Microservice's in detailed

Micro(+)Service's
MICROSERVICE'S IN DETAILED…
@ M O H A M M E D F A Z U L U D D I N

Topics
What is Microservices.
Why we need Microservices.
Microservice Architecture.
Microservices Design Pattern.
Operational Challenges With Microservice.
Microservices Vs SOA.
Microservices Security.
Pros and Cons of Microservices.

What is Microservices
• A workshop of software architects held near Venice in May 2011 used the term "microservice"
to describe what the participants saw as a common architectural style that many of them had
been recently exploring.
• Microservices is a specialization of an implementation approach for service-oriented
architectures (SOA) used to build flexible, independently deployable software systems.
• The microservices approach is a first realization of SOA that followed the introduction
of DevOps and is becoming more popular for building continuously deployed systems.
• Microservices also known as the microservice architecture , which is an architectural style that
structures an application as a collection of loosely coupled services.
• In a microservices architecture, the services should be fine-grained and the protocols should
be lightweight.

Why we need Microservices
• Companies like Netflix, Amazon, and others have adopted the concept of microservices in their
products. Microservices are one of the hottest topics in the software industry and many
organizations want to adopt them.
• Especially helpful is the fact that DevOps can play very well with microservices.
• In monolithic software, we mainly use a three-tier architecture: Presentation layer, Business
layer and Data access layer
• Say a traditional web application client (a browser) posts a request and the business tier
executes the business logic, the database collects/stores application specific persistence data,
and the UI shows the data to the user.
• There are several problems with this type of system. All code (presentation, business layer,
and data access layer) is maintained within the same code base.
• The most important aspect of microservice culture is that whoever develops the service, it is
that team's responsibility to manage it.
• This avoids the handover concept and the problems associated with it.

Microservice Architecture
• The Microservices Architecture help to have at least a basic grasp of the following concepts:
• Object Oriented Programming (OOP): A modern programming paradigm .
• Web service / API: A way to expose the functionality of your application to others, without
a user interface
• Service Oriented Architecture (SOA): A way of structuring many related applications to
work together, rather than trying to solve all problems in one application
• Systems: In the general sense, meaning any collection of parts that can work together for a
wider purpose
• Single Responsibility Principle (SRP): The idea of code with one focus.
• Interface Segregation Principle (ISP): The idea of code with defined boundaries.

• Microservice architecture tells us to break a product or project into independent services so
that it can be deployed and managed solely at that level and doesn't depend on other services.
• Many people have the wrong idea about microservices, Microservices aren't telling you to
break your project down based on the tier, such as JMS, UI, logging, etc.
• We need to break it down by function.
• A complete function and its functionality may consist of UI, business, logging, JMS, data access,
JNDI lookup service, etc.
• The function should not be divisible and not dependent on other functions.
• Services in a microservice architecture (MSA) are often processes that communicate with each
other over a network in order to fulfill a goal using technology-agnostic protocols such as HTTP.
• However, services might also use other kinds of inter-process communication mechanisms
such as shared memory.
• Services might also run within the same process.

• With Microservices Architecture, The developer is only concentrated on a particular service, so
the code base will be very small, and the developer will know the code very well.
• When one service needs to talk with another service, they can talk via API, specifically by a
REST service. A REST service is the medium to communicate through, so there is little
transformation.
• Unlike SOA, a microservice message bus is much thinner than an ESB, which does lots of
transformation, categorization, and routing.
• There is no centralized database. Each module has its own, so there's data decentralization.
• You can use NoSQL or a relational database depending on the module, which introduces that
polyglot persistence.
• A lot of people think SOA and Microservices are the same thing.
• By definition, they look the same, but SOA is used for communicating different systems over an
ESB, where the ESB takes a lot of responsibility to manage data, do categorization, etc.

• As microservices communicate through REST, the transformation scope is very small — only
one service is dependent on another service via API call.
• Microservice architectures will use libraries, but their primary way of componentizing their
own software is by breaking down into services.
• We define libraries as components that are linked into a program and called using in-memory
function calls.
• Microservices are out-of-process components who communicate with a mechanism such as a
web service request, or remote procedure call.
• One main reason for using services as components (rather than libraries) is that services are
independently deployable.
• But if that application is decomposed into multiple services, you can expect many single
service changes to only require that service to be redeployed.
• The aim of a good microservice architecture is to minimize these through cohesive service
boundaries and evolution mechanisms in the service contracts.

