Let’s take a closer look at some classic examples derived from real-life scenarios.
A. The dine-and-dash example
To kick off, a classic example is the dine-and-dash-scenario: An organisation migrated its on-premises virtual machines to Azure using a lift-and-shift approach but neglected to optimise for the cloud environment.
In this scenario, the organisation assumed that moving to Azure would automatically deliver the advantages of cloud scalability, flexibility, and cost-efficiency. However, the organisation overlooked the fact that its virtual machines were still using the same configuration and drivers from the local data centre, which were not suitable for the Azure platform. For example, some virtual machines connected to old storage or SAN devices that were no longer accessible in the cloud. This led to performance issues, increased CPU and memory usage, higher costs, and reduced availability.
This organisation shifted its problems to the cloud and ended up paying more to host them, instead of improving its infrastructure and fully benefiting from the cloud features. It should have assessed its virtual machines before the migration and made the necessary changes to optimise. This includes resizing, reconfiguring, updating, and removing unnecessary components. By doing so, the organisation could have reduced its operational costs, improved its performance, and enhanced its security and reliability.
The lesson: Don’t dine and dash, and take a look at the Cloud adoption framework for Azure (Microsoft Cloud Adoption Framework for Azure - Cloud Adoption Framework | Microsoft Learn).
B. The neglectful nanny example
We all know what can occur when you leave a toddler alone for too long: you might return and find your living room redecorated and repainted. It will be a funny memory later, but in the moment the experience can be quite different. The same applies to your Azure infrastructure:
Consider this: you have used the Cloud Adoption framework and decided to refactor parts of your solution to take full advantage of what Azure offers. However, the problem is that Azure evolves quickly, with new features being added every month. At Intercept, we often see organisations that carefully plan their infrastructure, deploy it, and then leave it unattended for several years.
The reason is simple: because the solution works, the organisation assumes there is no need to change the infrastructure. However, over the years, new technologies have emerged that would have been a better fit for your solution. By integrating these new features, you could have added more value, reduced operational costs, and made your CFO a little happier.
The lesson: Don’t neglect your infrastructure, as it just adds more technical debt to your backlog!
C. The responsibility dodger example
When you read up on public clouds, compliance, security, and service level agreements, you will encounter the term ‘shared responsibility model'. Unfortunately, not everyone reads about this, leading to situations where people mistakenly think that Microsoft or a partner is responsible for everything. Remember, these are “shared responsibility models,” not “shared accountability models.” In the end, you decided and clicked, so you are still accountable.
- For example, have you deployed an expensive machine and forgotten to turn it off? This can result in a shocking bill at the end of the month. You clicked it, so you are responsible.
- Was your application compromised? That doesn’t mean the cloud is insecure.
- Did you deploy that Web Application Firewall and configure it?
This highlights why we need to rethink ‘shared responsibility’. While Azure handles aspects like physical data centre security, you are still responsible for securing your solutions, monitoring costs, setting up alerts, and other measures. We should view the cloud as a tool that makes it easier to manage responsibilities. You'll soon find that taking on this responsibility can be quite rewarding.
The lesson: View the cloud as a tool that provides numerous features so that it is easier for you to take responsibility, but take that responsibility. Soon, you might find that embracing this responsibility can actually be quite rewarding!
Wrapping up
In this article, we explored three classic examples of what can happen if you leave your Azure infrastructure unattended for too long. We have discussed how the cloud requires us to take more responsibility for our solutions and infrastructures, despite the many features it offers to assist us. We covered Azure's shared responsibility model and the importance of security and cost management in the cloud.
To help you further, our upcoming articles will delve deeper into the technical aspects of these topics and provide practical examples of how to implement best practices and tools for cloud governance. Stay tuned!
