Architecture Evolution With Mulesoft

For the last four years, I have worked with the Mulesoft product and with the three architectures: monolithic, SOA, and microservices. This article will discuss the evolution of these architectures and how Mulesoft has adopted them.

Monolithic Architecture (Single Unit)

Monolithic architecture could be defined as the first architecture. Simple and tightly-coupled applications, they are executed in a single application layer and group all functionalities in the same one.

If, for example, we want to access another service or system through an API, we must develop business logic as well as error management and so on in the application itself. The following diagram shows a simple example of monolithic architecture on Customer Relationship Management.

For small architectures, they work well, but when the architecture grows, the application is more complex to manage and refactor. In addition, it makes continuous integration more complicated to carry out, making the DevOps process almost impossible to accomplish.

The communication between resources and/or applications is direct without any other middleware/ESB intervening. It even increases the level of difficulty when it comes to implementing communication with a web service in some languages such as Java, where the connection with a SOAP service is complex.

SOA Architecture (Coarse-Grained)

SOA (Service-Oriented) architecture already allows for greater decoupling and therefore evolution to a more diversified architecture, or as they call it, coarse-grained.

This is the original architecture of Mulesoft, the ESB that allows to centralize all the business logic and allows the connection between services and applications regardless of their technology or language in a fast and simple way.

Mulesoft offers Mule Runtime, similar to Apache Tomcat, which works as a servlet container, as defined in the following diagram.

In this way, we eliminate all the work and most of the business logic to the application with monolithic architecture. The ESB will be in charge of transforming the data, routing, accessing the necessary services, managing errors, etc. The source application will simply generate a message (if necessary) and send it to the ESB via HTTP request.

However, one problem persists, and that is that all the integrations deployed work on the same runtime by leading it to the coupling and to an architecture that continues to have monolithic nature. For example, when you apply a configuration in the runtime, it will be applied to all your deployed applications.

Microservice Architecture (Fine-Grained)

Finally, the fine-grained one. This architecture imitates SOA but with smaller and independent services. Microservices bring a lot of complexity to the architectural level as there are many small actors involved, but the advantage is that they are all isolated and independent.

The limits must be very clear, reducing it too much can end up with a very complex and excessive architecture. The use of microservices requires a great change of mentality, things must be simple, well documented, simple to execute. This is why a development cycle should also be proposed/used to execute, implement and evolve quickly.

Mulesoft has also evolved and is no longer just a middleware with SOA architecture, now also focuses on the architecture of microservices with its integration as a service (SaaS) platform, Anypoint Platform. In this way, through its Cloudhub storage platform (integrated with the Anypoint Platform), you can deploy applications so that they are automatically created in separate instances without realizing it.

In addition, Mulesoft's methodical way of connecting data and applications through reusable and useful APIs, API-led connectivity, which helps to decouple between the implementation and the API. API-led connectivity is divided into three layers, Experience Layer, Process Layer, and System Layer. The first layer is the one that interacts with the client and has no implementation, only an exposed API that can be managed and secured.

The remaining layers contain the implementation, the process layer interacts between the API exposed and the systems layer that connects to the necessary services (database, SAP, Salesforce, mail, e-commerce, etc.).

But there's still one more evolution. Thanks to Anypoint Runtime Fabric and Runtime Manager (integrated with Anypoint Platform), these applications can be deployed on Runtimes in instances on infrastructures managed by the client in AWS, Google Cloud, Azure, virtual machines, or bare metal.

Also for containers, although it requires Docker's knowledge.

Summary 

The problem with the supposed imperative to adopt microservices is that there are many people who feel that it is a prescriptive architecture; it must be done one certain way — like Netflix, for example — or it simply can’t be done. But adopting microservices this way is not feasible for many organizations and can lead to failure.

For organizations that have particular structures and cultures, a purist view of microservices can only go so far because of various legal, technological, and cultural constraints. Organizations will fail if they follow an overly prescriptive point of view in the microservices space if their needs are not compatible with the purist approach.