A few weeks ago, I attended a virtual Field Day event, Cloud Field Day 7. We had several presentations from VMware focusing on VMware Cloud on AWS. In future posts I will get into the more detailed aspects, however I wanted to start out with a few hot takes.
This gives me a chance to revive the notes from CFD5 and combine the two experiences into my list of why you should give a damn about VMware Cloud on AWS.
1. Refactoring is not easy
Over the last few years, I have worked on some large cloud migration and application modernisation projects. I can honestly say once you get into the nuts and bolts of legacy applications you end up finding challenges that you never thought you would face.
Taking a traditional monolithic application and migrating to the cloud via microservices or functions is a slow process for most. Where do you start? How does this method interact with various parts of the infrastructure? How does a typical user story play out across the code?
What you will find is that a lot of these types of applications are tightly coupled. Due to the nature of the infrastructure they were designed for, they will make calls back and forth between components more often than a modern equivalent. Refactoring often can’t be completed in one big bang. You need to be able to approach it in stages and have clear paths forward including migration and the ability to roll back.
Moving individual components of a large application one piece at a time can introduce latency, complexity, and a much larger path to troubleshoot. The cloud offers fast connectivity, but we can’t beat the speed of light. You are always going to be adding in additional hops throughout the end-to-end transaction.
Imagine you could just move the existing application and all its dependencies as-is to a familiar operating environment. As close to the new cloud services that you wish to consume as possible. Well you can and in my opinion, this is probably the best move you could make in that refactoring journey.
2. Data Centres are not your core business
Very few customers that I engage with are in the business of running data centres or hosting platforms. I am a huge advocate of buy before build when it’s not core to your business goals. Whether you have on-premises DCs or you are using a co-lo service, there are costs and overheads involved.
The benefit you get in return for this is small. Staff that support the DCs and infrastructure’s ongoing operations would be better utilised in improving business processes, building automation, improving service to end users. Or maybe working on that refactoring and modernisation that will accelerate your products to market.
VMware Cloud on AWS allows you to use the same skills and processes or automation that you have in place today. The great benefit is that you are no longer concerned with the nuts and bolts of power, cooling, patching, hardware refresh cycles and many activities that plague the day to day of existing infrastructure.
3. Flexibly scaling your own infrastructure is a myth
Ok, that’s a bit bold. In practice the scalability that you can get from your own on-premises infrastructure comes with some caveats. If you are using a blade system you aren’t going to get a huge amount of value from decommissioning a single blade of compute. Likewise, with shared storage, freeing up data here and there isn’t going to produce a meaningful reduction in footprint.
Now the smaller the units of infrastructure you are using the less this might impact you. In some cases HCI solutions are going to be a lot easier to scale up and down as needed. But you still have associated infrastructure like networking. You might have software licenses that are on long term agreements. Then there’s the physical part, you may need to empty an entire rack before you realise any savings there.
One of the more difficult realisations for customers is that their cloud migration journey is going to involve increased costs. Often for a sustained period before they can measure the ongoing savings. It’s not like you can just turn off 10% of your data centre when you’ve migrated those applications.
Taking an approach of just migrating from one vSphere platform to another with minimal reconfiguration and downtime smooths out the increased cost spike and accelerates the decommissioning of on-premises infrastructure.
4. Disaster Recovery can be challenging
Often we set out with the best intentions when it comes to disaster recovery, but I have found that it doesn’t always stay that way. When you embark on that journey you have decided that in a significant event you will recover a percentage or all your workloads to an alternative location.
If you went the route of being able to recover everything then you’ve probably invested a huge amount into equipment. Perhaps to avoid that you decided that only the most critical services will be recovered, and you scaled down what you install at that second location. But how often do you review what is critical? How often do you expand the DR location to meet the current state of the production systems?
You often see a lot of drift over the lifecycle of the equipment and that can impact the ability to recover. Many decide to run Test & Dev workloads to maximise return on the investment. But all too often those systems become critical to someone and they are not T&D anymore, some make their way into production. Try shutting those down when you need the resources for your failover.
VMware Cloud on AWS allows flexibility in the replication of workloads. You can ensure that all the data critical to getting online is there and only run the minimal amount of compute required. When it comes to hitting that big red button, the environment will auto scale to accommodate the compute needs.
5. Not everything is suitable for cloud native approaches
We need to be honest to ourselves, the applications that we’ve been using for the last few decades are not going away any time soon. There are many reasons for this, it could be costs involved, fear of it breaking, legacy languages and dependencies, or any number of other challenges.
There’s a reason that mainframes are still in production. That applies for most things we have used over the years. When you sit down and analyse the applications in your estate there will be some that you just don’t want to do anything with. Until maybe you can retire them one day.
While the idea of running a hybrid approach of on-premises applications and cloud native applications is not new and there are many ways to support this. Sometimes it just won’t be the answer. It could be because of any number of the reasons I have outlined in the previous points or something entirely different.
VMware Cloud on AWS allows a tightly coupled hybrid environment using resources in the same locations and on the same networks. This allows you to take advantage of cloud native where it makes the most sense for your business. Keeping the rest as-is, but all in one place.
Final Thoughts
In closing I would like to note that since the initial presentation from VMware they have announced platforms in all the major cloud providers. There must be a reason behind this adoption, and I think that I have covered some of what is driving that.
I have been around long enough to have learned never to deal in absolutes. There will be cases where none of the above apply to you. There will be cases where applications need more performance or specialist integrations that you just can’t take advantage of in this model. There’s no one size fits all approach in IT, but for a large part of the market, VMware in the cloud will tick a lot of boxes.