• Microservices are organized around capabilities, e.g., user interface front-end,
recommendation, logistics, billing, etc.
• Microservices are small in size, messaging enabled, bounded by contexts, autonomously
developed, independently deployable, decentralized and built and released with automated
processes.
• Microservices-based architecture naturally enforces a modular structure.
• Microservices-based architecture defines a continuous delivery software development
process.
• A change to a small part of the application only requires one or a small number of services to
be rebuilt and redeployed.
• Microservices-based architecture adheres to principles such as fine-grained interfaces (to
independently deployable services), business-driven development (e.g. domain-driven design),
IDEAL cloud application architectures, polyglot programming and persistence with holistic
service monitoring.

Microservices Design Pattern
• There's more than one way to build microservices. Learn the Aggregator, Proxy, Chained,
Branch, Shared Data, and Asynchronous Messaging Microservice Design Patterns.
• Aggregator Microservice Design Pattern:
• The first, and probably the most common, is the aggregator microservice design pattern.
• In its simplest form, Aggregator would be a simple web page that invokes multiple services
to achieve the functionality required by the application.
• Since each service (Service A, Service B, and Service C) is exposed using a lightweight REST
mechanism, the web page can retrieve the data and process/display it accordingly.
• If some sort of processing is required, say applying business logic to the data received from
individual services, then you may likely have a CDI bean that would transform the data so
that it can be displayed by the web page.
• Another option for Aggregator is where no display is required, and instead it is just a higher
level composite microservice which can be consumed by other services.

Aggregator Microservice Design Pattern

• Aggregator Microservice Design Pattern:
• The aggregator would just collect the data from each of the individual microservice, apply
business logic to it, and further publish it as a REST endpoint, this can then be consumed by
other services that need it.
• This design pattern follows the DRY principle. If there are multiple services that need
to access Service A, B, and C, then its recommended to abstract that logic into a composite
microservice and aggregate that logic into one service.
• An advantage of abstracting at this level is that the individual services, i.e. Service A, B, and
C can involve independently and the business need is still provided by the composite
microservice.
• Aggregator can scale independently on X-axis and Z-axis as well.
• So if its a web page then you can spin up additional web servers, or if its a composite
microservice using Java EE, then you can spin up additional Wildfly instances to meet the
growing needs.

• Proxy Microservice Design Pattern:
• Proxy microservice design pattern is a variation of Aggregator.
• In this case, no aggregation needs to happen on the client but a different microservice may
be invoked based upon the business need.
• Just like Aggregator, Proxy can scale independently on X-axis and Z-axis as well.
• You may like to do this where each individual service need not be exposed to the consumer
and should instead go through an interface.
• The proxy may be a dumb proxy in which case it just delegates the request to one of the
services.
• Alternatively, it may be a smart proxy where some data transformation is applied before the
response is served to the client.
• A good example of this would be where the presentation layer to different devices can be
encapsulated in the smart proxy.

Proxy Microservice Design Pattern

• Chained Microservice Design Pattern:
• Chained microservice design pattern produce a single consolidated response to the
request.
• In this case, the request from the client is received by Service A, which is then
communicating with Service B, which in turn may be communicating with Service C.
• All the services are likely using a synchronous HTTP request/response messaging.
• The request from Service B to Service C may look completely different as the request from
Service A to Service B.
• Another important aspect to understand here is to not make the chain too long.
• This is important because the synchronous nature of the chain will appear like a long wait at
the client side, especially if its a web page that is waiting for the response to be shown.
• A chain with a single microservice is called singleton chain. This may allow the chain to be
expanded at a later point.

Chained Microservice Design Pattern
•

