Govind Mulinti, a senior architect at Whishworks, is the guest author of this blog post.
Microservices has been a buzz word for past few years. It talks about a technique of designing integrations and APIs as independently deployable services. There are certain characteristics around organizations around business capabilities, automated deployments, intelligent endpoints and distributed control of data.
Before we start on microservice style, it would be useful to compare it with the monolithic style. A monolithic application is built as a single unit. Enterprise applications are often built in three main parts: a client-side user interface (consisting of HTML pages or JavaScript running in a browser), a database (consisting of many tables usually a relational database management system) and a server-side application. The server-side application will handle HTTP requests, execute some domain specific logic, retrieve and update data from the database and populate the HTML views to be sent to the browser. This server-side application is a monolith – a single logical executable. Any changes to the system involve building and deploying a new version of the server-side application.
Such a monolithic server is natural and has a simple approach for building such a system. All the logic for handling a request runs in a single process, allowing us to use the basic features of the language to divide up the application into classes, functions, and namespaces. With some care, we can run and test the application on a developer’s laptop, and use a deployment pipeline to ensure that changes are properly tested and deployed into production. We can horizontally scale the monolith by running many instances behind a load-balancer.
Monolithic applications can be successful, but increasingly people are frustrated with them as more applications are being deployed to the cloud. Change cycles are tied together; even if a small change is made to the application, it requires the entire monolith to be rebuilt and deployed. Over time it is often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires entire application to be scaled rather than parts of it that may only require more resources.
These obstructions have led to the microservices architectural style of building applications as suites of services. These services would be independently deployable and scalable. Each service also provides a stable module boundary, even allowing us to write different services in different programming languages. They can also be managed by different teams as well.
Microservices
We can frame our understanding of microservices architectural style based on the details that microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistent storage, and any external collaborations.
The common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA. We will discuss here how it fits our purpose in the integrations.
Here we can see a difference between the monolithic architecture and a microservices architecture. There may be a few variations based on the distribution of the back-end services of the databases. In some cases, the legacy backend applications may not be shifted or changed as an influence of cost plays an important role.
Here we see that the services are broken down based on the business modularity, and those can be developed and deployed independently of each other unless the business required all at the same time.
We can achieve a clear microservice architecture for any greenfield project. There can be various solutions based on the existing enterprise architecture, availability of requirements and customer’s view resulting into different types of implementations. But we can ensure that the services implemented can be made available in a modular approach so that they are developed and delivered independently.
The microservice architecture illustrated in the above diagram has a third service with two instances. We can scale individual services instead of a full set of applications based on the requirement and the volume expected for individual service.
Considering the above example in the image, the monolithic database may be an existing system for which the customer may not be willing to transform as their current business might have an impact and would also cost a lot. In these cases, we can create an integration architecture that would cater to the need of mediating the existing services and provide APIs that can be independently deployed and exposed to the other external systems that are expected to be integrated into the system.
The approach to microservices is not about hitting it directly but rather about designing the whole set of services, then group them functionally and split them further into microservices accordingly.
How MuleSoft as an ESB comes into play
If we follow microservices architecture principles and choose to implement granular services, we can easily deploy these services on the CloudHub independently and can scale up or down as and when necessary without impacting any other services within the EAI landscape. Each service or API is created as a separate application containing the mediation flow required for the underlying requirement. Every individual application can be managed independently. The same is possible if we plan to go with the Mule ESB EE deployment strategy as well. The scaling factor is out of the box supported on CloudHub through the admin console whereas for EE deployment it would be dependent on the underlying infrastructure design.
Supplementary Benefits
Parallel development can progress as the functionalities are not overlapping, and these are designed to operate independently. Placing these components and APIs as microservices also provides an opportunity to plan granular releases. This also implies that the releases can follow agile process and methodologies.
Some benefits include exposing of granular services from the legacy applications or complex solutions that can be consumed by new e-commerce solutions and mobile applications.
It is not necessary to have full detailed requirements for all the planned services. We can create, enhance and expose the services to the consumers with an agile/iterative delivery model.
To learn more, take a look at more resources on best practices for implementing microservices in your organization. We also have a best practices for microservices webinar that is available on demand for viewing.
This post originally appeared on the Whishworks blog. Whishworks is MuleSoft’s EMEA services partner of the year.
