Exam Ref AZ-304 Microsoft Azure Architect Design Certification and Beyond

Brett Hargreaves

• Publisher: Packt Publishing
• Year: 2021
• ISBN:
  9781800560543
• Edition: 1
• Topic: Informatik
• Subtopic: Systemarchitektur

Master the Microsoft Azure platform and prepare for the AZ-304 certification exam by learning the key concepts needed to identify key stakeholder requirements and translate these into robust solutionsKey Features• Build secure and scalable solutions on the Microsoft Azure platform• Learn how to design solutions that are compliant with customer requirements• Work with real-world scenarios to become a successful Azure architect, and prepare for the AZ-304 examBook DescriptionThe AZ-304 exam tests an architect's ability to design scalable, reliable, and secure solutions in Azure based on customer requirements. Exam Ref AZ-304 Microsoft Azure Architect Design Certification and Beyond offers complete, up-to-date coverage of the AZ-304 exam content to help you prepare for it confidently, pass the exam first time, and get ready for real-world challenges. This book will help you to investigate the need for good architectural practices and discover how they address common concerns for cloud-based solutions. You will work through the CloudStack, from identity and access through to infrastructure (IaaS), data, applications, and serverless (PaaS). As you make progress, you will delve into operations including monitoring, resilience, scalability, and disaster recovery. Finally, you'll gain a clear understanding of how these operations fit into the real world with the help of full scenario-based examples throughout the book. By the end of this Azure book, you'll have covered everything you need to pass the AZ-304 certification exam and have a handy desktop reference guide.What you will learn• Understand the role of architecture in the cloud• Ensure security through identity, authorization, and governance• Find out how to use infrastructure components such as compute, containerization, networking, and storage accounts• Design scalable applications and databases using web apps, functions, messaging, SQL, and Cosmos DB• Maintain operational health through monitoring, alerting, and backups• Discover how to create repeatable and reliable automated deployments• Understand customer requirements and respond to their changing needsWho this book is forThis book is for Azure Solution Architects who advise stakeholders and help translate business requirements into secure, scalable, and reliable solutions. Junior architects looking to advance their skills in the Cloud will also benefit from this book. Experience with the Azure platform is expected, and a general understanding of development patterns will be advantageous.

Section 1: Exploring Modern Architecture

Aspiring architects can often misunderstand what architecture is. This section discusses how the advent of the cloud has forced architecture to evolve and sets the context for why we must learn what is covered in this book.

The following chapters will be covered under this section:

• Chapter 1, Architecture for the Cloud
• Chapter 2, Principles of Modern Architecture

Chapter 1: Architecture for the Cloud

Before we examine the detailed knowledge that the AZ-304 exam tests, this chapter discusses some general principles of solution architecture and how the advent of cloud computing has changed the role of the architect. As applications have moved toward ever more sophisticated constructs, the role of the architect has, in turn, become more critical to ensure security, reliability, and scalability.

It is useful to agree on what architecture means today, how we arrived here, and what we need to achieve when documenting requirements and producing designs.

In this chapter, we're going to cover the following main topics:

• Introducing architecture
• Exploring the transition from monolithic to microservices
• Migrating to the cloud from on-premises
• Understanding infrastructure and platform services
• Moving from waterfall to Agile projects

Introducing architecture

It may seem a strange question to ask in a book about solution architecture—after all, it could be assumed that if you are reading this book, then you already know the answer to that question.

In my experience, many architects I have worked with all have a very different view of what architecture is or, to be more precise, what falls into the realms of architecture and what falls into other workstreams such as engineering or operational support.

These differing views usually depend on an architect's background. Infrastructure engineers concern themselves with the more physical aspects such as servers, networking, and storage. Software developers see solutions in terms of communication layers, interactions, and lower-level data schemas. Finally, former business analysts are naturally more focused on operations, processes, and support tiers.

For me, as someone involved across disciplines, architecture is about all these aspects, and we need to realize that a solution's components aren't just technical—they also cover business, operations, and security.

Some would argue that actually, these would typically be broken down into infrastructure, application, or business architecture, with enterprise architecture sitting over the top of all three, providing strategic direction. In a more traditional, on-premises world, this indeed makes sense; however, as business has embraced and adopted cloud, how software is designed, built, and deployed has changed radically.