• Branch Microservice Design Pattern:
• Branch microservice design pattern extends Aggregator design pattern and allows
simultaneous response processing from two, likely mutually exclusive, chains of
microservices.
• This pattern can also be used to call different chains, or a single chain, based upon the
business needs.
• Service A, either a web page or a composite microservice, can invoke two different chains
concurrently in which case this will resemble the Aggregator design pattern.
• Alternatively, Service A can invoke only one chain based upon the request received from the
client.
• This may be configured using routing of JAX-RS or Camel endpoints, and would need to be
dynamically configurable.

Branch Microservice Design Pattern

• Shared Data Microservice Design Pattern:
• One of the design principles of microservice is autonomy.
• That means the service is full-stack and has control of all the components – UI, middleware,
persistence, transaction.
• This allows the service to be polyglot and use the right tool for the right job. For example, if
a NoSQL data store can be used if that is more appropriate instead of jamming that data in a
SQL database.
• In this design pattern, some microservices, likely in a chain, may share caching and database
stores. This would only make sense if there is a strong coupling between the two services.
• This would certainly be an anti-pattern for greenfield applications that are design based
upon microservices.
• If only a SQL database is used in the monolithic application, denormalizing the database
would lead to duplication of data, and possibly inconsistency.

Shared Data Microservice Design Pattern

• Asynchronous Messaging Microservice Design Pattern:
• While REST design pattern is quite prevalent and well understood, but it has the limitation
of being synchronous, and thus blocking.
• Asynchrony can be achieved but that is done in an application specific way.
• Some microservice architectures may elect to use message queues instead of
REST request/response because of that.
• In this design pattern, Service A may call Service C synchronously which is then
communicating with Service B and D asynchronously using a shared message queue. Service
A -> Service C communication may be asynchronous, possibly using WebSockets, to achieve
the desired scalability.
• A combination of REST request/response and pub/sub messaging may be used to
accomplish the business need.
• Coupling vs Autonomy in Microservices is a good read on what kind of messaging patterns
to choose for your microservices.

Asynchronous Messaging Microservice Design Pattern

Operational Challenges With Microservice
• Microservices increase operational complexity since you need to rethink operations from
a very fundamental standpoint, you need to consider the following aspects:
• Infrastructure: Defining infrastructure requirements for microservices and then provisioning
and maintaining infra for each microservice adds a degree of complexity that most Ops
engineers working on monoliths are not accustomed to.
• Load balancing and scaling: You will likely need a scaling strategy that is much more
complicated than for monolithic applications, which are always scaled out (x-axis). With
microservices, you will need to figure out if you need to scale all services or just a subset
when there is a spike in demand. Your Ops team will need to understand y axis scaling since
the microservices approach is consistent with it and z axis scaling to get the benefits of x
and y.
• Service discovery: The set of service instances in a microservices world changes dynamically
due to scaling and upgrades. Also, services have dynamic network locations, so you need a
way for new service instances to be discovered.
• Monitoring: This has to be configured and maintained for every microservice, increasing the
complexity for Ops engineer(s).

Microservice Vs SOA
• SOA:
• A Service Oriented Architecture is a software architecture pattern, which application
components provide services to other components via a communications protocol over
a network.
• The communication can involve either simple data passing or it could involve two or more
services coordinating connecting services to each other. Services (such as RESTful Web
services) carry out some small functions, such as validating an order, activating account, or
providing shopping cart services.
• Microservice:
• Microservices is a software architecture pattern in which complex applications are
composed of small, independent processes communicating with each other using language-
agnostic APIs.
• Microservices must be a real need in the system architecture as it could be designed
wrongly. It means a service should be independently deployable, or be able to shut-down a
service when is not required in the system and that should not have any impact on other
services. The following figure shows a quick view of a Microservices architecture.

Microservice Vs SOA
• SOA:
• A Service Oriented Architecture is a software architecture pattern where application
components provide services to other components via a communications protocol over
a network.
• The communication can involve either simple data passing or it could involve two or more
services coordinating connecting services to each other. Services (such as RESTful Web
services) carry out some small functions, such as validating an order, activating account, or
providing shopping cart services.
• Microservice:
• Microservices is a software architecture pattern in which complex applications are
composed of small, independent processes communicating with each other using language-
agnostic APIs.
• Microservices must be a real need in the system architecture as it could be designed
wrongly. It means a service should be independently deployable, or be able to shut-down a
service when is not required in the system and that should not have any impact on other
services.

