Where the VMWare & AWS Alliance Works

Not everything is suited to Cloud out of the box & business constraints can take teams by surprise. What can they do? Well…

I’m not quite sure I fully agree with the article on Cloud Opinion. That said, I absolutely do agree that customers must invest in learning to refactor and [re]architect for cloud. Sooner or later, they need to seriously consider it in order to take advantage of the economics and indeed, other important factors that cloud can offer.

Optimization Problems

The issue isn’t as black and white as is made out though. There are several situations where options around “lift-and-shift”, which make no mistake, I hate, do have to be considered in the context of everything else.

Lift-and-shift migration is frequently more costly in cloud than in COLO, simply because existing COLO infrastructure was built based on the old school capex model of procurement. Once a server is there, it’s there. This little known fact means that it is often cheaper to provision the same platform in regular data-center offerings.

What’s worse, missing internal skill around cloud mean external skills have to be brought in and the inevitable context switch from COLO to cloud may leave companies craving the familiar. Indeed, due to the aforementioned capex/opex shift, this may be fundamentally incompatible. This left companies like Moz in an initial position where lift-and-shift operations put them out of pocket by almost double their original localised TCO.

With that position, how could such a migration ever make sense? You have to rearchitect first and shift later, surely? Normally, I agree.

Reclamation

The reality of enterprise systems is more complex than we’d like. Whether or not the development team or IT department are aware, contractual agreements set obligations which carry legal and economic consequences. Most notably, vendor renewals. Contracts which supply fixed, provisioned virtualized storage and compute for 5 years suddenly become a pain to think about very close to renewal dates.

At the same time, organisations are under pressure to do much more, with less. Commercial floor-space costs more, staff cost more, capital costs more (as more resources are added and more licenses procured). Many organisations are on core VMWare infrastructure, which is akin to migrating bare metal boxes unless you convert them to AWS or Azure. An option AWS has long provided to those wishing to migrate.

Yet, these still aren’t painless and 100% confidence building. Any step we take needs testing. Hence, the resulting VM’s need testing thoroughly. Not least through load balanced services and subject to new network latency. For enterprises, it’s much easier to simply drop a VMWare server on to AWS as-is, since this cuts out one of the moving parts when considering performance and often reliability, together with the large amounts of associated testing and a large proportion of any regular blue-green monitoring, certainly as they see it (my view is you shouldn’t skimp on quality). The theory goes its a much less painful route for enterprises. Providing a stopgap whilst they carry out the necessary architectural rework.

Moving from monolith to microservices is not a small and painless undertaking. There is a lot of legacy code work. When it’s done, it’s great! However, until then, there is often a lot of false starting and definitely a lot of coverage work to do, even piecemeal. Doing the rearchitecture work first creates a dependency between that and the cloud migration. If the first work isn’t done, or doesn’t deliver in the same way, cloud never happens. If there is a vendor renewal in that time and it’s more expensive, then it’s an added capital cost companies have to shell out. Often for 12 to 24 months or more.

Crucial trade-offs

It’s to be compared against the cost of not doing it later.

Lift-and-shift costs more (or rather never costs less) than an appropriate cloud architecture. I think most can agree on that. To lift-and-shift that for 2 to 4 years is akin to having a vendor refresh and at almost double the cost. It’s like paying out a contract of 3.5 to 7 years long, but only getting 2 to 4 years out of it. It elicits a number of questions:

• Does this extra cost necessitate the architectural rework earlier or later?
• Does the company get more from reusing the space earlier? For example, new staff with any extra productivity. Or lower IT staffing costs per server?
• Does the company have enough capacity to do the migration or the rework?
• Does a VMWare migration step give them that space?
• Is there enough time before a vendor refresh to carry out the architectural work, without compromising the platform TCO as a whole?
• …

Summary

For some clients, VMWare’s partnership with AWS does address those customer pain points. I certainly don’t recommend it as a primary strategy, but if needed, it’s another tool in the repertoire of architects and one that, together with one eye on the future of a system, we should at least be prepared to take, otherwise we may risk losing the value sweet spot of the investment to sub-optimal results on either side.

Liked the article? Don’t forget to share this knowledge with your friends, family and colleagues by hitting-the-heart.

Ethar writes about anything and everything IT. He’s a lean-EA, coder and all-round geek, with a bit of a hackers mind and runs a systems engineering company when he’s not.