Over the last few years, all the major cloud providers produced a lot of extremely useful and extremely valuable informational materials. Yet, in our on-going goal of achieving a high level of abstraction to make our information more comprehensible, we are frequently missing the simplicity of the explanation. The Azure Well-Architected initiative helps to address this gap by providing tools, programs, and processes that are based on a common framework, called the Azure Well-Architected Framework.
This framework focuses on architecting workloads that meet reliability, performance efficiency, security and cost efficiency guidelines for a particular workload type. All workloads have application logic, infrastructure, and data services components that are described within the Well-Architected Framework. This blog post and two follow-on posts will dive into the data services component.
The Frameworks
Before we go into architecting principles of the data services layer, let’s first take a look at the overall set of prescriptive guidance offered by Microsoft.
Microsoft recently converged on a few key concepts: Cloud Adoption Framework, Azure Landing Zones and Well-Architected Framework.
- Cloud Adoption Framework (aka CAF) – a set of guidance documentation that helps to envision, plan, architect and build the solutions that you need in the cloud.
- Azure Landing Zones – templates or a “lay of the land” patterns that help to accelerate adoption and deployment of cloud solutions by following best architectures and deployment practices from security, networking, scalability, identity, data store and data consumption perspectives. The broad variations of possibilities and individual tailoring of customer solutions to better align with their needs is achieved by the modularity and decoupling or the implementation from the design principles. Of course, there are also Application Landing Zones.
- Well-Architected Framework – guidance that addresses critical questions that contribute to 99% of the success of any solution:
- Did we build what we intended to build?
- How well does it work? (does it perform, does it scale)
- Is my solution secure?
- How complex will my support and operations be of this solution?
- How much will this all cost?
The solution is successful and sound if it can answer the above questions. The actual details get much more complex and situational as you get deeper into the requirements and design of the workload.
And then there are always the trade-offs that need to be considered. For example, does your workload need high availability? If so, then it’s going to cost more in infrastructure.
Building in the cloud
To better illustrate how these frameworks fit together, how they all complement each other, and solve their individual objectives, let’s use a simple example of building a house.
Assume we want to build a modern house – environmentally friendly, efficient in the consumption of resources, supporting accessibility features, economically efficient, reasonably priced, looking great. Easy task…
To build such a house we will need an architect and the architect will bring the land surveyor – because one will have a hard time building a basement of their dreams if the bed rock one foot below will not allow it any deeper. The architect will pick the design, look if this area is close to the ocean waves, that every so often may swell to 20 feet heights, or if the fantastic mountainous outlook may not be supported by the soil that may collapse under the weight of the construction.
Azure Landing Zones and Cloud Adoption Frameworks will help you to solve all these problems. In addition to just providing guidance and templates, you will have an opportunity to use “pre-build” deployment blocks that will enable you to build a reasonably sound solution that you envision in a very short duration of time. The job is well done!
The major question at the end of any construction would be – did we actually build what we planned to build? The answer may not be that easy – it is probably – “it depends”.
While there is a multitude of rules and regulations, templates and pre-building blocks to build a house, it does not ensure the actual quality of the build and frequently does not measure up if the large number of security cameras will make the house less energy efficient or with no cameras at all – it will not be very secure.
The Well-Architected Framework helps to answer exactly this type of question. It puts a variety of components and requirements groups in five common perspectives:
- Security – secure and harden the workload
- Performance – take advantage of the scalability and flexibility of cloud fabrics
- Reliability – what uptime and resiliency does a particular workload require
- Operational Excellence – velocity of dev/test/ops processes
- Cost – can you operate and secure your workload at a lower cost
Of course, someone may even ask about Sustainability or Responsible AI.
Well Architected for Data Platform – SQL Server Products and Services
The SQL Family of products and services at Microsoft now spans the classical SQL Server edition that could be deployed on premise or virtually in Azure as IaaS, Azure PaaS solutions, SQL Managed, and SQL DB.
We are going to focus on the cloud offerings – Azure SQL VM, Azure SQL MI, and Azure SQL DB. Each of the products has its own very specific characteristics, sometimes some functionality could exist in all of these products and sometimes in two of them and sometimes a feature is very unique to a single product. For this very reason the “high level” approach is not able to get to the level of the assessment and analysis in order to provide recommendations – in our new Data & AI WAF assessments we introduce specific product tailored assessments that are focusing on the individual SQL products capabilities and specifics.
As a testament and appreciation for a lot of good and hard work done by the creators, I would like to mention that each of the assessment questionnaires was created by the group of Microsoft SQL Technical Insiders (having special deep technical training program focusing on SQL) in collaboration with the product team engineers that actually develop these products. It is hard to imagine better folks to work on these assessments.
Please review, discover and experiment how to perform a Well-Architected Assessment. You can always reach out to your Microsoft account team to request assistance and discuss how to perform a Well-Architected Assessment for your Cloud Platform, Solution, Application, or specific problem with any of the 5 pillars (Security, Performance, Reliability, Operational Excellence and Cost).
In future postings we will discuss in detail how to use the Well-Architected Assessment and Azure Advisor Signals to optimize data platforms on Azure.
About the Author
Sergey Khimchenko is a Senior Cloud Architect focused on the Data & AI services hosted on Microsoft Azure. He is the technical lead for the Well-Architected Framework focused on data services. Before Microsoft, Sergey spent almost 20 years as an Associate Director at KPMG, working on the Application Platform and various architecture projects for KPMG’s enterprise accounts.
Microsoft
