Azure Architect: Right Azure Architecture First Time - Deploying and managing cloud solutions

In computing, the term "architecture" refers to the high-level structure of a system. This can include the overall design, the individual components and how they interact, and the principles that guide the design process.

When it comes to cloud computing, Microsoft Azure architecture is particularly important. This is because Azure provides a flexible and scalable platform that can be used to build a wide range of applications. By understanding Azure cloud architecture, you can make the most of this powerful tool and create an Azure deployment that is best suited to your software application and how it needs to function. Furthermore, good Azure architecture can help to improve performance and reduce costs. As such, it is essential to make the most of Azure to have a clear understanding of its architecture, and how this applies to your applications.

Azure architecture: Cloud Components - Over simplified

Any Azure deployment has four main elements:

• Compute - Compute is responsible for running cloud applications and services. It provides the CPU and memory resources needed to run these services.
• Storage - Storage is responsible for storing Azure cloud data. It provides the disks and databases needed to store this data.
• Networking - Networking is responsible for connecting Azure resources to each other and to the internet. It provides the routers and switches needed to connect these resources.
• Wrapped services - An example of this would be Azure SQL where it is a bundled service of an application

Together, these services provide the foundation for any cloud solution. And when they are chosen incorrectly from the hundreds of options available, they can cause you no end of problems.

Many issues that you experience in your Azure deployments can often be tracked back to decisions that were made at the start of your move to the cloud or are inherited as constraints from your on-premise set-up. Often there are several paths to resolving these, but not when you are not sure of the root cause or Azure is blamed as the problem.

The types of problems that you experience will usually be grouped into the following areas:

• Azure cost overruns: The architecture in place does not scale or requires a much larger spend than expected when scaled up, monthly costs are unpredictable and much higher than expected
• Unexpected Costs: Over time you get spikes of the cost that run up and down and you are not sure why
• Static architecture: Your architecture is static and doesn't scale up and down with demand (Sometimes when an app is 'lifted and shifted' this is a real problem as it all runs on one VM or one service or it requires too many
• Performance bottlenecks: This is one we see a lot, and often more resource is thrown at an application to make it viable. This then has the knock-on effect that it solves the performance issue but kills the IT budgets. We once worked with a customer who had budgeted 20k per quarter and was spending that a month and couldn't find the root cause for the scaling issues
• Security issues and maintenance: This often comes up ISVs when shipping updates and trying to standardise environments, as well as ongoing maintenance overhead and the day-to-day, being more resource thirsty than expected
• Stability: The platform often has glitches in performance, and scaling up the resource doesn't make these go away
• Migration path: The migration path chosen for moving from on-premise to a cloud model had to leave some legacy pieces as they were. Those constraints can often turn out to be more of a concern than expected

Most of these issues come back to elements of your Azure architecture but knowing this and doing something about it in the real world are two different things.

This area is more to do with how Microsoft as an organisation has traditionally operated. Over the years Microsoft has built a partner community that then resells Microsoft licences and solutions. When Microsoft move to the cloud, they implemented the same model with kickbacks to gain market share quickly, unlike Amazon AWS which didn't have the legacy of a partner model.

This has meant that the actual way you procure Azure has several different options rather than just buying direct or through a tier one distributor. For example, through a partner or hosting provider on a CSP agreement or not.

We have written an article about how this works and it goes through the ins and outs of this and the impact it can have on your business. It also looks at what Microsoft has done to remove the locking to a particular partner.

This area will probably not be the main cause of your Azure issues, but it can have an impact on how / who you work with to fix them and what your options are for approaching changes to your Azure tenant/deployment.

When you encounter an issue with your Azure architecture, the first step is to break down the problem and identify its root cause. Once you have a clear understanding of the issue, you can begin to explore potential resolutions.

In our experience, 9 out of 10 customers we have worked with have been able to resolve issues by making changes to your existing infrastructure. For example, you might need to add additional resources or modify your networking configuration. However, in some cases, it may be necessary to completely redesign your Azure architecture or carry out work on your software application.

In all the time we have worked with Azure we have always been able to have a significant impact on Azure issues just by getting back to the basics of how Azure is meant to be used and its architecture best practice.

