In the past four years, my MuleSoft website has experienced three architectures: Monolithic, SOA and Microservices. This article will discuss the evolution of these architectures and how to adopt them.
Monolithic architecture (stand-alone)
Monolithic architecture can be defined as the first architecture of most websites, which are simple and tightly coupled applications that execute in a single application layer and group all functions in the same application layer.
If we want to access another service or system through API, we need to develop business logic and error management in the application itself.
The following figure shows an example of the monolithic architecture of a customer relationship management system.
For small architectures, they work well, but as the architecture grows, the management and refactoring of applications becomes complicated. In addition, continuous integration will become complicated, which makes the DevOps process almost impossible to complete.
The communication between resources or applications of the monolithic architecture is direct, without any other middleware or ESB intervention. This also adds a lot of complexity when using certain languages (for example, the connection between Java and SOAP services is very complicated) to communicate with Web services.
SOA architecture (coarse-grained)
SOA (Service Oriented) can already have a greater decoupling of the architecture, it can evolve into a more diverse architecture, also known as a coarse-grained architecture.
This is the second version of Mulesoft's structural system. ESB centralizes all business logic and allows connections between services and applications, regardless of technology or language, to be very fast and easy.
Mulesoft provides Mule Runtime, similar to Apache Tomcat, it can be used as a Servlet container, as shown in the figure below.
In this way, we eliminate unnecessary work and most business logic of the application through a single architecture system. ESB is responsible for converting data, routing, accessing necessary services, managing errors, etc. The source application simply generates a message (if needed) and sends it to the ESB via HTTP request.
However, there is still a problem, that is, all the integrations of deployment are introduced through ESB, and the architecture of coupling and continuing to have a single nature is still working in the same system. For example, when the configuration is applied at runtime, it will be applied to all deployed applications.
Microservice architecture (fine-grained)
Next, microservices with fine-grained architecture come into play. The architecture is very similar to SOA, but a small and independent service. Microservices bring a lot of complexity to the architectural level because they involve many small roles, but the advantage is that they are all independent.
The limitations of microservices are very clear, and reducing too much can lead to a very complex and excessive architecture. The development and use of microservices requires developers to completely change their mindset, things must be simple, complete documentation, and easy to execute.
Mulesoft has also continued to develop. It is no longer just the middleware of the SOA architecture, but also focuses on the microservice architecture and its integration-as-a-service (SaaS) platform Anypoint Platform. In this way, through its Cloudhub storage platform (integrated with the Anypoint platform), users can deploy applications to automatically create them in different instances without having to know.
In addition, Mulesoft uses a reusable and useful API to connect data and applications, helping to separate the implementation layer and the API. The API-guided connection is divided into 3 layers, the experience layer, the process layer and the system layer. The first layer is the layer that interacts with the client but is not implemented. There are only public APIs that can be managed and protected.
The remaining layer contains the implementation, the process layer interacts between the exposed API and the system layer connected to the necessary services (such as databases, SAP, Salesforce, mail, e-commerce sites, etc.).
With the help of Anypoint Runtime Fabric and Runtime Manager (integrated with Anypoint Platform), these applications can be deployed on an infrastructure managed by AWS, Google Cloud, Azure, virtual machines or clients in a single machine.
It also applies to containers, although it requires some knowledge of Docker.
summary
Regarding the adoption of microservices, many people think that it is a standardized architecture, and it must be done in a standardized way, such as Netflix. However, the use of microservices is not feasible or practical for many organizations, and it is very likely to lead to failure.
For a team with a specific structure and culture, due to various technical and cultural constraints, the view of microservices can only go so far. If the organization follows the normative view too much in the microservice space, and the product requirements are not compatible with pure methods, then the implementation of the microservice architecture will definitely be unsuccessful.