The biggest part of my job is speaking with end user organizations and understanding their greatest current and future challenges. Oftentimes I hear about workloads that are initially developed on a particular cloud provider’s infrastructure that cannot be redeployed or migrated anywhere else. To be clear, nothing is technically impossible. It’s always a matter of the migration costs outweighing the benefits. Many times organizations want to move workloads developed in a public cloud to their private cloud for reasons such as security, compliance or lowering costs. In other cases, service stacks may need to be distributed globally to 40 or more countries and rebuilding those stacks on various infrastructures can cost millions.
The bottom line – the organizations that I speak with daily are demanding the following with respect to their hybrid cloud strategies:
- Flexibility and choice – Today’s platform decision may not be the best option in two years, or perhaps even in a few months. Organizations want choice, and they don’t want to pay a severe financial penalty for changing course.
- Common management – Converting virtual machines, and moving applications and data is often not the challenge when it comes to managing hybrid cloud workloads. The true challenge is trying to manage workloads deployed to different data center or cloud environments requiring new API integration or new operational management tooling. IT decision makers want a consistent management and QA experience no matter where they deploy a workload.
Hybrid cloud architects want as few variables in the architecture as possible because the greater the variation the more costly automation becomes at scale, and that extends to management products. Most IT decision makers see flexibility as the capability to run or move a workload wherever they choose, whether it be the public cloud, a private data center or to a new outsourcer of their choosing. When you get past the marketing and really examine technical architectures, converting the virtual machine, migrating the app and the data is the easy part. Rebuilding the management infrastructure is anything but “easy.” Management dependencies are massive and are like a game of Jenga. Take one away and the whole service stack can come tumbling down. Those that have played Jenga know that rebuilding is a daunting task, and the same can be said for rebuilding an IT operational management stack.
I discussed hybrid cloud management dependencies in greater depth in this post, so I won’t repeat them here, but I think you get the point.
I mention all of this because today Amazon announced the AWS Management Portal for vCenter. Administrators will find this tool useful for importing virtual machines into Amazon and conducting basic management tasks from VMware vCenter. However, as I’ve said before, the virtual machine is the easy part. Consider all of the management dependencies above as well as third party integration. If you want to move those workloads or simply run additional instances in a region with no AWS presence, an outsourcer, another cloud provider, or your own data center, you may find that the cost and complexity associated with migration or a new deployment is too much. The service stack would likely be bound to proprietary APIs, and all or most of the third party management and operational software will have to be replaced. You will be burdened with new QA challenges and likely will need to reengage with the procurement teams.
In summary, there are many things that the AWS Management Portal does not do that should lead you to question its strategic value:
- There is no easy way to move workloads back to one of your data centers, or to another cloud provider
- You cannot use your existing software licenses
- You cannot automate and orchestrate across private and public clouds
- You cannot enforce policy governance across multi-clouds
- You lose all of the seamless third party integrations deployed through the VMware Solution Exchange
Whether you are strategically aligned to VMware or not, you should demand consistent management, third party integration, and a common API that spans all hybrid cloud deployment scenarios. Don’t be fooled by basic management that is tactically useful today but can lead to increased lock-in down the road. The cloud service broker has to be multi-provider – vCloud Automation Center is today and has been for some time. Beyond that – the hybrid cloud platform should enable provider choice and seamless third party integration, regardless of where a workload is deployed. Deciding to run a workload somewhere else should not require a massive migration effort along with massive costs.
Choosing a tool that addresses an immediate need can help today, but can create more problems down the road if you’re not careful. I applaud Amazon for creating this tool for its tenants, but I encourage all end user organizations to take this moment to reflect on your overall hybrid cloud management strategy, and choose a platform that is right for your long term strategic needs.
Anyone who has been in IT long enough knows how easy it is for a tactical Band-Aid to unexpectedly become a permanent solution. In the cloud era more than ever, you must think strategically about management. To date, proprietary service provider tools have created management silos that drive up total cost of ownership while increasing provider lock-in. There is a better way. Our approach is to give you choice of a de-facto standard that is supported by thousands of cloud providers, outsourcers, partners, end user organizations, and ecosystem vendors world-wide. In addition, our OpenStack support allows customers to choose how they will integrate and manage services, while giving them the flexibility to change course anytime.
When it comes to management, every product choice has implications. As the great Yoda once said, “Always in motion is the future.” What seems sensible today can cost you dearly tomorrow. Management tools that take away your ability to choose limit your future. Agility demands are picking up, but this is only the very beginning. Our bet is that a future with limited choice is a future with insufficient agility. How will you define your organization’s future?
Comments