Software Architecture Patterns and Designs

In this article, we will discuss software architecture patterns that will help to implement current applications based on our current requirements.

Hello readers, I am here after a very long gap. I was busy with some other important tasks. Hope, some Dineshonjava readers read my books related to software technologies such as Spring 5 Desing Patterns, Mastering Spring Boot 2.0, and Hands-on-Microservices.

In May 2019, you can also find my other latest book Desing application with Spring Boot and React JS published by BPB Publication. In this book, you can find a full stack development with the Spring Boot 2.2 and React JS framework.

It is just recapping about my efforts toward the Software industries. Here, I am going to discuss an article about the Software Architecture Patterns and Designs, we will learn here, how to create applications and which software architecture is better for your current application.

We are aware of today’s application and its requirement to server millions of requests per second. Nowadays, everyone on the internet, every second a huge amount of data is consumed by internet users. So, now, we have to plan robust architecture patterns that can serve millions of requests per second without any impact.

After reading this article, the reader will understand the concept of conventional Monolithic architecture its advantages in the software development life cycle such as the Waterfall model. The reader will be further explained on the limitation of Monolithic architecture that leads to a need for building loosely coupled system as Microservice architecture.

In this article, we will also discuss some points to evaluate which architectural choices made for the application of business and the reasons behind shifting towards microservices. Let’s start with the Monolithic architecture pattern,

Monolithic Software Architecture Patterns

At the initial phase of a startup, most of the applications were based on the Monolithic architecture pattern. In Feb 2010, I had started my second job with Paytm, that time Paytm was a startup and began with a monolithic application architecture because we were only two developers with the Paytm on that time.

There are many startups begin application develop follow Monolithic architecture pattern due to the small size of the team. Monolithic architecture pattern doesn’t force to more operational overhead and also, monoliths often just have one massive code base.

An application based on the Monolithic architecture pattern is a single artifact with all layer’s interfaces such as a database having several tables and DAO classes, client-side UI part including HTML pages & JavaScript, and a server-side application to handle HTTP requests, processing some business logic using service classes, retrieve and update data from the database, exchanging messages with other systems, and returning responses in format of HTML/JSON/XML.

A Monolithic architecture based application often has a massive code base including all the layers required for either frontend and backend application. As a developer, if you want to make any change into this massive code base then you have to build and deploy again an updated version of the server-side application.

As we know that we have to serve a variety of different clients. We have to focus on development to provide support to all different clients such as desktop browsers, mobile browsers and native mobile applications such as Android, IOS etc. In an application, based on the Monolithic architecture pattern, we must have complete code to support a variety of different clients. Let’s discuss it with an example based on Monolithic architecture pattern.

Monolithic architecture pattern example

Suppose we are working on a book shop application, it is an e-commerce application that provides online book shop portal. It takes orders from customers, verifies availability of the ordered book, places an order, and ships ordered book to the customers. So, to build this application, we have to create several modules such as Shop Front UI module which provides the user interface to the customers, backend services such as Account Service, Book Service, Order Service, Shipping Service etc. These services have various responsibilities such as to verify customer, to check the availability of books, to place an order, to ship that order.

Let’s see the following architural diagram of the Monolithic application:

As you can see in the preceding diagram, all modules such as frontend, and backend services such as Account Service, Order Service, Book Service, and Shipping Service work as a single artifact. The clients such as Desktop and Mobile browser use the same application.

Monolith application is always built as a single, autonomous unit. In a client-server model, the server-side application is a Monolithic application and it handles the HTTP requests, executes logic, and retrieves/updates the data in the underlying database.

The problem with a Monolithic architecture pattern, though, is that all change cycles usually end up being tied to one another. A modification made to a small section of an application might require building and deploying an entirely new version. If you need to scale specific functions of an application, you may have to scale the entire application instead of just the desired components. This is where creating microservices can come to the rescue.

Let’s discuss some pros and cons of the Monolithic architecture pattern in the below section.

Pros of Monolithic architecture pattern

There is the following number of benefits of using the Monolithic Software architecture pattern:

• Simple to develop– Monolith application is very simple to develop because all modules of application will be part of the same application and current development tools and IDEs are support the development of the monolithic application.
• Simple to test– As we have discussed monolithic application has all modules in a single artifact, so you can easily do end-to-end testing by simply running the application either with manual or with Selenium.
• Simple to deploy– A monolith application is a single artifact so you can easily deploy to the server as the WAR file.
• Simple to scale– You can easily achieve scaling by copying this single artifact of application to the multiple running machines and set up a load balance behind the monolithic application.

