Moving from one supplier to another is never a simple thing; there are always subtle changes involved. In our day-to-day lives, even something as simple as switching from one supermarket to another has a number of effects. Moving from VMware (and on-premises) to AWS can be just as challenging, as there are a substantial number of differences between the two solutions and several factors to consider.
Let’s review some examples.
CAPEX vs. OPEX
Capital Expenditure is for buying tangible ‘long-lived’ assets. In our technological world, this would be networking equipment (switches, routers, load balancers, firewalls – and these can be either physical devices – or virtual software appliances ), compute equipment (rack mounts, blades, RAM, CPUs, disks, and peripherals), and storage (SAN, NAS, flash disks). Without a doubt, you have invested a substantial amount of time and resources in meetings and on RFPs before finally deciding on a specific vendor and solution. You will usually pay a good portion of the cost upfront (unless you have an alternative financing agreement). In most cases, however, it can take anywhere from a month to half a year before the system is actually put to use and becomes fully operational. In the meantime, the hardware is not being used for the purpose of which it was requisitioned, but you have already spent the money.
Operating Expenses, on the other hand, are ongoing costs (whether monthly, quarterly, or yearly) you pay for services you use. In the traditional technology space, the service contract and support for the hardware you purchase is OPEX. If you need support on day one or you have a faulty part, then you will have made use of the money you spent, without having to wait a period of time before being able to use it.
VMware licenses are definitely CAPEX. You purchase them in advance for (or with) every physical server you would like to use. Sometimes, you even purchase several licenses to have spare in your pool be it for budgetary, organizational reasons, or perhaps just for convenience. The support fees added to the licenses you buy are your OPEX, and will become a recurring cost year after year.
Monthly Billing Cycle
The general consensus is that money spent on your cloud resources is OPEX. With AWS, you receive a bill in your email box once a month, like clockwork. All the resources you have used over the previous billing period are aggregated into a PDF with a lump sum on the bottom that you now have to pay to AWS for their services. There are no RFPs, and no customer meetings (although there could be price negotiations, depending on the size of your company and projected spend). This is the aaS world. You use it, and you pay for it at the end of the month.
Why should you take this into account? Although it should not affect your budgetary planning, which is usually done on a quarterly basis, there is a possibility that your monthly expenses will fluctuate. This could be for a number of reasons — being it the ramp-up of a new project for a customer, high season sales, or a major event that requires more resources for a specific period time, hence the higher cost for that specific month.
Cost Model Difference
The cost model for on-demand usage is the complete opposite of the model with VMware. The initial forecast for a vSphere cluster includes not only the servers and the licenses, but also the storage capacity and network bandwidth that go with it. This requires hardware underneath, storage arrays, disks, network switches, and ports. You cannot just buy a single disk; you need to buy a shelf. You cannot buy a single network port; you need to buy an entire network switch. This brings us back to the fact that the infrastructure you are using will only be fully utilized many months (or perhaps years) after you have purchased and paid for it.
With AWS, you only pay for what you use. You don’t need to buy extra ports or extra disks in advance (of course, there are certain cases where paying up front for compute resources will save you a substantial amount of money; with reserved instances, for example). But on the other hand, you pay for every single thing you use; every bit and byte, every request to the API or a service is metered, and you are billed accordingly (for anything in excess of what you’re granted in the free tier).
Where can this come into play? Consider your in-house monitoring solution queries the vSphere APIs every minute to get the metrics and alerts of your workloads. Since you have already paid for the product, you own it, and the only cost involved here is the performance of the vSphere API that provides the metrics; this can usually be addressed by beefing up the resources on your vCenter servers. You can query as much as you want; it doesn’t really cost you anything for each additional query.
But if you were to use the same model on AWS (which is not necessarily best practice), you would now incur a cost for 60 API calls an hour (assuming that you can get all the information you want from the request). You would now need to worry about throttling and have to pay for each request you make. This is an oversimplified example, but you can extrapolate your specific needs and use case to see where this might become an issue.
Changes in the Workplace
To work with AWS, all you need is a computer, a shell prompt (or web browser), and connectivity to the internet. You can work anywhere – any time – and in most cases from any device. This could have a significant impact on your expenses on support for your applications and infrastructure.
Instead of having to keep someone on site 24/7 (sometimes in multiple locations), which has a price with people working outside of the regular working hours, you can spread your support team across the globe, and assign them the responsibility for the infrastructure. They do not have to be physically located in the same place as your resources. Everything is managed through an API.
It is also worth considering the possibility that a good part of support and infrastructure will become generalist; what some call the “full stack engineer.” The costs of employing such an individual might be higher than of a specialist in one specific field (such as storage) but the number of employees needed to support the infrastructure (which grows continuously) is going down. As a result, your support and salary costs might actually go down. Of course, this will differ from one solution to another and a proper cost analysis should be performed before drawing any concrete conclusions.
Making a change in the business is not always an easy decision, even more so when we are talking about such a large one as revamping your consumption and financial model of licensing and infrastructure services.
It is not clear-cut whether such a move or the decision to change your provider from VMware to Amazon will actually save on the short- or long-term expenditures. Contrary to what some might think, it is not all about the money you spend. There are many other considerations, such as time to market, agility, and innovation, that also have a net value and should be considered as part of the overall equation. All of these can provide a real cost benefit and influence your decision to move from your own datacenter out into AWS.
It does not have to be an all or nothing decision. Many organizations see a huge benefit to moving some of their workloads out into AWS while preserving their on-premises infrastructure at the same time, creating a hybrid-cloud solution which provides them the best of both worlds. Last year VMware and AWS even went a step further and entered into a partnership to offer a VMware solution running within AWS – which would suit a certain number of use cases in the cloud.