As time passes, architectural styles have improved significantly. Various architecture patterns, such as mainframes, client-server, n-tier, and service-oriented architecture (SOA), have been popular at various points in history. However, these architectural were all involved in developing some sort of monolithic application, either directly or indirectly.

As the revolution happened in the technology stack, microservice architecture has come to the fore as a result of improvements in all previous architectures. The aim is to provide agility, reduce the turnaround time for adopting new changes, achieve scalable performance, and take full advantage of modern tools and frameworks.

Microservice architecture breaks an application into small, independent subsystems. They also can be referred to as a system of systems, as shown in the following diagram:

Though the components are stored in different logical layers in a monolithic architecture, they are packaged in a single application structure. On the other hand, the microservice system is a set of independent subsystems, each packaged in their own project structure and deployed as independent units. You can consider a microservice architecture as a jigsaw puzzle where each microservice is a building block of a whole application.

In short, in a monolithic system, the components are logically different but part of single physical application, whereas in a microservice architecture, the subsystems are actual physical applications that form a giant logical application.

The microservice architecture is widely used now as a set of standards to refactor monolithic applications. Emerging from a hexagonal pattern, a microservice architecture promotes the encapsulation of a business function into an individual independent unit that is isolated from other functionality.

A Hexagonal Architecture puts input and output on the edges of a hexagon and keeps Business Logic at the center. This arrangement isolates the application from outside concerns, as follows:

The inside part consists of Business Logic, whereas the outside consist of the UI, messaging, REST, database, and others. The outside parts can be swapped without affecting the core application functions. Each business function can be designed with the hexagonal model, which then interacts with others with a standard communication mechanism.

Let's look at the hexagonal pattern by taking an example. Consider you are developing an EMI calculator application that calculates the principal and interest amount based on total loan amount, interest rate, and tenure. This application keeps the provision of scanning the user input to calculate the loan data. The logic for taking user input is closely associated with the EMI calculator application. After a period of time, another application needs to use the EMI calculator application. In this case, the input mechanism needs to be updated.

To overcome this problem, the hexagonal pattern suggests isolating the EMI calculating logic from the input receiving mechanism by defining some sort of standard interface. This way, the EMI calculator is completely unaware of where the inputs come from. In this scenario, the interface for receiving input is referred to as a Port, while its implementation is known as an Adapter, as follows:

The hexagonal pattern is also referred to as the Port and Adapter pattern. The concept of the microservice architecture is derived from the hexagonal pattern, in which each hexagonal structure represents a self-contained and loosely coupled service (subsystem). Adding more hexagonal models is equivalent to adding more independent services. 

That is why the microservice concept is logically compared with a honeycomb, in which multiple hexagons form a large and solid structure. Similarly, individual services (equivalent to individual hexagonal structures) form a larger application.