28. July 2021
by [Michael Frank]https://github.com/Michael-Frank/) | 1288 words | ~7 min read
In a time of rapid technological change, decision-makers in companies are often confronted with the challenge of future-proofing their existing applications and systems. This article is aimed in particular at technical and business decision-makers whose applications and systems are still predominantly running “on-prem”, i.e. in classic operation, and are not based on mainframes. Are you driven by the need to migrate your applications to stay competitive? If you’re looking for a guiding perspective in this migration dilemma, you’ve come to the right place.
In this article, we delve into the “bottom up” perspective and show why it not only makes sense, but is actually necessary, to make applications and systems “cloud-ready” - regardless of whether your organization has already made the leap to the cloud or whether that move is still in the planning stages.
In particular, we point to the migration strategy we employed in the LEAP project and why refactoring, even to a limited extent, can be crucial.
Ideally, business has a good cloud strategy and strong commitment pushing the cloud move “top down”, and at the same time from the “bottom up” all technical teams have an equally strong desire to leverage the offered technical and organization benefits if cloud technologies.
However, there are 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” strategy for their cloud platform in place, 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 in a Q&A Style.
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 on the best course of action. Sound familiar? Good, then this section might be for you.
Why not take the chance to refactor the applications right 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 an existing application can be economically adapted to run on a cloud platform. However, it 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!
but 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:
Migration teams are encouraged to exceed this baseline if possible within the frame of the migration. New applications are build cloud-natively. With cloud-friendly, the focus is on the outcome: Secure applications that can be maintained and operated easily.
By following them early you can avoid doing work twice/wrong! But that’s not all:
Sounds nice but…
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:
Trivia: k8s vs kubernetes - never dared to ask? the developers thought the word “kubernetes” (ancient greek for “helmsman”) was too long in everyday life. Just leave out the middle 8 letters and replace them with an “8” and you get K8s.