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.