As you have seen the benefits of the Monolithic application in the above list. Although Monolithic architecture pattern has some benefits at same this architecture numerous limitations.

Cons of Monolithic architecture pattern

There are some limitations of using the Monolithic software architecture pattern as the following:

• The large monolithic code base intimidates developers, especially ones who are new to the team. The application can be difficult to understand and modify. As a result, development typically slows down.
• Overloaded IDE – the larger the code base the slower the IDE and the less productive developers are.
• Overloaded web container – the larger the application the longer it takes to start up. This had had a huge impact on developer productivity because of the time wasted waiting for the container to start. It also impacts deployment too.
• Continuous deployment is difficult – a large monolithic application is also an obstacle to frequent deployments. In order to update one component, you have to redeploy the entire application.
• This simple approach has a limitation in size and complexity.
• Application is too large and complex to fully understand and made changes fast and correctly.
• The size of the application can slow down start-up time.
• You must redeploy the entire application on each update.
• Impact of a change is usually not very well understood which leads to doing extensive manual testing.
• Continuous deployment is difficult.
• Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements.
• Another problem with monolithic applications is reliability. Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.
• Monolithic applications have a barrier to adopting new technologies. Since changes in frameworks or languages will affect an entire application it is extremely expensive in both time and cost.

Let’s have a look at the situations in which monolithic applications are useful.

When to use monolithic architecture

Monolithic architecture can be used in the following situations:

• In the foundation stage of the project, this architecture works well and mostly big and successful applications start with the monolith application architecture.
• It works well for building an unproven product or proof of concept.
• When your development team is less experienced.

We have discussed the Monolithic Software architecture pattern and its cons and pros. Let’s move to discuss another very important software architecture pattern in the next section.

Microservice software architecture patterns

In the previous section, we have discussed the Monolithic architecture pattern. An application based on the Monolithic architecture has all modules of application as a single artifact.

But unlike Monolithic, there is another architecture that structures as an application such that all modules of that application are loosely coupled, collaborating services, and independently deployable. In this approach, each service must have focused on a set of narrowly, related functions. And each service runs as independently and as a unique process. For example, an application might consist of services such as the order service, the account service etc. This approach is known as Microservices Architecture.

Microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.

In the microservices architecture, all services communicate to each other either synchronously using HTTP/REST or asynchronously using AMQP/Kafka. Each service contains own database. So, the basic idea behind the microservices architecture is splitting your monolithic application into a set of smaller, interconnected services.

A microservice architecture pattern separates concerns on a process level. All processes in this architecture are loosely coupled with each other. They communicate using predefined rules to achieve a business goal. So, let’s move on and look at an example of a microservice-based application.

Microservices architecture pattern example

We have discussed an application based on the Monolithic architecture pattern in the previous section of the Book online shop. In this section, we are going to discuss the same example using microservice architecture. The online book shop application has 4 t 5 modules such as Account Service, Book Inventory Service, Order Service, and Shipping Service. This application also has a user interface application Shop front UI web application to server user request and send a response.

Let’s see the following microservices architectural diagram of the application that consists of a set of services:

As you can see, we have divided the earlier monolithic bookshop application into several independent services: Account Service, Book Service, Order Service, and Shipping Service. This is a microservices architectural style; according to this approach, we can develop a single application as a suite of small services.

Each service is built around a business capability and is independently deployable into the server. For example, the Account Service manages the customer’s account and has its own database, Account DB. Similarly, the Book Service manages the inventory of the books and has the database Inventory DB. The Order Service manages the customer’s orders using a separate database, Order DB. Finally, the Shipping Service manages shipping orders using the Shipping DB. Each module has its own dependency without depending on other services. This means that we can choose different technologies as well as develop separate services.

The server-side application must handle requests coming from various clients, such as a desktop or mobile browsers and native mobile apps. The Shop Front UI web application handles the HTTP requests that come from browsers. Some APIs are exposed to the native mobile app, so the app doesn’t call these APIs directly – instead, the app communicates through an intermediary known as an API Gateway. The API Gateway is responsible for handling these requests using load balancing. The API Gateway also offers caching, access control, and API monitoring.

Let’s see the benefits of using the Microservice software architecture pattern.

Pros of Microservice architecture pattern

The following are some of the benefits of the microservice architecture pattern:

• Easy to maintain- Smaller code base is easy to maintain. It is very easier for the developer to understand. You can start faster development which makes more productive.
• Easy to scale- Yoy can easily scale individual component.
• Technology diversity- Microservice gives open hand to use mix libraries, frameworks, data storage, languages etc.
• Fault Isolation- Component failure should not bring the whole system down
• Better support for smaller, parallel teams
• Independent deployment- Microservice architecture enables each microservice to be deployed independently. As a result, it makes continuous deployment possible for complex applications

