Cloud Transformation, Cloud Apps, and… LEGO?

When moving an application to the cloud, with cloud transformation in mind, it can sometimes be overwhelming. Like a complex Lego set, sometimes the best way to tackle it is to look at each component separately and then bring them all together, as explained in this article.

I remember a distinct Christmas morning when I was a child. I had wanted this spaceship Lego set and I may or may not have gotten a hold of the wrapped box to try and ascertain if that was indeed what was inside. I went to bed excited for the morning with the hope that I was right. 

I was! 

There was the massive frozen planet spaceship in all its glory. I excitedly opened the box and then paused… that was a LOT of pieces. So I pulled out the instruction book. That… was a LOT of pages. 

One of my parents took a look at the instructions and noticed that it broke down the spaceship into five components. They told me to just take it one component at a time, so I did. After all five components of the spaceship were complete, it was easy to see how they all fit together into a single unit.

When moving an application to the cloud, especially with cloud transformation in mind, it can be difficult to see where to start. Instead of looking at the application as a whole, break it down into its component parts and apply the concept of cloud transformation to each component. Just like the giant Lego spaceship, we know that all of the pieces go together. 

This is not to say that we don’t have to take the whole architecture into account (we do) but we can explore our options at the component level while we explore the whole. Complex applications can make this more challenging but the principles used for a simple application migration can be applied even to complex ones. 

Using our Lego analogy, each of these components can be tackled one at a time for cloud transformation alternatives. Each needs to be evaluated independently to some extent based on your business needs. In some cases your component migration will involve less transformation for business reasons, and for other components you may end up re-thinking its operation entirely. 

Let’s take a quick look at a database. Below are several, but not all, of the different types of database services offered in Azure. Each of these services tackle database technologies in different ways.

We may decide to do a direct migration from one technology, on-premises, to the same technology in the cloud (for simplicity’s sake). We might also have additional reasons, for example our database engineers may not need retraining immediately. Ok, great! If these business reasons make this decision a priority then it informs how we look at our next component. 

We need to make sure that whatever we choose for our API and frontend can work with our database decision. This is how we keep the whole in mind while dealing with the component. I could have built my spaceship components in different ways, but then there’s the risk that it might not have come together in all its spacefaring glory had I done so.

If you’re thinking about migrating an application to the cloud, don’t worry, our new course Moving An Application to the Cloud with Azure is for you!

We hope you’ll take a look and that it helps get you started.