Distributed monolith vs. Microservices Architecture

Microservices

A mobile or web application in a microservices architecture is presented as many small discreet components that are connected. This is a style of Services Oriented Architecture (SOA) and so, is built using services of SOA. However, applications that are developed using SOA are found to have technical integration issues. The level of implemented services, built using SOA, is fine-tuned technical APIs (Application Programming Interfaces). General microservices architecture for business software implements it through large-grained business APIs.

Microservices Architectural Style

In this architectural style of microservices, several single applications are developed and customized to suit different business needs according to particular requirements. Each of the components in this system communicates with lightweight mechanisms while running its processes. For instance, HTTP reserve API is a lightweight mechanism, which the components of microservices architecture communicate with.

Rules that are essential for microservices architecture

• Breaking down monoliths that are larger than microservices, into smaller components or services.

  • Single network-accessible service - the smallest unit that is deployable

  • The original rule is one service per container.

    • A docking container that connects with Cloud Foundry, to ensure the quality of runtime.

• Optimizing single functions.

  • One business functions per service, in a microservices approach.

  • In an SOA approach, multiple business functions are taken care of by a single application.

• Rest APIs and message brokers aid in communication

  • Although SOA services complicate the entire process of breaking down monoliths, microservices simplifies them. They do this by adhering strictly to the type and limits of network connectivity.

  • In an SOA approach, multiple business functions are taken care of by a single application.

  • Microservices avoid tight coupling that gets introduced when it communicates implicitly with a database.

  • Applying CI/CD (Continuous Integration / Continuous Development) processes that are specific to services.

  • It is a well-known fact that different services evolve at separate rates.

  • Each service has a CI/CD process that is unique to them, and this pipeline occurs at a natural pace.

  • Not possible with a monolithic approach

• High availability or clustering decisions that are specific to services

• In a large system, all the processes are not required to scale.

  • Usually, many services can be deployed in a minimum number of servers possible, which aids in conserving various resources.

The micro in microservices refers to the size of components used in these and not based on the entire system.

Monolith or Monolithic Architecture

A software application that is single tiered and developed using multiple components that are combined into one. These components are combined into a single program so that it can be developed on a single platform. There are six major components used in the development of a monolith or monolithic architecture. These include authorization, presentation, business logic, database layer, application integration, and a notification module.

A monolithic architecture combines core elements of a web or mobile application. A basic idea would be as follows:

‣ Database - Data access layer (customer, billing, or event business logic) - User Interface

Monoliths offered a solution to fast track the processes when a combined effort of both human & computing resources was slow in implementing all changes per business, around 30 years ago. An example of monolith implementation would be, a process where the team of professionals developing, testing, and deploying programs that are relevant to businesses, worked non-stop to achieve the desired result. However, a major drawback of monoliths could be, that there was no way, a third party software is integrated into them.

Module Monolith

‣ All software codes for a system is in a single codebase.

‣ Well-structured, and not split into various modules.

‣ Non-monolithic Module - Software codes split into various modules and libraries.

Allocation Monolith

‣ All software codes are scheduled and deployed at the same time.

‣ A single version of codes to be released is deployed to all nodes of a monolith. The same version of the software will be running at all points, at the same time; irrespective of whether the module structure is a monolith.

‣ Non-monolithic modules will deploy at different times.

‣ Deployment of the codes is done everywhere at once.

Runtime Monolith

‣ A single application performing for an entire system.

‣ Essentially an allocation monolith that only has one node.

Benefits and Drawbacks of Monoliths

Benefits - Monoliths are simple to develop, test and deploy. It is easy for monolithic architectures to get scaled, which helps with adaptability.

Drawbacks - The huge size can slow down the application and this makes it difficult to maintain at an optimized level. It should be started from scratch after each update. Not too reliable and has difficulty in integrating and adapting to newer & advanced technologies.

Distributed monolith vs. Microservices Architecture

Monolith First

This is an approach used in developing monoliths, presumably the first & easy way. The most common approach would be to build a monolith & shave of microservices from edges until a nucleus of monolith survives in the middle. Designing a monolithic architecture with care by paying attention to the modularity of software at the API boundaries along with a proper way of data restoration, is deemed as the logical way of developing a monolithic architecture. Replacing the entire monolith is another option if this helps in taking a business into a competitive market and stays afloat.

ETL (Extract, Transform, and Load) and the system & Monolith

The evolution of a monolith results in a distributed version, which is an upgraded version of monolithic architecture. However, the once collected data is segregated to different places now, with it being spread to various systems. This can create issues as a big custom requirement will result in data searching in more than one system.

The requirements of the system involve complete access to all information and data available. This approach has a limited impact on the basic systems that are involved in both monolithic and microservices architecture. It does not need any additional infrastructures. The business requirements could be customized as per the client's needs. This approach is feasible and works to a certain extent and is scalable.

Biggest Headaches of ETL

‣ Changes in data - As encapsulation can take place; the data can migrate to various systems rather than be at one large place.(As mentioned before)

‣ Several data schemes to handle - Will cause issues of data scaling.

Distributed Monolith

For analyzing why data segregation takes place, one can create a system of the distributed monolith. Instead of a single system and a database, there are several of them. These systems have data represented and replicated across them. This can be referred to as a distributed monolith.

In this situation or scenario, there is no chance of data segregation. The only way to derive data from such a distributed monolithic architecture is to develop services that can connect directly to all components.

A distributed monolith can be tracked by keenly observing and following the changes that happen in them. Event sourcing is one such method to break a distributed monolithic architecture.

Microservices Architecture

Microservices architecture is developed & organized based on business requirements and models. These are broken into libraries, as a part of componentizing, a custom software. The components are linked to a program and called via in-function calls.

Conway's law states, "Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure." - Melvin Conway, 1967

Microservices architecture is split into services that can be organized around business capability. The skills required include user-experience, database, and project management. Applications built via microservices are as simplified as possible.

A basic system that runs with microservices architecture goes through this layout:

‣ It is run and deployed on the build machine

‣ It is deployed into an environment that favors and helps with integration.

‣ The deployed environment is also a User Acceptance Testing (UAT) platform.

‣ This environment is where the microservices architecture performs at its best.

Microservices architecture is considered to have an evolutionary design. There are examples wherein a monolith got evolved into microservices architecture, as per the custom requirement of a business organization. There is scope to add more components without affecting the functionality of microservices. This creates more opportunities to improve the overall value of microservices architecture. One headache would be, redeploying modified microservices architecture. This is a blessing in disguise as it eventually simplifies and speeds up the entire process.

Is this debate really necessary?

Although splitting up of monolith into microservices architecture is also said as a distributed monolith, in reality, it is not, as mentioned before. There are arguments about microservices architecture; about, it being future of software applications getting integrated into business processes or not. Since it has an evolutionary design, refactoring would be easy to accomplish. Most of the experts have the opinion of building a monolith and then evolving it into a series of microservices.

It can be safe to say, both have their advantages and flaws; however, they are needed to customize various business software as per custom requirements. There cannot be a direct comparison between both as the concepts of monolithic architecture or monolith and microservices are intertwined with each other. The debates of distributed monoliths vs. microservices architecture will keep going on until a solid alternative with the best from both worlds emerge. A software application and development team should know about both the concepts thoroughly before entering the market.