Ask the Expert: Azure implemention’s biggest challenges

Starting a cloud implementation is never a simple feat.

There are lots of questions around that people try to answer and a lot of doubt about decisions made. In this article, we’re going to highlight three of the main challenges you might face when starting a Microsoft Azure project, and look at what you can do to avoid them.

Where to start

The first decision has been made: the Azure cloud project will go ahead and people are excited, but what’s next? At the time of writing this article, there are almost 100 services available on Azure. So where does one start? Customers get overwhelmed by the possibilities of Azure and often struggle to understand how to begin their journey. So what is the first step? Plan ahead. Come up with a list of high-level tasks and focus on those outcomes.

No focus on a strong foundation

The excitement of the new Azure environment gets the better of people, and the main focus of people’s efforts naturally shifts towards the application or workload that is being migrated to or built on Azure. This makes sense, because it’s exciting.

However, the foundation gets neglected. Logging, monitoring, alerting, and security all fall behind over time. Deploying something into the cloud is not the most difficult task, but running and operating it, that’s a different story. And it’s also a story not told very often. It’s important to focus on a strong foundation that dictates patterns to consumers of the cloud environment.

For example, one pattern might be logging; dictating that metrics and logs need to be forwarded to a central Azure Log Analytics workspace for longer-term data retention. These patterns need to be able to be replicated by the consumers of your cloud environment. They also need to be well documented, and the documentation readily available.

A strong foundation will make sure that certain fundamental principles are being followed and standards are adhered to. This will make operating, maintaining and also troubleshooting a lot easier.

This doesn’t have to force your consumers into processes that do not fit them, however. It’s more about creating guidelines that are flexible enough to accommodate most use cases. A great partner along this journey is invaluable to make sure you get the foundation right and your house does not collapse.

No-cost optimization

We see the consequences of no-cost optimization all the time, especially when companies get help in to migrate lots of on-premises servers into the cloud. For example, when they decide to exit their datacenter doing so-called lift and shift migrations.

Lift and shift is something that sounds good on paper. “No change to the environment, straight copy of your VMs to the cloud.” Once companies get to the cloud and the environment has been running for a month or two the dreaded bill-shock happens. The promise of the cloud is quickly becoming a nightmare and the question comes up, “how do we get back out again?”. This does not need to be the case.

Lift and shift should only be a temporary strategy where you accept that you will likely incur a higher cost than if you had stayed on-premises. I personally like to propose something I call a “contemporary lift and shift”. With this strategy,  the process first needs to be automated.

Secondly, Virtual Machines (VM) will be right-sized during migration so that you only spend money for the compute you actually require, and lastly, Virtual Machines get “cloudified”. This means they are integrated into the foundation, complete with logging, monitoring, and alerting.

This also includes the addition of single VMs into VM Scale Sets that automatically heal themselves in case of failure—if that’s not possible, at least the Azure platform monitoring will alert us of the fact that something went wrong.

On-premises Virtual Machines are almost never shut down; because the hypervisors aren’t shut down either, shutting down the VM doesn’t save any money. In the cloud, you need to think about times where you can shut VMs down so that you don’t spend money unnecessarily. Cost optimization includes all of the above points, like being able to right-size your workloads, not just VMs.

Also, it also covers App Service Plans for your App Services, database SKUs on Azure SQL or hot and cold tiers on Azure Storage Accounts. Being able to automatically scale out (or up) and in (or down) in relation to demand is paramount to keeping your monthly spend under control: something else that is often overlooked.

For development environments, instead of using your “production” environment or shared subscriptions, why not have your teams use their MSDN credits? If this applies to your environment, then using those credits for development purposes is perfect, yet I’ve seen a lot of companies let those free credits go to waste.

If that’s not possible for you—perhaps you don’t have any MSDN subscriptions for your teams—then creating Azure Resource Groups for your colleagues, and assigning Azure Budgets to those Resource Groups, can help makes sure people stick to their budgets, making costs more visible and people more accountable.

Lack of automation

Although it’s not a new thing, automation still doesn’t seem to be very high on people’s lists when it comes to planning a cloud environment. It’s one thing to click together a few resources based on a “5-minute” read tutorial, but it’s a completely different thing to set up a multi-region architecture that’s supposed to withstand outages (planned and unplanned) anywhere in the system. Only a high degree of automation will help here.

Automation means leveraging concepts like Infrastructure as Code using Microsoft’s Azure Resource Manager (ARM) Templates or third-party tools like Hashicorp Terraform or Pulumi.

This can be quite a shift for cloud users: for a very long time code was only associated with software and developers, but nowadays, and especially in the cloud, it’s almost non-negotiable that the same concepts are applied to infrastructure as well.

Automation can also extend into the Virtual Machine’s Operating System to configure the runtime environment, and goes all the way to the automation of your Operations Team’s tasks.

VM and database backups are created automatically. Patches are applied hands-off (or maybe even not at all) and the VMs get replaced with a newly patched VM. Updates to the infrastructure must be applied via build and release pipelines, so that changes are audited and versioned.

Without automation, teams will always be busy with “unimportant” tasks. Automation will free them up to stay up to date on new features that the cloud offers, and also give them time to create more automation: if there’s an issue or bug somewhere, for example, then the fix should be automated so it will never have to be manually fixed again.

Embracing change

To sum this all up, it’s important to understand the different paradigms in the cloud compared to on-premises, and what it takes to change your environment and behavior to utilize the cloud as best as you can.

Automation is key; things will fail in the cloud, and only automation enables you to respond to changes in a timely fashion.

Cost is also a big factor, because whatever you do, cloud computing will incur cost straight away. Wastage should be avoided at all cost (pun intended). This ties back into your strong Azure foundation and your foundational principles.

In the end, I always recommend getting a good partner on board for the journey. Get excited and get started.