Do you want to be in the data center business?
We didn’t think so and you’re not alone. Most CIOs have a deep desire to get out of the data center business. Corporate leadership, understanding the benefits of public cloud, are directing IT to reduce costs. Therefore, many IT executives are turning to public cloud as a model for reduced total cost of ownership (TCO). This requires a significant migration of application workloads out of data centers and into public clouds. Our experience points to an average TCO savings of 40% year-over-year, achieved through what we call mass migration – moving application workloads to public cloud providers using a factory model. We’ll discuss the specifics of this factory approach later on in this guide.
A successful cloud program requires a basic change of mindset. IT groups have traditionally approached big projects as if they were launching a rocket: make or acquire the components, install them, test everything, put it all on a launch pad and send it off. With cloud adoption, this approach presents too many opportunities to get it wrong. It also traps IT in the ‘Tyranny of How’, paralyzed by analysis, evaluation, preparation, planning, strategizing and a host of issues that get in the way of actually doing something meaningful.
There is, however, a fundamental concept that is proven to break the old thinking paradigm. We call it the MVC, or Minimum Viable Cloud, built on the same premise as the MVP, or Minimum Viable Product, from the book, The Lean Startup. In the MVC we teach clients how to iterate their cloud program to prepare for mass migration.
Iteration can be a hard concept to embrace, requiring IT execs to abandon their waterfall model of data center management. In the new model, infrastructure is code. The public cloud lets you use software to create the data center. Whether it is Chef, CloudFormation, Puppet or Ansible, software defined data centers allow you to build and operate at scale—servers, storage, networks, and security. Since you’re creating the data center in software, you can iterate and fail fast until you get to the cloud state desired for production. But IT needs to go from being a hardware-centric organization to a software focused team.
Building a Nest for Your Eggs
With the MVC, you iterate on the infrastructure you’re preparing. Think of it as building a solid nest (platform) for your eggs (applications) and putting that nest in the best tree (data center). By iterating on the MVC, we can tear the nest apart, and even go to another tree at a fraction of the time and cost of doing those things in a physical data center. The MVC then becomes the centerpiece of your cloud program, preparing you for mass migration. You can track the MVC as tightly as any piece of code going through a CI/CD (continuous integration, continuous deployment) cycle giving you much greater control of your infrastructure.
Selecting Your First MVC Application
In the MVC nest, that first egg, that first application, is most critical. Not everyone in the organization may be on board with the migration to public cloud, so it is important that your first project is a meaningful application. We advise clients to release a meaningful application in the first MVC iteration, one that requires all stakeholders to participate in the release of the production application in the cloud.
Starting with an iteration of just one application is also important because you’re exercising an organizational muscle that hasn’t been used before. Remember what it felt like the first time you went to the gym? That is how your organization will feel after your first pilot application moves to the MVC. This step is key because all eyes will be on the process. You may have to tackle a range of issues to get buy in from InfoSec, Risk, App Owners, Operations, Governance, Compliance and the executive office. Your MVC is the foundation for iterating through each of these groups.
Naturally, once you’ve done a few applications, you’ll feel more comfortable, just like you did after you made a few more trips to the gym. Mass migration involves heavy lifting. it is like a flywheel—hard to put into motion, which is why you need the iterative process; but important to run correctly from the start, because once your application migration is up to speed, it is hard to slow down. The MVC iterative process also helps address internal groups’ fear of change, since the change first occurs in the cloud model, without significant expenditures of money or time.
MVC 1.0 – What’s in the Box?
MVC 1.0 is the baseline of capabilities to start with from day one. Without such a starting point, clients can get lost between requirements gathering, capabilities mapping, planning, design and implementation, and even lose sight of what they’re designing. We recommend adoption of the MVC baseline of capabilities (reference architecture, services, tools, etc.) and then perform a series of gap assessments to determine what changes need to be made to the MVC 1.0 baseline, including:
- Application Assessments – What are you moving or building?
- Security Assessment – How will the controls change in the new model and how will we implement the technology to address the new controls?
- TCO / ROI – What are the economics of the program? Are there compelling reasons to move to the cloud that would stand up to Board of Director scrutiny?
- Operations – What changes to the operational model are required to manage and govern the cloud at scale?
- DevOps – How will the application teams work with operations and adapt to the new mantra infrastructure as code?
Assessments identify the gaps between your current state and the MVC 1.0 baseline, which are then remediated during the building of the MVC.
MVC 1.0 must include the following:
- Networking and On-Premise Considerations
- VPC Design
- Account Structure
- Third-Party Tools
- Identity and Access Management
- Security and Protection
- Automation and Control
- Encryption and Key Management
- Image Management
- Logging and Monitoring
- Data and Databases
Once the gaps are identified, we implement the MVC and prepare the nest to receive the application and data.
By the way, clients tend to assume their applications work, but we often find something no one ever saw, like the scratch on your car you never noticed until someone else drove it. Depending on the complexity, age and architecture of the application, the effort it takes to migrate to the cloud can range greatly. Therefore, we recommend a migration workbench approach leading up to Migration at Scale.
Using a Migration Workbench Model
A migration workbench is a team of engineers who perform a specific set of migration tasks. There are six migration workbench types. They are as follows:
Rehost — Generally referred to as ‘Lift and Shift’, this workbench is a machine to machine migration of the application and data to the cloud platform. This is the easiest of the migration tracks and can be done using automation for most of the tasks. However, you don’t realize all of the cloud benefits, because the applications have not been developed or rewritten for the cloud.
Replatform — The replatform workbench is a team of engineers who perform minor, but critical replatforming functions to enable the application servers and software to run on the new cloud platform. Typically, this involves environment changes, not code level changes. Replatforming includes:
- OS and or database version upgrades
- Significant DNS and networking changes
- INI and Configuration file changes
Refactor — Refactoring an application occurs when code level changes are required. This should include code scans for blockers that would prevent migration to the cloud. At CTP we use a tool called PaaSLane, which scans .NET and Java code for problem areas that may restrict migration to the cloud. Refactoring is a complex function and requires the team to have domain skills in cloud services, as well as security and infrastructure knowledge.
Retire — Retiring applications appears to be straightforward, but many clients overlook a lot of the benefits. On average, 30% of your data center applications will be retired due to replicated services within the cloud platforms. In addition, there are often applications running in the data centers that are maintained for compliance requirements only. They could be retired early in the cloud by building the system in software, testing it and then turning it off, thus using the services only when needed. This creates significant cost savings.
Replace — Replacing applications is more complex and very dependent on the business unit or application owners. However, the Replace Workbench is required in the event that the total data center footprint is eliminated.
Retain — Unless you have a zero-footprint goal, you will likely have to retain some portion of your application estate. At that time, it is really about ‘end of life’ scenarios and how you plan to decommission the platform. The challenge is not how to retain the applications, but how will the cloud based applications engage with the retained applications? Often the retained applications are centers of gravity. They are huge databases and legacy systems that have hundreds of connections to other services. If you are consolidating data centers and need to move these applications, sorting out the complex spider web of connections is the job of the Retain Workbench.
Having determined which applications can move to the cloud, we set up the cloud environment, secure it and prepare operations to receive the applications as we transition from an MVC modality to mass migration.
This is a solid, prescriptive factory approach to application migration – but it does require a new way of thinking for IT.