09. November 2023
by Michael Frank | 1165 words | ~6 min read
As we have stated before, there is only one way to do cloud migration properly: Linking business and technology
But how do we get there: What if business and technology is currently in linking phase? What are proven strategies and tips on the way?
Ideally, business has a good cloud strategy and strong commitment pushing the cloud move “top down”, and at the same time all technical teams have an equally strong desire to leverage the offered technical and organization benefits of cloud technologies from the “bottom up”.
However, there are also many “bottom up” cases, where teams are pushing to the cloud before strong business commitment is there. And there are cases where companies have a clear “top down” cloud commitment, but lack adoption of their cloud platform and struggle to find a good strategy to move over their legacy landscape.
We will look at both cases and show what has worked for us and our customers.
Doing “bottom up” migrations, the teams usually have a lot of questions and “What-Ifs” in their mind. Let me try to tackle some of them.
Imagine your company announced “Hey, we will (probably) moving to the cloud (soon / once its ready)” and your team is sitting on some not-so-cloud-friendly applications that need some love and polishing to keep them maintainable anyway. So now you need to decide what to do. Sounds familiar? Good, then this section might be for you.
So why not take the chance to refactor the applications now, and on the way also make them cloud friendly?
Safe harbor statement: We are strong believers in the cloud-friendly (or Lift and extend) cloud migration strategy, where existing applications can be economically adapted to run on a cloud platform and the focus is on the outcome: Secure applications that can be maintained and operated easily.
However, cloud-friendly is not a one-size-fits-all solution, and there are other migration strategies that may be better suited for your specific application.
You may ask: But my companies cloud platform is not available yet or still in flux. Cant I just wait?
You could, but you probably already know your companies cloud platform is very likely to be at least some kind of “container runtime” or better “some sort of kubernetes” being it on-prem, public cloud, or managed or in-house.
Targeting Kubernetes is a sane choice!
And leveraging cloud design principles are beneficial for any runtime! So it makes sense to implement them as early as possible and is usually faster than expected.
The cloud design (and migration) principles are:
Implementing the infamous 12 factor principles
Elimination of toxic dependencies
Proper isolation of state
Observability and diagnosability
Shifting Security to the platform where possible
Teams migrating their applications, are encouraged to exceed this baseline if possible.
By implementing the cloud design principles early, you can avoid doing work twice or worse, doing it wrong when migrating to the cloud!
But that’s not all:
New applications should be build cloud-natively, fully leveraging the Cloud-Platform features.
Sounds nice but…
“where do i host my containers if the company platform is not ready?”
Maybe you can use a managed kubernetes from a public cloud provider. And dont be afraid to host your own kubernetes. There are awesome distributions for each usecase. e.g. coming from a single host world, or maybe some small shop floor on-prem system? Why not microk8s? Unfortunately listing them all and their use cases would go far beyond the scope of this article.
“i don’t need Kubernetes”. Containerizing is almost a must, as it allows a better Plain Docker is dying, swarm is dead. At some point, we had to go against the flow and its painful, as you are forced to solve many issues where K8s and its ecosystem already have ready to use solutions. Kubernetes is todos standard for running containerized applications.
Top down, the business goals and constraints of the migration must be clearly defined. Typical goals are:
Our approach: Transparency, Good Planing, Stakeholder management and Migration Industrialization as a Service:
Ever wondered why kubernetes called k8s? Developers found “Kubernetes” to long and shortened it to “K8s” by replacing the middle 8 letters with a number.