Robert Starmer, Kumulus’ Founder and CTO shares his insights into the decision-making process of cloud migration or cloud repatriation and provides practical advice on how to manage a successful and repeatable migration.
Does it make sense to migrate your current cloud environment back into a self-managed or third-party managed data center environment?
I think it comes down to looking at this from a couple of different perspectives. First, what is the overall value? Clearly, there’s value in the application or you wouldn’t be talking about migrating or repatriating it. But there’s also the question of the effort needed to perform that migration and the cost structure of the application relative to its revenue generation potential. If we start with the question of what is the value of an application, we can start to build a business model around the revenue potential.
If you’re developing something new, assigning value might be a little bit more difficult because you haven’t necessarily reached any level of scale and consistency in terms of customer consumption of a resource to understand the business value. But there certainly is a business model behind the dollars to run my application, and I presume that I’m going to be making more than that to offset the cost of those resources.
But it’s not just the resources. There’s also the question of break-fix, finding that the application process itself is no longer responding to the end-users, and debugging that process. And since very few businesses generate a cloud-enabled or web-scale without also generating data, there’s also the follow-on of the lifecycle management bill for that data. How do you do backups? Who’s managing those backups? When are they being triggered? How do you recover a backup resource if something happens that you find you need to go back into those backups and recover the system? How do you deal with the development lifecycle of making a change that could impact the data within that environment? The whole idea of break-fix.
There are a lot of conversations recently about repatriating services back to a data center. I’m going to put it into hardware that I potentially own. But I’m still likely paying somebody else for some portion of the management, the underlying concrete floors and walls and ceilings, etc., and probably the power system and the cooling environment to keep those systems running efficiently. There’s often a third party still involved.
Now, I’ve seen all kinds of calculations for the cost-benefit analysis of that, and in many cases, cost-benefit can actually lean towards saying, yes, go ahead and run this on your own. But there’s a lot that predicates that decision. And I would say the number one predicate is when I already have an operations model and a development lifecycle model that works with my own infrastructure and my own infrastructure management.
Containerization is Key
The number one way you can get there is to containerize your application. Even if it’s a monolith, containerize it. You do not have to break it up into microservices or do any other crazy thing to it. If it’s a monolith and it can scale on its own, in other words, I can run eight of these monoliths in parallel, or I can run four of them, or I can run one of them, then at least put it into a container that bundles the application and any dependencies it may have into one system.
Then look at how you would operate that containerized application. You’re still going to store data somewhere, and you’re potentially going to cache data and distribute data through a CDN. All of those things still apply. All of those systems still are part of your operational architecture. But you can at least get to the point of having a single blob that is your known good application. And the nice thing is that if you do a migration to a newer version, you’re not making a change to the underlying active infrastructure, you’re swapping one container for another. That also helps manage a huge context switch and a huge pain in the life cycle of a resource. I don’t have to rebuild anything from scratch. That build process happened long ago in the life cycle of my application. And even if I build a new version, it’s a whole entire new version, potentially built on the same platform, same core, but those new features are added on top of the system rather than being rebuilt entirely from scratch. And especially rather than being rebuilt entirely from scratch in the active environment where you are trying to recover from a failure, for example.
Containerization is, in my mind, the one equalizing tool in managing migration, regardless of direction. Even if you said, hey, maybe Google has given me a better deal than Amazon this month, and I want to move all of my applications over to Google. Great. Again, that’s a business decision. If you’ve containerized everything, if you’ve modeled everything on open concepts, open content, and open capabilities, then you should be able to migrate between the two clouds almost whenever you feel like it. Potentially you even have your application running in multiple clouds at the same time, truly dynamic environments.
Is There Actually Business Value in Moving Your Platform
But the more interesting case I think these days is people looking at the question of, “How can I manage my IT cost for the best value for the company?” It brings us right back to the concept of what is cloud value. So when we think about cloud value, think about just the infrastructure, the core resources and services, that we work with. That’s great and I get why we do that. That’s the bill that you get from Amazon. But we really need to look at the entire application life cycle relative to being deployed in the cloud versus being deployed in your own data center.
There are a number of companies that have come out recently and said, you know, by getting out of the cloud and going to my own data center, I have saved millions. I’m not saying that that’s not possible or even that that’s unrealistic. It’s probably a corner case. There are not that many people that are currently spending half a billion dollars a year in the cloud or even a quarter of a billion dollars a year in the cloud over a number of years to make that sort of statement viable. Although I’m sure there are some. I think we’ve seen plenty of news stories of companies that have spent $300 million or $500 million committing to Amazon. There are many more companies that are talking about $1 million, $5 million or even $20 million a year in cloud costs.
These are significant numbers, but the value proposition comes back to the question “If you spend $20 million in the cloud, do you get more than $20 million out of the cloud?” In other words, is running your infrastructure in the cloud the thing that’s sinking your ship or is there something else that’s causing you problems?
How is This Going to Work? The Process of Cloud Migration
Now we come to the other part of repatriation or migrating from one cloud to another. If we’re not already containerized, there is the cost and overhead of changing effectively your cloud platform or your systems platform, whether it’s cloud-enabled and therefore, hopefully somewhat automated at least. Or even if it’s not automated, but it still uses virtual technologies like virtual machines, virtual storage, and virtual network resources to make it easier to manipulate where in the overall system scale your application sits.
To me, the goal is to take your application where it currently stands and move it toward a platform strategy. If you’re doing serverless in AWS Lambda, maybe you want to move that to a serverless framework model, or better yet, a Kubernetes job style model, or even a container-based job style model as a way of simplifying that transition strategy from step B, which is you come up with a consistent model to get to a platform and then you migrate platform from A to B. The nice thing about that is that you actually have potentially better performance in all of the migration strategy steps except for that final transition from cloud A to cloud B or cloud A to data center B.
The other thing that we have available to us is this idea of network load balancing. And suddenly, if you have the right kind of network configuration between the old and the new target data center services, we can actually start doing load balancing between the old and the new. You can slowly cut over to the new system, run some additional tests against the active live new system, and make sure that the system continues to operate properly.
This of course requires that you have some kind of testing infrastructure in place. I know a lot of companies don’t, especially at the production level, they’ll do testing at unit tests and maybe there’s sort of a staging environment, but this is really sort of a blue, green, or even a canary-style migration from the current cloud into the new cloud. And you can do that through domain name changes. And those domain name changes, if you’ve done this right and you have both systems set up to forward properly, you can actually make those changes happen over time and yet still have the ability to fail back to the previous version if something doesn’t quite work right.
So there’s a lot of really powerful mechanisms for actually forwarding traffic into environments and sort of managing the lifecycle switchover from one system to another. I would say the one last thing that really is important in terms of making this kind of a transition successful and potentially making it repeatable is to ensure that your company has decided on and is either building towards or has already started building on a consistent application platform. Because it’s certainly realistic to think that the development teams want to use the best possible technology to build their application. But if you don’t have a platform model for how to implement that, that means that you now have operations that are all over the place, because you have to deal with every possibility of a developer’s model. And you end up with no consistency in terms of your migration strategy either, because now every application is slightly different.
In Summary
This article provides a comprehensive analysis of the factors that should be considered when deciding whether to migrate (repatriate) a cloud environment back to a self-managed or third-party-managed data center environment. It explores various perspectives such as the overall value of the application, the effort required to perform the migration, and the cost structure of the application relative to its revenue generation potential.
Robert suggests that containerization is the key to managing migration, regardless of direction. By bundling the application and its dependencies into one container, a single known good application can be created. This approach simplifies the migration process and helps manage the complex lifecycle of the resource. Containerization also makes it easier to migrate between different clouds, potentially enabling a single application to run in multiple clouds at the same time.
Robert emphasizes the importance of a consistent application platform to ensure a successful and repeatable transition. While developers may want to use the best possible technology to build their applications, having a platform model for implementation is crucial. This ensures consistency in operations and migration strategies, as well as avoiding the need to deal with every possibility of a developer’s model.