This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
You have your first Cloud Adoption Framework “Landing Zone” set up in the Azure cloud. Congratulations, your technical life will never be the same, and the sky is the limit to what you can now do. Having all the possibilities of the cloud, however, can be daunting. Like a cat at an open door, you may hesitate. Left paw first, or the right one, or simply jump right out there? Maybe just stay inside.
Now you must choose how to make your approach to the Cloud with the workloads in your portfolio. I assume you can choose between different workloads and timing, not limited to only very few workloads, and are not for example under an extreme time pressure that will force you to hustle with all you can muster into the cloud. You are reading this because you are about to select the optimal workloads suitable to start your company out and up into the cloud!
It is important to note that, although your company technical lead or cloud architect is heading the selection process, additional people in your company should be involved. Your business owners know the priorities for the current and future business both outside and in the cloud. Security officers may insist on moving data at a certain cadence, aligned with specific regulations. Even the HR department – often overlooked – might need to get involved. Why HR? If the first workload you migrate to the cloud is lacking cloud-experienced engineers on the team, it could impact the speed and accuracy of the ascent, as well as the attitude in your company regarding continued migrations.
There are multiple considerations to make when selecting your first workloads to go to the cloud:
- Technical complexity – I recommend selecting something non-trivial, but also not the most complex solution you have! Pick something that you believe technically can have a start and a finish quickly, and that does not depend on complexities such as data access over a hybrid connection! Something less complex is the public corporate web site. It is not the most exciting application you have, but it is one of considerable value to the business. Stay away from using your core business application, with dependencies on other services in the company, as your first workload that goes to Azure. You want to start modestly and make sure you have something real running on Azure that you can measure for performance, and cost.
- Security – Choose if you can, applications which have few users, or only internal users. Internet facing applications, with complex user access control, are technically more difficult to get right, and if migrated badly will cause a headache in your security department in the future!
- Data complexity – A less data intensive application, where all the challenges of data compliance (personally identifiable information or sensitive data) is not the first thing with which you must deal!
- Skills – Where do you have your rising cloud stars among the engineers in the company, and can you pick one of their workloads first? Any team with members that have previously used Azure or have someone Azure certified is a suitable candidate to start with. If your company does not yet possess any cloud experienced engineers, I self-servingly recommend taking your first workloads to Azure using advice from a cloud professional consultant. Initially in the cloud there is an abundance to learn. A focused investment in experience will pay back manyfold. Great engineers will eventually find a way, but engineers experienced at the task at hand will go more straight for the goal, faster. Your HR needs to be involved if your company is attempting a cloud ascent with no real cloud experience on staff!
- Cost – Your organization needs to learn what Azure costs compared to pre-cloud IT budgets. Costs depend on level of auto scaling and other factors. If you can choose initial workloads that have medium complexity in terms of number of Azure resources and user scaling demands, it will make it easier to put financial controls in place.
- Business value – If you migrate an application first that nobody in business cares about, you mind as well, in their eyes, not have done it at all. Pick something that matters to key people first!
- Good model workloads – Workloads that go first to your cloud will serve as models for the batch of workloads that comes second. Consider elegance in the application and how easy they are to explain during show and tell. Maybe, do not choose Kubernetes or Machine Learning data platforms. Choose something that is easy to explain, where you can map applications clearly to Azure resources and show a solid set of basics for your future cloud adopting teams!
No matter which workloads go first, there is value to achieve from the initial migrations. You should take care to establish your key business cloud metrics that you can show to less technical managers. Non-technical folks (muggles) need something visual that excites them so that they understand that something is going on and can follow along. “How many workloads have we now migrated?” “How many new customers are using our cloud services?” It must be something/anything that matters to them. This helps with retention from C-level. Financial operation is another key. Satisfy “the bean counters” in your company with important numbers. You know the Excel-people. “How much is Azure costing month over month, and what is the consumption trend?” If you cannot demonstrate that you are in control of “how much,” you will come to rue the day the CFO comes knocking at the door of the development department fuming with a printed Azure bill in hand. Satisfy key stakeholders from the very beginning and they will not disturb you when you continue your technical Azure ascent!
As you work through this list while selecting the forerunners that blaze the path for your company service ascension to Azure, you need to decide what is the most prioritized consideration that apply to you and align your workload prioritization accordingly. I am sad to say that including technical stakeholders in the inception stages of the initial strategic planning when company suits decide to go to the cloud is not as commonplace as it should be. Make sure to align the strategic reasons “why” with the technical “how”! Head over to the Cloud Adoption Framework and delve into the Strategy and Plan sections before you proceed. Corporate reason for being in the cloud – your cloud strategy, and the method of approach – your plan, must be in good order before you actively adopt too many workloads into the cloud! When strategy and plan are in order, it becomes clear which important first cloud metrics you must establish as the first workloads go online! To better understand how key metrics in Azure work, and how to integrate them in your pre-cloud applications, please investigate the Well-Architected Framework, which has lots of references, guides and examples on how to configure your applications for reliability, cost optimization, operational excellence, performance efficiency and security. Exactly what metrics are the most important to your organization will vary based on your mileage. Let me give you a couple of real-world examples to highlight what I mean.
Recently, my firm was guiding a Cloud approach for a company that just had a security breech and had suffered data loss. It is so interesting that today companies consider a cloud first strategy to increase their security posture. I remember the early days of Azure, when Azure was “Windows Azure,” relevant and major objections from SecOps. Security was an adoption blocker. The Cloud was not compliant enough or proven to be secure enough. Today we experience the inverted argument – a move to the cloud increases security. Their number one, uncompromisable requirement was therefore security. We ended up putting extra effort into strengthening the cloud security skills of their IT department, and we did multiple reviews on their security. What was then critically important was to wire up the right security alerts to an active 24/7 monitoring call center, should an attack or security anomaly ever occur.
In another customer case, they started out toward Azure with a quite limited Azure budget. In this situation we were looking to generate buy-in from the business. They needed to get a couple of solid POC applications running in the Cloud, show the value and cost management, and then expand from there. While I very much appreciate that budgetary concerns sometimes must be a reality, it is worth mentioning that approaching the Cloud this way is an initially terribly slow process. You need to build an end-to-end full solution in the Cloud for the initially selected workloads, while ensuring – and proving, that the workload cost profile is optimal. It is a great learning for the teams involved in this initial cloud journey, because they learn so much about the Cloud, auto-scaling, good architecture, by being extra thorough to begin with. For this customer, the focus was on cost analysis and performance optimization.
Regardless of what metrics matter the most to you, future workload migrations and future innovations in the Azure cloud depend on how you select, and how you measure and report on the first workloads. Your second batch of workloads will follow the same ascent up to the mighty cloud above. Good luck!
About the author
Magnus Mårtensson is a Microsoft Azure Most Valuable Professional since the start of Azure, and MVP of the year in 2012. Additionally, though he does not work for Microsoft, he holds the title Microsoft Regional Director, which means an exceptionally close business relationship with his partner Microsoft. He is a consultant, architect, and product development lead, and an international speaker traveling the world to teach, network, learn, and experience. Passions include connecting with audiences, organizing online and global conferences such as CloudBurst and GlobalAzure, tasty food and wine, and great company. Topping it all is mind-sharing, so come over at a conference and say hi!