For several years now, people and organizations have been slowly but surely moving their data and applications to the cloud. Whether it is a local private cloud, Hybrid or a fully hosted one, they all have one thing in common: They are no longer tied to physical hardware.
That is how it’s supposed to be right? Well, during my years of working with companies to achieve “cloud”, people are still getting a little confused, or they just do not understand exactly what they want, or better yet, how to get it. There is a difference between hosted servers, colocation, and cloud resources.
My experience in migrating our customers, we focused on three types of cloud migrations: 1) Infrastructure, 2) Application, 3) Storage. Many people say that moving to a SaaS solution is a separate way also, but I am talking about maintaining control over your applications, data, and the systems that house them. Most SaaS solutions, unless you set the application up on your own systems, is a paid service. Yes, we all know about DBaaS, PaaS, and XaaS, but we are going to focus on what you have in house for now.
The first thing I have my clients look when they are interested in a cloud migration is at their security needs. Are they under a compliance model that would be harder for them to enforce with their data being managed or hosted offsite (e.g. HIPAA, Gramm Leach Bliley act, SoX, PCI…). Storage is only part of the problem. Data at rest normally has a separate requirement than data in motion (i.e. Copying data to and from the cloud provider). If they are under restrictions, we have to factor in additional security measures like firewalls and new policies and procedures.
Once we get the layout on the security front, I take them through the application discovery. Why is this important? One reason is many software licenses for applications are only good for the local company’s datacenter, not at a hosted provider. Also, many homegrown applications may have hard coded information in them (e.g. IP Addresses, Using HOST files, or using a TCP/UDP port range to communicate with instead of a dedicated TCP/UDP port that can be opened in the firewalls). One other issue that homegrown applications have is the people that write them may not be around now (e.g. hit by a bus, retired, or quit). If that is the case, high-end developer resources are brought in to reverse engineer the application so it can be used in a cloud environment. That takes time.
Once we have a list of the applications, then we need to crunch some numbers. If you have 50 hosts, and out of those 50 hosts each one has 25 guest VMs then you would have 1250 VMs you need to migrate. But what if you only have a few VMs, and everything else are physical machines? Then you need to add an additional step or converting them from P2V (Physical to Virtual) or P2V2C (Physical to Virtual to Cloud). Not hard to do, but it takes time and allot of after hours work.
If we now take the 1250 VMs that we mentioned before, and now applied how many separate applications we have over the top of it, it should give us a number we can look at more closely. If the customer has 400 applications, we apply it to the 1250 VMs that would leave us with 850 VMs. This number says every application needs its own VM, which we know most of the time it is not true. Also, the new number doesn’t take into consideration clustered, print servers, fault tolerant units or server farms. So, out of those 850 VMs, some will still need to be around.
We crunch the numbers again. Everything you move to a hosted cloud, you pay for. Period. Whether it is CPU, RAM, Disk, Bandwidth you will pay something, somehow for it. And, if you use additional services that the cloud provider can offer, such as Databases, Backups, Managed Services, your ticket will grow per VM instance that you have in the cloud. So, we need to make sure that applications can coexist on the same VMs to save money. The only way to tell that is to monitor the application’s usage of resources and see if another application or a few can buddy up with it on the same VM.
Now, once we get to this point I ask them “Why?” Why do they want to move to the cloud? What do they expect to get out of it? Do you have a test environment already that you have been learning cloud management on? Do you own licenses for locally installed software or do you plan on using an open source solution? Does the term “all or nothing” really work for the cloud? Do you have certified personnel on staff that can use the selected software or environments to benefit your company and make the migration successful?
Over the next few articles here on CloudTweaks, I will get into the weeds of each step, why we need them, and caveats if we forget something or take it for granted. We need to look at the roles and responsibility matrix for each organization, and who does what when and where.
Cloud is simple, robust and easy to use if you plan accordingly. Just because you are being circled by hungry sharks, doesn’t mean they will bite!
Please subscribe to our weekly newsletter located in the footer to follow this series.
By Richard Thayler