Microservice-based architecture also has a few disadvantages, however, and we’ll take a look at them in the following section.

Cons of Microservice architecture pattern

Microservices provide several benefits, but there are also some challenges relating to microservice architecture when developing an enterprise application. Let’s see the following:

• Difficult to achieve strong consistency across services
  • ACID transactions do not span multiple processes
  • Eventual consistency, Compensating transactions
• Distributed system
  • Harder to debug/trace
  • Greater need for end-to-end testing
  • Expect, test for and handle the failure of any process
  • More components to maintain: redundancy, HA
• Typically requires “cultural” change (Dev Ops)
  • How applications are developed and deployed
  • Devs and Ops working together, even on the same team!

In light of its disadvantages, in the next section, we will discuss when to use microservice architecture for your project.

When to use microservice architecture

One of the challenges with microservices architecture is deciding when to use the microservice architecture. Let’s see some scenarios that tell us when to start using the microservices architecture in your next project.

• New project development: Microservice architecture is more suitable when developing the first version of an application. You can plan your project and its associated modules from an initial level, whereas it can be challenging to convert an old or legacy project into a microservice-based application.
• Separating concerns in the business application: This architecture provides a better level of separation of concerns as the Spring framework provides separation of concerns at the level of the application’s components.
• Development of a cloud-native application: This architecture provides cloud-native patterns and supports distributed application development. We can create numerous independent services which can be deployed to a different platform on a different network, as can be done in the cloud.
• The quick development of independent service delivery: Microservice architecture allows us to develop a business application quickly by dividing it into the independent delivery of individual parts within a larger, integrated system.
• Efficient modules: In a business application, there are some modules that are very important for a business, and these modules must be developed in extremely efficient ways. The microservice architecture allows you to use better technologies for these modules to improve their efficiency.
• Alongside a fast-growing product or team: If you start with microservice architecture, it provides your team with the flexibility to develop a product quickly. It also provides scalability to your application from the beginning.

Microservices has become an increasingly popular service architecture, but it’s essential to understand whether it’s the best fit for your project. Now,
let’s move on to another type of software application architecture.

Service-oriented architecture (SOA) Pattern

SOA is another application architectural style. In SOA, architecture services are provided to other services and to vendor components using a communication protocol over a network. These services are discrete units of functionalities that can be accessed remotely. The following diagram shows an SOA in action:

As you can see in the preceding diagram, there are two main layers of the SOA: a service consumer layer and a service provider layer.

• The service consumer layer is the point at which all the consumers, such as human consumers and other service consumers, interact with the SOA.
• The service provider layer is the point where all services are defined within the
• SOA.

In the preceding diagram, the Enterprise Service Bus (ESB) provides communication by a common communication protocol, or communication bus, which has connections between the consumers and providers. In SOA architecture, database storage is shared between all services.

SOA has more dependent ESBs. The ESBs implement a communication system between mutually interacting software applications with microservices. It also uses faster messaging mechanisms.

In this article, we have discussed three software architecture patterns such as Monolitic, Microservice, and SOA. Let’s move to the next section and have a look how these architecture a different to each other.

SOA vs Microservice vs Monolithic software architecture patterns

Let’s see the following diagram about these software architecture patterns and this diagram also self explains about the different between these software architecture patterns.

As you can see in the preceding diagram, the Monolithic architecture based application contains all modules as a single unit or artifact. But in the SOA, these modules work as coarse-grained services using ESB. And in Microservices architecture, application divided into fine-grained modules. Each module is known as a Microservice. Microservice architecture has a much better fault-tolerance system than SOA. Because SOA has ESB, which could be a single point of failure that impacts the entire application.

Conclusion

In this chapter, we discussed different software architecture patterns, including monolithic, microservice, and SOAs. Monolithic architecture means building an application that includes all of its modules as a single artifact. It is better for simple and lightweight applications.

But Monolithic architecture has various drawbacks, such as its large codebase, which can become difficult to manage. Even after making only a small change to the codebase, a new version of the complete application codebase must be built and deployed to the server. To resolve the problems of monolithic architecture, microservice architecture can be used.

Microservice-based architecture resolves many of the problems of monolithic architecture. This architecture pattern decomposes a monolithic application into several different and independent processes. These processes are known as microservices. A microservice architecture pattern is the better choice for complex, evolving applications. In essence, this architecture pattern handles a complex system better than monolithic architecture.