VMware is viewed as the de-facto Enterprise leader in on-premises virtualization solutions. The VMware suite of products is used amongst almost all Fortune 1000 companies and they entrust their mission-critical applications and workloads to a robust and stable platform. But robust infrastructure is not the only requirement today, there are other just as important factors such as agility, self service and feature set, all of which are sending more and more organizations to public cloud providers like AWS.
There are a number of important concepts that you will need to consider in assessing whether migrating to AWS is the right option for you.
Pets vs. Cattle
There is a great analogy for what should be considered a “cloud ready/suitable” application, and that is the way we treat pets vs. the way we treat cattle.
Your pet has a name. You have nurtured it since it was a puppy, bought it toys, cared for it, taken it to the vet when it was not feeling well. Y your pet is something you have invested a lot of time and money into and if you were to lose it, it would be sorely missed. It is also something that is not easy to replace.
Cattle on the other hand do not have names, usually only numbers. You don’t really invest very much in any one animal as opposed to all the other animals in the herd. It serves a purpose. If it were to get sick and die, you would replace it with another animal – just like it.
Workloads that have traditionally run on VMware are like pets. The functionality built into the underlying platform, including all the high availability options, live migration, backup and replication, just to name a few, were made for that specific purpose. It will be a huge loss if your workloads were to die and you needed to rebuild them. This has been a perfect fit for the on-premises, enterprise workloads. And this is where VMware shines.
Workloads that run in AWS are like cattle. They don’t usually have a name – just an instance ID. Launching a new one with the correct software configuration is as simple as running a command from your computer. And if they die? Then the cloud has the capability to automatically launch a new one – with the same configuration as before –all built as an integral part of the platform.
The Real Difference Between Pets and Cattle
The analogy above is nice – but in reality there are a number of core elements that actually make it a reality.
Imagine if you were to open your closet and ask out loud, “Today is going to be below freezing, Give me the appropriate clothes so that I won’t be cold”. And your closet would hand you the appropriate layers of clothing to make sure you could handle the weather outside. That would be amazing! This, of course, would require a fair amount of underlying logic itto enable t the closet to understand what you’d need to wear in sub-zero weather. – But it would not really care about the color – or if the items match – and for some that would be a catastrophe (for others a blessing).
Fortunately, applications don’t care about what they look like, it is all about functionality – just give me the tools to get the job done.
When provisioning an instance, you would ingest a role (also known as a grain) into the machine. The machine would now communicate with the central server, identify itself as a web server (this would equate to “it is going to be cold” in the example above), and receive a list of software (clothes) that it needs to install (keep warm).
This method scales very well because the installation of the software is no longer part of the logic an instance needs to maintain; that responsibility is transferred to a central server.
Automation, Automation, Automation
Imagine manually installing software on all your servers. This might work for very small environments, but when going to the cloud we do plan for a much larger scale of deployments, sodoing things manually will not work.
You do not have to go all in with a full fledged configuration management solution (although the benefits of doing so are huge). You can start small by creating a script that will install your component without any human interaction. This will allow you to start treating your workloads more like cattle and allow you to launch an instance – and have it come up configured and ready for use. You can use a standard bash script to get you started. As opposed to the way things are done in VMware,where getting code injected into the instance at startup is not straightforward and is only possible through the VIX API, in AWS it is dead simple.
The amount of services available today in AWS is astounding, with more being added on a regular basis.
Let’s take RDS for example. AWS has a Relation Database that is compatible with Oracle databases. There is a very high cost entailed when running your own Oracle cluster. Some customers have chosen to use RDS and have managed to reduce their expenditure by a factor of thousands.
Take some time to understand where it makes sense to use these services and how they can simplify your work and processes.
Companies are usually in the business of selling their products or services, after all, that is where they make their money. They should invest in the added benefits that they can provide with new product features. Investing large amounts of time and human manpower to manage the underlying infrastructure is not part of your core business.
Let someone else do it for you.
Consuming a service from AWS is dead-drop simple. All you need is a credit card and you are on your way.
But as easy as it may be, you could also be well on your way to whole new set of problems. Cost is something that can very easily get out of control because AWS is so accessible. You should prepare yourself and your financial organization for such a transition, and make use of all the tools that AWS makes available to its customers. AWS has APIs and alarms that will alert if your bill is expected to be higher than usual. And there are cost optimization tools to help you save money.
As result of the ease of use, not only can your costs spiral out of control, but you might also be opening yourself up to numerous security problems.
Your team knows how to protect the perimeter of your network. There is usually a beefy firewall that blocks access to your precious data and resources. You have a dedicated and experienced network team who do their job very well, day in and day out, to protect your precious secrets.
However, with the move to AWS there is no perimeter. Anyone on your team that has access to AWS – and this now includes the developer, the database administrator, the security guy, the networking girl, and the financial accountant on your budget – can access your resources.
The boundaries are no longer there (at least initially), therefore you need to invest time in understanding how you can allow your traditional teams to continue to maintain control over all the new options available in your journey to AWS. Understanding the strategies to manage users through IAM will not only allow you better control over the resources you are using, it will also ensure that – even with the move to AWS – you maintain the same level of compliance and security as you are used to in your own datacenter.
As explained above, there are a number of different factors to consider when moving away from your own private datacenter and VMware environment and into a managed service. The factors do not only apply to the technological parts but also to people, processes, and architecture.
The decision to move should not be taken lightly. It requires a substantial amount of planning and research. It is a journey, not one you will be able to get right the first time – it is one that will continuously evolve over time.