The Easiest Way Of Going Into The Cloud

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 the cloud pales compared 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 the cloud.

The why – why do we move to the cloud? – has been discussed, and its value is known to all. However, how – how do we move to the cloud? – is the thing we often get wrong. The question now becomes; how do you move to the cloud or, to go deeper we can ask – is there a right way to move to the 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 cloud migration. Shifting the focus towards architecture and design means there is less work on implementation. More importantly, 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 :

Traditional Cloud Migration
Language Migration
Structural Migration (microservices)
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 the 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?