In this article
May 26, 2022 is a date that may have sparked a major change in the technology industry for years to come. On this day, Broadcom announced its intention to acquire VMware. The news came as a major surprise to the entire industry and inevitably has led to many interesting discussions with peers and customers alike.
VMware and its portfolio of products are still considered to be a viable platform and strategy. They have been the market leader in this space, are a known and viable entity for our customers, and have been the de facto in the data center since the dawn of x86 virtualization. This article is not aimed at discussing the rumors, the potential pros and cons of the acquisitions or to guess what could happen in the future, as these are opinionated and speculative at best. Instead, the focus is on the questions that some of our customers are asking:
- What should we do, if anything?
- What are other customers doing?
- What are data center alternatives that we can consider?
Often, the discussion starts with "We need to reduce risk and need a viable alternate solution," and jumps directly to "Let's migrate!" The problem, however, is much bigger than it appears to be on the surface. Migration efforts are a major piece to consider but are ultimately the tip of the iceberg and the final step in the process. Customers should also consider the following for all options discussed below:
- Application compatibility
- Processes and documentation
- Ecosystem software & integration
- Training and hiring
The strategies below are built around the 6-Rs of cloud migration as the efforts for a private cloud follow a similar approach. The focus of the article is specifically based for on-premises workloads and potential swimlanes.
Repurchase and/or retain
This strategy focuses on repurchasing and retaining the existing virtualization strategy while optimizing consumption with respect to hardware and software licensing. Have an ELA? Now would be a good time to look into renegotiating the contract. Customers can also start evaluating alternative point products that may be used throughout the environment.
There are many unknowns around the potential acquisition, some may become true others not. Evaluating alternate solutions for the different portfolio products (outside of the base hypervisor) helps ensure IT requirements are met, proper integrations and workflows have been worked out and the level of effort is understood. Overall, this allows customers to keep the mindset of "business as usual" but readies the business to move quickly in the event of an unexpected/unwanted outcome.
This strategy is the equivalent of a "lift-and-shift" where a customer takes virtual machines in one environment and converts them to a different format on a different hypervisor. Thus far, this is the most asked-about strategy, however, it is the hardest to successfully execute.
This approach gives the quickest relief, but it also introduces many overlooked considerations which include, but are not limited to:
- Maintaining multiple infrastructures: As an example, if there is a disaster recovery plan in place today, now there are two disaster recovery plans that must be documented, maintained and tested.
- Documentation for runbooks and troubleshooting of the new architecture must be re-written for the network operation centers (NOC) as procedures will change.
- Potential challenges for training and hiring administrators with the appropriate skill set to manage the environment at scale.
Consider the image below (not all-inclusive) when going down this path. These are some high-level tasks that should ideally be completed prior to performing migrations to an alternate strategy.
Once the above is understood, documented and accepted, migrations can begin. Keep in mind that migrations will take a long time and will be affected by many factors including how much data is going to be transferred, the speed of the network, risk tolerance and length of maintenance windows (note that all virtual machines will require an outage for the cutover).
Refactor and/or replatform
As the name suggests, this strategy focuses on general containerization and what can be done to properly containerize existing applications, which includes rearchitecting to utilize a microservices architecture. The strategy is two-fold:
- Accelerate the speed at which containers are being adopted, aka adopting a "container-first" strategy.
- Evaluate existing applications that are in the form of traditional virtual machines and covert them to containers.
This strategy should be the ultimate goal and focus for organizations. The industry is moving in this direction, and it is not a matter of "if" but a matter of "when" applications will require containerization. Think back to when virtualization first became a viable option. It didn't take long for IT departments to force applications to be virtualized vs. running on bare-metal unless there were valid reasons. The container world is at this stage.
This is not to say that this strategy is easy. It is met with its own challenges which can include application supportability and the seemingly endless list of open-source software that could be integrated. This strategy checks most of the major boxes:
- Slows down spending in the legacy environment by adopting a container-first strategy.
- Slows down spending on various portfolio products by leveraging native container features.
- Increases application agility & resiliency.
- Reduces "vendor lock-in."
Most customers are currently deploying container platforms in a virtualized environment vs. bare-metal. Adopting this strategy can also include evaluating alternate hypervisors to host the required container components relieving pressure on future licensing investments.
Each strategy above requires its own set of evaluations and specific questions to be answered. Customers will likely end up with a combination of two or even all three but should choose to have a well-defined plan on a single strategy, which needs to include cost estimates.
Every customer is at a different level of portfolio usage and integration which will determine the level of effort required for each respective strategy. Below are some example questions with respect to costs that should be documented:
- What's the current spend with the existing strategy?
- How are we expecting the costs to increase to be in the future?
- What value do we put on the various intangible rumors (i.e., How the support organization could be affected and ultimately affect the business with time to resolution when an issue occurs)?
Answering these types of questions will help give a sense of how the business could be financially impacted in the future. Comparing these costs to the estimated costs of adopting one of the above strategies needs to be evaluated and budgeted appropriately. For what it's worth, we are not saying "Don't migrate!" but that it is especially important to understand the costs of efforts such as these (alternate virtualization strategies or otherwise). Spending dollars to ultimately save pennies is not an ideal outcome.
Have more questions? Reach out to your WWT account team to schedule time to have a deeper dive and evaluate how the different options might or might not work in your specific environment. Our teams and experts can help with cost estimates, implementation and migration services as needed. We can also help with testing out solutions in our ATC to help you get a better understanding of how different products operate and how they may differ from your existing strategy.