By working with cloud management software, you can ensure that your new architecture is well-designed and fit for purpose. With the right planning and execution, you can resolve even the most complex Azure architecture issues.

Addressing the most common architecture and deployment issues in Azure:

• Azure cost overruns: Collect and analyse a baseline of cost data and identify where the spend is going, often there are elements of Azure used which are overkill for purpose. For example, storage is one area that is often over specified, for example, P1 to P3 storage gives different levels of performance but needs certain classes of CPU or VM to get that performance. Matching the different elements properly often saves a lot of money.
• Unexpected Costs: Spikes in cost can have a number of root causes but can often relate to peak usage or the way that your software application processes data requests. For example, one of our customers changed the way they processed things and reduced their app processing costs by around 30%
• Static architecture: CloudOps will analyse your architecture and then make suggestions about how this can be auto-scaled up and down to meet your projected high demand periods
• Performance bottlenecks: An example of this is when the load goes onto the system you do not get the performance expected. This is often due to components used not behaving as expected, due to other constraints, like the storage example above. Often things like this can be diagnosed and fixed quite quickly when CloudOps is hooked up and analyses an environment.
• Security issues and maintenance: This is often not given the time it needs. CloudOps provides maintenance routines and backup services as part of the unified cloud management dashboards.
• Stability: The way the Azure deployment scales or doesn't is usually the root cause. Do you have multiple web servers, or just one hefty server? Can you spread the load across multiple back end services. Or are you running in only once region and suffering from latency issues.
• Migration path: This area often leads to issues that will need your development team to look at and then put in stages of redevelopment to resolve. To justify this investment you will need to have a good understanding of how much of an impact this will have once development is completed, so you will need good estimates for revised Axure costs. We have written a piece about getting accurate estimates out of the Azure calculator.

Most organisations go wrong by treating their Azure architecture as a one-off exercise. This means that most organisations get something running in Azure and then largely leave it to run. This can be a costly mistake and you can end up having bouts of firefighting and taking more time than planned to resolve Azure issues as they crop up.

The Microsoft Azure platform and the service offerings and configurations change over time, so your architecture needs to as well. There are so many changes that could impact your deployment coming out at such a frequency that it is difficult to stay on top of them and assess them, this is where Azure management software comes in.

CloudOps continually monitors your environment and your workload's health and cost and then uses machine learning to generate recommendations about how it can be optimised. This along with support and advisory services allows you to stay on top of an evolving platform without the expense of consultants or extra team members focused on this area.

Or you can try to get the same result by using Azure consultants, but that has its own challenges which we have broken down here.

Software as a service (SaaS) businesses can use Azure's pay-as-you-go model to quickly respond to changing demand. Azure's architecture provides the flexibility and scalability that software companies need to be successful. As you add customers you can scale up your Azure architecture as needed. At least in theory.

Often this starts to become a job in itself and stops you from being as agile as you would like and then distracts from your roadmap for your software. This is why many of the companies we work with are automating their operations management and moving to a NoOps model. To find out more about how CloudOps can facilitate this, read our full-length article. Moving this way can help an Azure DevOps-focused team move away from being distracted by infrastructure issues.

The counterweight to this is that more than one company we have worked with was seriously considering staying with a hosted data centre approach. This has almost always been due to Azure cost concerns and problems budgeting for Azure spend. Once CloudOps has had a chance to run over their Azure deployments they have then been able to get the cost/performance balancing concerns resolved.

Our unified cloud management platform CloudOps has been developed with all of this in mind to help you get to the root of any architecture problems. But also to stay on top of changes as the platform and your software evolves.

CloudOps includes:

• 24/7 assisted support
• Single pane of glass dashboards
• Cost analysis and reduction recommendations
• Licence / Risk registers
• Monitoring with fault find and fix
• Automated backup
• Automated patching and maintenance

On top of that, we also provide you with a technology adoption manager who will learn your business inside out, as well as advisory services, guidance, and support. So book a test drive and see how CloudOps can resolve your Azure issues and keep your Azure deployments on track.