Chapter 4: Reviewing the Historical Architecture Styles

In this chapter, we will review some of the existing architecture styles. I decided to focus on only a few, in chronological order, from monoliths to microservices, but the list of architecture styles does not stop there. There are many more styles and patterns, but the ones I chose represent both legacy and modern systems, which you will definitely encounter in your software architect career.

Here are the topics we are going to focus on:

• Introducing architecture styles
• Starting with monoliths
• Continuing with service-oriented architecture (SOA)
• Finishing with microservices

By the end of this chapter, you should be able to understand the benefits and drawbacks of monoliths, SOA, and microservices. You should be familiar enough to recognize the style of the architecture you are confronted with and apply the skills you've gained in your own context.

Introducing architecture styles

Architecture styles are high-level design choices that influence the way applications are designed, built, and hosted. Making such a choice forces you to obey the standard practices that ship with the style in question. Some architecture styles act at a higher level than others.

For example, the three-tier architecture is based on three different layers – presentation, business, and data – all of which are physically separated. In a three-tier architecture, the presentation layer cannot talk directly to the data layer. Network policies should be enforced to prevent such occurrences. As you can see, this type of architecture has an impact, not only on the hosting piece but also on the way you organize the development of the different components. Conversely, the Model View Controller (MVC) pattern is also based on three layers, but all the layers can be deployed to a single server. Here, the physical split is not required. However, going...

Starting with monoliths

I guess that you must already be familiar with monoliths, as it seems they have become the pure evil ones. However, at the risk of shocking you, monoliths will probably be around forever and have some interesting benefits. Before we look at their benefits and drawbacks, let's see what a monolith looks like:

Figure 4.1 – Literal meaning of a monolith

The preceding image shows what a monolith truly is. It is some sort of single-block-rock, from which you cannot extract a single piece, at least not with your hand. It is something that cannot be manipulated easily, something that will have a certain resistance to changes. However, while it seems hard to manipulate the monolith shown in the preceding image, it looks much easier to do with the ones shown in the following image:

Figure 4.2 – Small monoliths

Yes, you got it: with monoliths, size does matter! The problem with monoliths is when they...

Continuing with service-oriented architecture (SOA)

SOA promotes reusability across the entire enterprise landscape by exposing business capabilities in the form of services. SOA emerged in the last decade of the previous century, with the aim of decoupling applications. Before SOA, it was very common to have client applications directly connect to each other, or to a shared database with read/write permissions. This led to big issues and to the formation of an enterprise-level monolith, as described in the previous section, to the extent that changing anything could pose problems to many applications, leading to a lack of agility and an ever-increasing amount of time required to make small changes.

The following diagram shows a typical SOA implementation:

Figure 4.3 – Typical SOA implementation

The component in the middle is the Enterprise Service Bus (ESB), which plays a central role in SOA. The ESB interconnects different services. Although we...

Microservices

Microservices have become popular over the past few years, but it is still not so easy to find a common definition of what they are. In my opinion, microservices can be seen as SOA on steroids, scoped to a single application. Microservice architectures are entirely based on services, but the biggest difference compared to SOA is their level of granularity, their level of decomposition, and their scope. While SOA maximizes reusability across the enterprise landscape, microservices focus on bounded contexts, which may vary from one application to another.

The following is a high-level diagram of what a microservice architecture looks like:

Figure 4.5 – Microservice architecture

Each outer circle in the preceding diagram represents an independent bounded context formed by a microservice. Within a microservice, you may have one or more components and a dedicated data store. Communication across microservices is done asynchronously through...

Summary

I hope that you feel more comfortable now that you know about the three architecture styles we discussed in this chapter. As a software architect, you will often be able to choose either monolith or microservices. You will unlikely be entitled to go for SOA on your own because SOA is an enterprise-level effort, not a one man/woman show. However, you should have understood by now that going for non-SOA in an SOA-driven enterprise will be quite challenging.

Although architecture styles are high level, they have a significant impact, positive or negative, on software quality attributes.

In the next chapter, we are going to consider lower-level design choices and dive deeper into the code design patterns that are implemented by software developers.