As an on-prem infrastructure guy, I am used to hypervisors, VMs, Windows server operatingsystems, IIS services, SQL instances and how to connect these components in a way that they can talk to each other. This means I did not care much on what the Dev guys were running on my servers, as long as it did not break any parts of the compute, network or storage stack, which was very unlikely based on the fact that these were standardized and tested services and software.
As I am moving towards the public cloud industry, it becomes very clear for me that I need to ramp-up on my understanding and knowledge of the application side of things. To understand the motivation and reasons to move to the cloud for different companies, I need to be able to see the daily challenges they are facing through their eyes.
The reasons behind a migration can vary heavily and should always be connected to a business and digital transformation strategy, since its the business and the vision of the future that should be the driving force for a cloud strategy and not simply the wish of “moving to the cloud”.
We might get a feeling of how different the reasons and cloud adoption strategies can be when we look at these three examples:
- A brand new startup development company with 15 employees that just want to code. No own hardware, no policies.
- A 2000 employee enterprise that invested big times in their on-prem infrastructure, legacy systems and integrations. Partly developing in-house, partly outsource their development.
- SMB with 200 users, no own development, on-prem servers for production systems, internal applications and collaboration.
Each of these businesses should plan and pursue a different path, that fits their business needs and strategy.
In my eyes SMB should in the future either invest into own in-house development and data analysis teams or run sole SaaS solutions in combination with a common cloud data and identity plattform.
There are four main migration scenarios, these will most of the time be a good starting point when we are talking with customers who want to migrate their application from on-prem to the cloud. The complexity of the migration strategy increases with each level.(Top to bottom)
Cloud migration strategies
Rehosting – Lift and shift
The easiest way for an application to the cloud. We take our on-prem resources and move them to their Azure counterparts in form of IaaS solutions. An example would be an web application with a IIS webserver and a SQL database server running either on a VM or a physical server(chances are high their are running on a VM in 2019+). With the “rehosting” approach we are migrating(converting) these VMs to an Azure VM running the IIS and an Azure VM running the SQL database server.
The customer gets all benefits of the IaaS cloud service model. A lift and shift gives the customers quick results but does not take further advantages of the cloud.
Refactoring – Adopt to PaaS
This strategy aims towards making use of the PaaS solutions available on Azure. An example would be moving the webserver part of the application to a App Service and the SQL database part to a managed instance of Azure SQL. Another option is to refactor the application to use containers instead of VMs.
The benefits of using the PaaS service model(apart from the lighter weight compare to IaaS) are the options to adopt DevOps practices, like the integration of IaC/Github and other automated deployment solutions.
Rearchitecting – Migration as an opportunity
When moving an application from on-prem to the cloud some customers might want to use this chance to make some major architectural changes. This could be breaking down the code into microservices and running parts of the application on kubernetes to allow for fast scaling and small, independent services.
Rearchitecting an on-prem application can be a huge project, that requires comprehensive planning and understanding of the new technologies like containers, microservices, kubernetes as well as the other compute, network and storage services available on the Azure plattform.
Rebuilding – Doing it differently in the cloud
To gain the most and real value out of modern cloud computing and for an application to become truly cloud native, parts or the whole on-prem application code and architecture needs a rebuild.
Morpheus got a point when we look at the cloud from what it physically is:
And as we saw with the lift and shift option, its totally possible to do things the same way in the cloud as we did them on-prem but the consequence will be an equal or more complex infrastructure that will most likely cost more money than before.
The real value of cloud computing platforms like Azure, AWS or GCP is the availability and plug and play possibilities of state of the art integrations and services, which were earlier simply not an option or very resource and time consuming.
By the time I am writing this article, Azure has over 600 services at their disposal, which are receiving updates multiple times a day and new services getting released on a weekly basis.
With an application power by the cloud, we could for example make use of serverless computing options, like Azure Functions or Logic Apps(no code alternative), this way our application can become event driven and integrations with other systems becomes easier. Serverless architecture focuses on the developer side of things, keeping infrastructure and management to a minimum, availability and scaling of resources happens automatically. Another example of why “the cloud is not just someone else’s computer”, is the fact that the average person does not have a PC locally in 140 countries and 54 regions across the globe. This fact alone does not add value to an application or business, but when we are starting to make use of a distributed storage service on top of this global infrastructure like Cosmos DB, we quickly begin to see the benefits and simplicity compare to operating multiple SQL cluster.
There is no “one fits all” approach when it comes to finding the right cloud strategy for a business. The business goals and digital transformation with their benefits, goals and visions for the future should be the driving force behind the journey to the cloud.