Part 3. BUILD: Magnus Mårtensson, Azure MVP, Microsoft Regional Director, and Chief Product Officer of Devoteam M Cloud Denmark guides us through the phases of the Microsoft Cloud Adoption Framework and gives advice on best practices, how to keep innovating, and dos and don’ts for your company’s Cloud Adoption Journey.
We aspire for innovation and deliver excellence in the Cloud. In this four-part series of articles, we interview Magnus Mårtensson on Microsoft’s Cloud Adoption Framework (CAF).
The Microsoft Cloud Adoption Framework for Azure is a comprehensive source of guidance and information on how to PLAN, ADOPT, BUILD, MANAGE, GOVERN, and INNOVATE in the Cloud. The framework covers the Cloud Journey from both technical, financial, HR, and innovation perspectives. Because CAF addresses general concerns, tips, and processes, it is just as relevant to use as a guideline for experienced Cloud users as for novices who are just starting out.
As Magnus says, CAF is a “wealth of information”, but it can also be “overwhelming and difficult to relate to”. In these four articles, we try to make that easier for you: we tackle the central phases and points of CAF and ask Magnus all the questions you want answered if you are trying to excel in the Cloud.
This week’s headline is BUILD because constructing, managing, and governing your Cloud environments according to best practices and with innovation at the forefront is key to doing Cloud Adoption right. The success of all Cloud Journeys revolves around a gradual and carefully executed Cloud Adoption. It is a continual process that must include and consider all parts of the company – from finance over HR to, of course, the IT department – to realize the full potential of the Cloud.
Laying the groundwork before takeoff to the Cloud
In the first article in this series on the Microsoft Cloud Adoption Framework, we covered what to look out for when defining a STRATEGY for moving to the Cloud. This includes understanding the strategic, financial, and technological motivations for making the transition, the expected business outcome, and carefully selecting the first adoption project. Magnus also gave advice for the PLAN phase, which consists of getting an overview of your digital estate, making a full Cloud adoption plan and a skills readiness plan for your employees, and aligning with the rest of the organization.
The second article covered the READY and ADOPT phases that deal with the company’s first real steps into the Cloud and with making good practices for Cloud adoption and innovation. These phases also aim to provide respect for the scope of the digital transformation – including an understanding of the potential upskilling process for employees used to working on-premises and the potential for innovation in the Cloud such as automating and using platform services instead of hosting applications yourself. Lastly, this third article will cover how to then build securely and sustainably in the Cloud and how to manage and govern Cloud environments and operations.
A big part of the best practices for management and governance is laying your groundwork well. It is hard to operate something that is poorly built or planned for. Likewise, good IT governance requires continuous awareness of security procedures and potential risks, optimization of processes and systems, and a stable framework built on careful tests with a Minimally Viable Product (MVP).
How does one do management and governance right? In addition to advising for a gradual Cloud adoption, CAF recommends assessing the risks, timeframe, demands, and rewards of each project individually (while keeping an eye on the big picture) to predict the outcome and act according to it. As highlighted in the first two articles on CAF, good Cloud adoption involves the entire organization. This means that the business plan should be at the forefront of the minds of the IT employees just as the finance department should be aware of the reasoning behind the decisions made by the IT department and so on. This heightens understanding and trust in the digital transformation process and makes it easier for the organization to adapt to the change.
The challenges with Cloud operations arise the moment your organization starts moving to the Cloud. For Magnus this is a problem with several meaningful solutions and potential pitfalls. Firstly, experienced and skilled Cloud operations staff is hard to come by, whether they are in-house employees or external resources. The key is either finding people who can set up good monitoring and be responsive when problems arise or training your existing staff to do the job.
Secondly, teaching staff to set up proper and stable tagging and maintenance procedures in the Cloud is essential for the innovation and automation potential of Cloud solutions. Magnus recommends taking advantage of the resources Microsoft already offers, such as the Azure Monitor to assist the operations team: “Every individual Microsoft service used to offer its own monitoring abilities. Now it is all gathered in a shared service: Azure Monitor. Monitoring is a key point of understanding the Cloud – and all monitoring and alerting capabilities, all of the auto scaling, the ability to monitor network traffic: it is all in the Azure Monitor box”.
“Success is the worst thing that can happen to your application”
While it might initially be hard to understand why the day-to-day management, monitoring, and operations are so important in the Cloud adoption journey, having proficient and proactive people in those fields is also what can make Cloud worthwhile for the company. Magnus explains it like this:
“Good staffing in operations is one thing, but there is also a central technical challenge here, even though it sounds like a joke: What is the worst thing that can happen to your applications? Surprisingly it is in fact success! Your application was built with a certain number of users in mind. When it crosses that threshold and becomes an internet hit, you suddenly have problems you never thought you could have. In this way, success becomes the worst thing that can happen for your application, because it wasn’t built for that kind of scalability. It was built for the frame of reference you had when you designed it”.
Therefore, the company must have architects skilled enough to build scalable Cloud architectures, “so that you can become a roaring success, make a positive impact on your business, and service tons of happy users”, as Magnus adds. From a monitoring and operations standpoint scalability means continuously tweaking and improving and fixing and being attentive to the Cloud environments and services on a day-to-day basis.
Otherwise, the fast business opportunities and flexibility that Cloud solutions can provide will stay missed opportunities. And you want a spike in usage on your applications to be a good thing. Magnus paints the picture: “Suddenly an influencer referenced your app and everybody wants to see what it’s about. That can be a good thing if we can accommodate the traffic. However, if the new users arrive at something that is down or broken because it responded badly to the workload, it is not only bad for business in general – but a huge missed opportunity to improve and scale”. If you cannot architect for scale and maintain your scaling balance, you either have dissatisfied users or pay too much money on your hosting bill. The trick is to continuously balance this in your operations team.
Your company must “architect for that”, as Magnus says. It is a part of being innovative, forward thinking, and learning to take advantage of the Cloud. At the same time, if the Cloud architects build something that can service a varying workload, the operations team must be able to take advantage of it and be ready to scale at the opportune time. The respective teams involved in the adoption process all need to be sensitive of potential possibilities, risks, and opportunities. “They’ve always needed to be – but now there is just more elasticity and other levers to pull – you have more options in the Cloud”, Magnus adds. In this way, great Cloud Adoption is also clear communication, knowledge sharing, and cooperation across teams and areas of expertise.
Nobody should panic when we hover over the ‘DELETE’ button
This ‘translation’ of opportunities, risks, and possibilities across the organization also comes into play when talking about costs and budgets. “In the beginning of the Cloud adoption journey it is hard to plan for the costs”, Magnus explains, “but that can be a strength if you understand how to take full advantage of it”. As you get better at working in new and innovative ways in the Cloud, you also get better at predicting costs and cutting unnecessary expenses off.
Magnus provides an example: “When trying to optimize and harness the potential of the Cloud, you might want to automate building and deploying automations. It is possible to set up a test application to run all scenarios and then delete it. We must make sure that the code is functional – that it builds and deploys like it is supposed to. If it doesn’t work, we of course need to fix it! But all those tests cost a little bit of Azure resources, and those can add up. When the finance department comes knocking, people tend to start thinking creatively. For instance: Why would we pay for Azure development resources when we aren’t using them? If I can remove that cost over the weekend, the night, or over the holiday when nobody uses them, and be in control of what resources we are using, then I can focus on automation, building deployments and automation scripts – and that is empowering and valuable for the organization”.
Often organizations are in the opposite situation, Magnus explains. They are used to a lot of applications just being set up and left running because everybody is afraid of not being able to set them up from scratch again: “If I go to a customer as a consultant and hover with the mouse over the delete button for the testing environment and the IT employees react by freaking out and saying: ‘No, no! Wait – don’t touch it, we set it up exactly the way it needs to be!’ then they probably haven’t automated enough. If, however, they say: ‘Yeah, whatever, just delete it – I’m just going to run this pipeline over here and get the testing environment back immediately’, then they probably have automated at a sufficient level”.
Cloud Innovation requires skill, dedication, and persistence
If your workforce and organization has taken advantage of the automation potential of the Cloud fully, then it is possible to scale and add costs when you need more capacity and remove costs when you’re not using the extra capacity. That requires a lot of skill and experience and, typically, Magnus adds with a half-smile, most organizations don’t bother with the fact that their development environments have costs over the weekends until the Azure bill is growing and the finance department demands an explanation.
Trimming costs under distress is not optimal and instead, according to Magnus, companies should begin their Cloud Adoption journeys with an innovative optimization mindset. Such a practice is even encouraged by Cloud providers like Microsoft, he explains: “Even if Azure is infinite for you, the customer, as long as you can pay the bill, it is not infinite for Microsoft. The datacenters are a finite resource – if Microsoft can fit a larger number of paying, satisfied customers using the right amount of Azure into their datacenters, then that is good for them. Microsoft can have more customers – and the customers are in turn satisfied with how cheap and effective Azure is”.
Over the course of these three articles on the Cloud Adoption Framework, or CAF, as it is popularly known, Magnus has taken us through the key points of the framework: STRATEGY, PLAN, READY, ADOPT, GOVERN, and MANAGE. We have talked about common mistakes, solutions, and best practices – and a couple of things have been made very clear: when you are launching into the Cloud being innovative pays, good preparation pays, and having skilled people with knowledge and experience of the Cloud adoption process at hand pays. Excelling in the Cloud requires forward-thinking, strong communication across the organization, technical expertise, willingness to learn, and courage to change the way we work with and think about IT.