Basics intro on microservices and how mule helps us to use this approach

1. MICROSERVICES WITH MULE
Govind Mulinti

2. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
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 client-side 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
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 involves building
and deploying a new version of the server-side application.
2
Buzz about Microservices

3. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Legacy / Monolithic
A monolithic server is a simple approach for building a huge 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.
3

4. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
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
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.
4

5. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Comparing monolithic with microservices architecture
• 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 influence of cost plays an important role
• The micro service architecture illustrated in the above
diagram has a third service with two instances. We can
scale individual services instead of full set of
applications based on the requirement and the volume
expected for individual service.
5
• The approach to micro services is not
about hitting it directly but rather
about designing the whole set of
services, then group them
functionally and split them further
into micro services accordingly.
a b d
Microservices - architecture
d
Middleware /
ESB
Client / UI
a
b
d
Monolithic - architecture
Middleware /
ESB
Client /
UI

6. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Microservices with MuleSoft ESB
If we follow micro services 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.
6

7. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
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 micro services 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 ecommerce solutions and / or mobile applications.
• It is not necessary to have a 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.
7