4 Steps to Avoiding Cloud Repatriation
The primary factor for repatriation is cost. In our conversation with David Linthicum, Chief Cloud Strategy Officer at Deloitte Consulting, Linthicum noted that repatriation isn’t a technical decision. Instead, repatriation is about returning value to your organization. Repatriation is a symptom of a problem vs. a natural solution for all. The goal is to right-size your applications for the public cloud’s pay-as-you-go financial model. As a result, we see a vast majority of repatriation from lift-and-shift efforts to the cloud. In this post, we’ll discuss some technical strategies in response to the repatriation proposal.
Also See: Our blog post on four skills needed for repatriation proved popular. So much so we are considering putting on an in-person workshop to deep-dive into repatriation. We’d love to hear your feedback.
We talked with a born in the SaaS provider at the most recent AWS re:Invent. They shared how they reduced their public cloud spending by two-thirds via re-platforming the application. The SaaS provider examined customer patterns and determined that a lower tier of AWS storage would meet customer requirements. If a company storing Exabytes of data in AWS can save money, there’s an opportunity for most customers to save money. However, very few of us have the developer resources or business cases to re-platform hundreds if not thousands of applications.
Developers vs. Operators
We’ve found that developers are the top resource constraint for re-platforming. Developers should spend time solving net new business problems vs. reducing operational costs. It typically falls on operations to perform migrations and in-place application optimizations.
In the data center, optimizations occur at the infrastructure level. For example, if storage costs are out of control, operations may implement data deduplication (Dedupe) at the storage array level. Dedup reduces the number of copies of the same data. In addition, dedupe is invisible to the application and developer. Without centralized storage dedupe, application developers would need to optimize storage for each application in the enterprise.
We often ask what type of dedupe-like optimizations are available in the public cloud to reduce cost using operations staff vs. developers. Is this a reasonable technical request? Here are our four steps to optimizing legacy workloads for the public cloud.
Step 1: Understand Your Landscape – App Rationalization
Whether you are considering a move to the public, moving back to the private data center, or re-platform applications, start with application rationalization. The fastest and lowest risk transformation is the retired application. You may find reducing the size of your application portfolio reduces your cost and complexity enough to forgo any re-platform or repatriation.
Step 2: Understand Your Landscape – App Categorization
Understand what can be optimized. You may discover during this step there are no optimizations to be had.
Do you have some packaged software or commonly off the self (COTS) applications? You buy these products from independent software vendors (ISV) such as Oracle, SAP, VMware, and similar software companies. These apps are some of the least flexible solutions for the public cloud. For example, while you may be able to decompose SAP to a set of containers and cloud-managed databases, it’s doubtful you’ll get production support from SAP. Licensing is another factor. While the application services can run in a smaller VM, there are questions about whether an SAP instance may be licensed against an Oracle DB running in Oracle Cloud.
Also See: Our project using automation tooling to replatform a CTO application for Google Cloud-native services.
We are going to point back to step 1. Ask if the process owner may move this business process to a SaaS product. While not a technical process, it’s worth discussing with the business process owners. You may be surprised there’s a desire to transform the business process, and the IT inquiry was the catalyst to start the conversation.
Step 3: Understand Your Landscape – Low-Hanging Fruit
I hope you are sensing a theme. You must know more about your application portfolio than when you migrated to the public cloud. In theory, if you have simple applications that are mainly databases with an application server, you may decompose those applications to a cloud-managed database and a VM running the application daemon. You can then containerize the application or web server. This motion reduces a large portion of the waste associated with public cloud spending. No longer paying for an overprovisioned set of VMs that’s always on can put a significant dent in your cloud bill.
If the application can’t be containerized, look at spot instances. You could put a load balancer in front of low SLA application servers running on spot instances. Spot instances could save you up to 80% on instance costs.
Operators may automate the assessment of the low-hanging fruit. For example, in our sponsored project with Google Cloud, we ran Google’s mFiT platform against our infrastructure. As a result, it identified applications that our operators could decompose for native Google Cloud services. The conversation with CTO Advisor Alastair Cooke highlights what’s reasonably possible.
Our experience represents the current state of automated assessment. Today, you need highly skilled operators. As a result, you may need to engage a professional services organization to avoid leveraging your internal developers.
Step 4: No, Really Understand Your Landscape – Day 2
Optionally, you could move to highly complicated applications. However, you should slow down! Remember, you also need to give your support infrastructure time to catch up with the refactoring effort. Can your OS support team transition to maintaining and deploying container images? What about supporting application updates? Can you adequately monitor application performance in this new shared model? What happens when there’s an update to the cloud control plane? Can you pass a security or compliance audit? There are so many unanswered and unproven processes at this point.
When do you move to Step 5?
It’s our experience that most organizations’ application stacks are simple in design. So we’d suggest continuing the decomposition of the applications you’ve moved. A great place to look is your database use. Does every application need Oracle or Microsoft SQL? Will a MySQL instance do the job? What are the regular updates to your applications? Have you gotten rid of all the VMs you can eliminate? Can you move some of the containers to serverless platforms?
If you are genuinely all-in on the public cloud, then be all-in. Lifting and shifting your workloads was the easy part. The real work begins with re-platforming.
The CTO Advisor Repatriation Workshop
Are you interested in a deeper dive? There’s still conversation about networking, governance, and security. We’ll be putting on an in-person workshop and want your input. Take a few minutes to fill out our survey.
Share This Story, Choose Your Platform!
IT infrastructure subject matter expert (Cloud, Virtualization, Network & Storage) praised for transforming IT operations in verticals that include Pharma, Software, Manufacturing, Government and Financial Services. I’ve lead projects that include consolidation of multiple data centers and combining disparate global IT operations. “Three letter” Federal agencies have called upon me to lead the modernization of critical IT communication platforms.