1) The document discusses microservices architecture as an alternative to monolithic architecture for building applications. Microservices split applications into independently deployable services organized around business capabilities rather than being a single application. 2) It compares monolithic and microservices architecture, noting that microservices allow individual services to be deployed and scaled independently rather than requiring the entire application to be redeployed. 3) The document argues that MuleSoft's integration platform can be used to implement microservices architecture by creating each service or API as a separate application that can then be independently deployed and managed.

1. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
www.whishworks.comwww.whishworks.com
Microservices with Mule

2. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Buzz about Microservices
• 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 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, a database 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.

3. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © 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.

4. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
• 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
Microservices

5. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © 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. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
• 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.
• 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.
6
What is a Microservice?

7. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © 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.
7

8. 2014 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential2015 © 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.
8