Microservice Vs SOA
SOA Microservice

Microservice Vs SOA
• Both architectures have similar pros and cons and some differences.
• In both architectures, each service unlike a monolithic architecture has a certain
responsibility.
• In Microservice the services can be developed in various technology stacks which
bring technology diversity into the development team.
• In SOA the development of services can be organized within multiple teams, however, each
team needs to know about the common communication mechanism.
• In microservices, services can operate and be deployed independently of other services,
unlike SOA.
• So, it is easier to deploy new versions of services frequently or scale a service
independently.
• In both architectures, developers must deal with the complexity of architecture and a
distributed system.
• Developers must implement the inter-service communication mechanism between
microservices (if the message queue is used in Microservice architectures) or within ESB
and services.

Microservices Security
• There is virtually no situation in software architecture that entirely frees you from security
considerations.
• With microservices, some issues become more distinct and a lot harder. However, there are
also a few features of microservices that can bolster security.
• With microservices, the network is still a bottleneck.
• Things like access control, which the industry already understands thoroughly within the
realm of monolithic applications.
• This paves the way for debates and scrutiny over whether a microservices architecture
actually solves more problems than it creates.
• Your decision to use microservices should always be conditional.
• When you've done your due diligence and decided that microservices are right for you, it's
time to make sure that all of your applications' security demands are met.

• Use OAuth for user identity and access control:
• The overwhelming majority of applications are going to need to perform some level
of access control and authorization handling.
• OAuth/OAuth2 is practically the industry standard as far as user authorization goes.
• While building your own custom authorization protocol is clearly an option, many out
there don't recommend it unless you have strong and very specific reasons for doing so.
• While OAuth2 isn't perfect, it's a widely adopted standard.
• The advantage of using it is that you can rely on libraries and platforms that will greatly
accelerate your development phase.
• By the same token, several solutions for improving the security level of your OAuth-based
authorization service have already been built by some of the biggest companies and
smartest engineers around.

• Use a distributed firewall with centralized control:
• For the most part, this is still uncharted territory, but I believe that a firewall that allows
users more granular control over each and every microservice (as attempted by Project
Calico) has got to be the way we build firewalls for microservices.
• Get your containers out of the public network:
• An API gateway establishes a single entry point for all requests coming from all clients. It
subsequently knows how to provide an interface for all of your microservices.
• By using this technique you can secure all of your microservices behind a firewall, allowing
the API gateway to handle external requests and then talk to the microservices behind the
firewall.

• Use security scanners for your containers:
• Within your automated testing suite, it would make sense to include periodic vulnerability
and security scanning for your containers.
• The chief open source actor in this space appears to be Clair, from CoreOS.
• Docker Security Scanning and Twistlock are a couple of commercial options.
• Something else to keep in mind here is that the container image itself may not necessarily
be trusted unless its signature has been verified.
• Monitor everything with a tool:
• You can't afford to run a distributed system without a solid, advanced, and reliable
monitoring platform.
• Built originally by engineers at SoundCloud, Prometheus is an open source monitoring
platform and a part of the Cloud Native Computing Foundation.

Pros and Cons of Microservices
Pros Cons
Strong Module Boundaries: Microservices reinforce
modular structure, which is particularly important for
larger teams.
Distribution: Distributed systems are harder to program,
since remote calls are slow and are always at risk of
failure.
Independent Deployment: Simple services are easier to
deploy, and since they are autonomous, are less likely to
cause system failures when they go wrong.
Eventual Consistency: Maintaining strong consistency is
extremely difficult for a distributed system, which means
everyone has to manage eventual consistency.
Technology Diversity: With microservices you can mix
multiple languages, development frameworks and data-
storage technologies
Operational Complexity: You need a mature operations
team to manage lots of services, which are being
redeployed regularly.

THANKS
• If you feel it is helpful and worthy to share with other people, please share the same

Microservice's in detailed

More Related Content

What's hot

Viewers also liked

Similar to Microservice's in detailed

More from Mohammed Fazuluddin

Recently uploaded

Microservice's in detailed