Where once there was a clear line between all these fields, today they are all treated the same. Every part of a solution's components, from servers to code, must be created and implemented as part of a single set of tasks.

Software is no longer shaped by hardware; quite the opposite—the supporting systems that run code are now smaller, more agile, and more dynamic.

With so much change, cloud architects must now comprehend the entire stack, from storage to networking, code patterns to project management, and everything in between.

Let's now look at how systems are transitioned from monolithic to microservices.

Exploring the transition from monolithic to microservices

I've often felt that it helps to understand what has led us to where we are in terms of what we're trying to achieve—that is, well-designed solutions that provide business value and meet all technical and non-technical requirements.

When we architect a system, we must consider many aspects—security, resilience, performance, and more. But why do we need to think of these? At some point, something will go wrong, and therefore we must accommodate that eventuality in our designs.

For this reason, I want to go through a brief history of how technology has changed over the years, how it has affected system design, what new issues have arisen, and—most importantly—how it has changed the role of an IT architect.

We will start in the 1960s when big businesses began to leverage computers to bring efficiencies to their operating models.

Mainframe computing

Older IT systems were monolithic. The first business systems consisted of a large mainframe computer that users interacted with through dumb terminals—simple screens and keyboards with no processing power of their own.

The software that ran on them was often built similarly—they were often unwieldy chunks of code. There is a particularly famous photograph of the National Aeronautics and Space Administration (NASA) computer scientist Margaret Hamilton standing by a stack of printed code that is as tall as she is—this was the code that ran the Apollo Guidance Computer (AGC).

In these systems, the biggest concern was computing resources, and therefore architecture was about managing these resources efficiently. Security was primarily performed by a single user database contained within this monolithic system. While the internet did exist in a primitive way, external communications and, therefore, the security around them didn't come into play. In other words, as the entire solution was essentially one big computer, there was a natural security boundary.

If we examine the following diagram, we can see that in many ways, the role of an architect dealt with fewer moving parts than today, and many of today's complexities, such as security, didn't exist because so much was intrinsic to the mainframe itself:

Figure 1.1 – Mainframe computing

Mainframe computing slowly gave way to personal computing, so next, we will look at how the PC revolution changed systems, and therefore design requirements.

Personal computing

The PC era brought about a business computing model in which you had lower-powered servers that delivered one or two duties—for example, a file server, a print server, or an internal email server.

PCs now connected to these servers over a local network and performed much of the processing themselves.

Early on, each of these servers might have had a user database to control access. However, this was very quickly addressed. The notion of a directory server quickly became the norm so that now we still have a single user database, as in the days of the mainframe; however, the information in that database must control access to services running on other servers.

Security had now become more complex as the resources were distributed, but there was still a naturally secure boundary—that of the local network.

Software also started to become more modular in that individual programs were written to run on single servers that performed discrete tasks; however, these servers and programs might have needed to communicate with each other.

The following diagram shows a typical server-based system whereby individual servers provide discrete services, but all within a corporate network:

Figure 1.2 – The personal computing era

Decentralizing applications into individual components running on their own servers enabled a new type of software architecture to emerge—that of N-tier architecture. N-tier architecture is a paradigm whereby the first tier would be the user interface, and the second tier the database. Each was run on a separate server and was responsible for providing those specific services.

As systems developed, additional tiers were added—for example, in a three-tier application the database moved to the third tier, and the middle tier encapsulated business logic—for example, performing calculations, or providing a façade over the database layer, which in turn made the software easier to update and expand.

As PCs effectively brought about a divergence in hardware and software design, so too did the role of an architect also split. It now became more common to see architects who specialized in hardware and networking, with responsibilities for communication protocols and role-based security, and software architects who were more concerned with development patterns, data models, and user interfaces.

The lower-cost entry for PCs also vastly expanded their use; now, smaller businesses could start to leverage technologies. Greater adoption led to greater innovation—and one such advancement was to make more efficient use of hardware—through the use of virtualization.

Virtualization

As the software that ran on servers started to become more complex and take on more diverse tasks, it began to become clear that havin...