Microservices has been a buzz word for past few years. It talks about a technique of designing integrations and APIs as an independently deployable service. While there is no exact definition of this architectural style, there are certain common characteristics around organisations around business capabilities, automated deployments, intelligent endpoints and distributed control of data.
1. September 10, 2015 by Govind Mulinti API , ESB , Mule ESB , SOA No Comment
Microservices with Mule
Microservices has been a buzz word for past few years. It talks about a technique of
designing integrations and APIs as an independently deployable service. While there is
no exact definition of this architectural style, there are certain common characteristics
around organisations 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 clientside user interface (consisting of HTML
pages and/or JavaScript running in a browser), a database (consisting of many tables
usually a relational database management system) and a serverside application. The
serverside 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 serverside application is a monolith – a single logical executable.
Any changes to the system involves building and deploying a new version of the
serverside application.
Such a monolithic server is a 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 loadbalancer.
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
There is no formal definition for Microservices architectural style, but we can frame our
understanding based on the details that microservice approach to division is different,
splitting up into services organised around business capability. Such services take a
broadstack implementation of software for that business area, including user
interface, persistent storage, and any external collaborations.