thinking aloud
Going Into The Cloud What is getting in the way of your migration to cloud? Come let us sit and reason together. The easiest way to go cloud is to adopt an already existing cloud solution. This, most commonly, has been through e-mail and document storage. Think Gmail and Dropbox. This small step into cloud pales in comparison to the monumental task organisations face moving their own applications to the cloud. Whether these applications are built in house or from a third party, the migration is tediously expensive, and often fails even though the applications do end up on cloud. The why - why do we move to cloud? - has been discussed, and its value is known to all. However, the how - how do we move to cloud? - is the thing we often get wrong. The question now becomes; how do you move to cloud or, to go deeper we can ask - is there a right way to move to cloud? The traditional model of cloud migration looks something like this; with a significant focus on the implementation and the rest split between architecture and design. This very model is why so many organisations now are feeling the cost and scaling burden while on cloud. It is why they are considering things such as hybrid solutions (mixing cloud and on prem). But, inverting the model gives us our priorities as it should be for a cloud migration. Shifting the focus towards architecture and design means there is less work on implementation. More importantly, that you can build something robust and malleable enough to change. With four main types of cloud migration, this model would work well on all the types: 1. Traditional Cloud Migration 2. Language Migration 3. Structural Migration (microservices)
4. Cloud Modernisation (serverless) Understanding the type of migration is essential to success or failure. An organisation may perform two such migrations together i.e., language and structural migration as a pair. Given that most organisations run monoliths on-prem before moving to cloud, their journey would begin with the traditional migration of taking a monolith to cloud. Then after having it on cloud, struggle to change it to modular monolith and to a microservice type cloud estate. This journey to cloud could be due to the size and complexity of the monolith, or not having all your dependencies ready for cloud. However, it can be overcome using MVMs (Minimum Viable Migrations). Traditionally, our migration to cloud was built on waterfall methodology and this also led us to using cloud with a waterfall mindset, no matter how hard we hid behind fancy terminology and team structures of agile. If your move to cloud was waterfall, you will operate as such. And this dooms you to the cries that ultimately follow stating cloud is not for you because it is too expensive, does not scale, and has become too complex and many more. A lot of reasons to leave cloud can be traced to having a direct link to how you moved into cloud. The goal of MVM is to migrate the minimum amount of data, applications, and infrastructure required to provide value to the business while minimising the risks and costs associated with migration. Combining this with an event-driven architecture to guide your structural migration also adds to the overall success of the migration. MVMs allow you to start small and scale the migration over time. Continuous design change will ensure you are
flexible enough to meet changes not as blockers, but as opportunities to optimise. A critical part of MVM is the bridge. This is what allows for communication between what you have on-prem and what is on cloud. The bridge allows a bi-directional flow of events between the domains and means there will be little need for heaps of data migration down the line. MVM also has a scoping phase that requires eight-week cycles to build, should have known ROI, should be injectable, should have known risk and dependencies and should relate to one bounded context. Yet another key component to this migration is understanding the effects of the migration to the organisations culture, people, processes, policies, and structure. If you think cloud migration is tech only, then you will fail when it comes to being on cloud. Cloud is best designed for the automation of processes. On cloud automation is one way to validate that you built for cloud, that you are utilising cloud, reducing risk on cloud and becoming a transformed organisation. An example is in deployment, automated pipelines for continuous delivery will have no need for a CAB (change approval board). If you have one, consider that a huge risk. Cloud migration is more like continuous delivery, an always ongoing task that strives to move from monolith through a few phases and end up at serverless cloud adoption (or whatever will come after serverless). Additional incorporation of game development pipeline (such as vertical slices) also adds value to cloud migration. With these tools in place, the question that remains for you should only be - what is your barrier to cloud adoption?
www.cioafrica.co | MARCH-APRIL 2023 | CIO Africa Magazine | by dx⁵ 27
