Micro service Arthicetcure

MS IN A NUTSHELL
PROS AND CONS
SOLID DEFINITION OF MS
REFACTORING INTO MS
WHAT WE WILL
SEE

MICROSERVICES IN A NUTSHELL
BUILDING MONOLITHIC
APPLICATIONS
▸ Let’s imagine that you were starting to build
a brand new taxi-hailing application.
▸ use a fancy , well structured generator for
your source code . fire up an IDE and start
coding. ( Folder Structure is not an
architecture! )
▸ Probably ,
▸ Easy to Develop ( well suited IDEs )
▸ Easy to test
▸ Easy to Deploy

MARCHING TOWARDS MONOLITHIC
HELL▸Failure Comes with growing, scaling, and probably cloud deploying.
‣ More agile sprints to enhance your app
‣ more software engineers with different taste of code
‣ HUGE Source code results complication .
‣ slow deployment , event in development !
‣ harder to get collaboration in team
‣ harder to fix a bug
‣ eventually , a bug stays unfixed or never found
‣ low reliability !
‣ huge barrier to adopting new technologies
‣ Sooner or later, a product will fail, or you will end up with a monolithic beast of code ( referred
to as big ball of mud )

OF COURSE , THERE ARE MONOLITHIC
APPS.
▸Benefits of monolithic development
▸Well Known
▸Easy to share and collaborate ( to a limit )
▸IDE-friendly
▸Easy Deployment
▸Suitable for small applications.
▸Unix Core !

MICROSERVICES – TACKLING THE
COMPLEXITY
▸Instead of building a single monstrous, monolithic
application, the idea is to split your application into set of
smaller, interconnected services.
▸Each microservice might have its own hexagon architecture.
▸Each micro service might expose a set of APIs to other
services or clients.

DECOMPOSED VERSION OF TAXI
PROJECT
‣ Each functional area
of the application is
now implemented
by its own
microservice.

THE ART OF SCALING
▸The Microservices
Architecture pattern
corresponds to the Y-axis
scaling of the Scale Cube.
▸Creating multiple
instances at runtime is X-
scaling
▸separation of data or
resource is Z-scaling

DATA MANAGEMENT
▸The Microservices
Architecture pattern
significantly impacts
the relationship
between the
application and the
database
▸No shared database.
▸Results less coupling,
but more data
duplication (
sometimes )

DEPLOYED WITH DOCKER RUNNING ON
AMAZON EC2
▸example of deployment
stack including Docker
containers for each micro
service ( y ) and NGINX
load balancer ( x )

PROS AND CONS OF MICROSERVICES
THE BENEFITS OF MICROSERVICES
▸it tackles the problem of complexity
▸each service would be constrained to scope of one business value ( more on this
later )
▸easier to develop and maintain.
▸enables each service to be developed independently
▸separate teams for each service , different technology stack.
▸enables each microservice to be deployed independently.
▸one team ( UI for example ) can iterate features more rapidly
▸each service to be scaled independently
▸number of nodes per service
▸hardware used for each node

THE DRAWBACKS OF MICROSERVICES
▸there are no silver bullets. Like every other technology, the
Microservices architecture has drawbacks
▸The term Micro-* itself can be a drawback
▸While small services are preferable, it’s important to remember
that they are a means to an end and not the primary goal.
▸The goal of microservices is to sufficiently decompose the
application in order to facilitate agile application development and
deployment.
▸Very small service ~ communication overhead.

CTD.
▸Complexity arises from the fact that a microservices application is
a distributed system
▸Message passing or RPC mechanism.
▸Tolerance for partial failure.
▸much more complex than intra-process method invocation in
monolithic design.
▸Partitioned database architecture
▸transaction affecting multiple entities will happen

CTD.
▸Testing a microservices application is also much more
complex.
▸For a monolithic app, simply run instances and test cases.
▸what happens with having different components having
different dependencies?
▸testing API gateway and communication protocols

CTD.
▸Implementing changes that span multiple services.
▸although its not recommended, but this might happen ( too often =
bad granularity )
▸Attempt to change MS1 , it depends on MS2 and MS3 . which order
of develop and deploy is correct for this patch ?
▸Need to carefully plan and coordinate the rollout of changes to each
of the services.
▸Fortunately, most changes typically impact only one service and
multi-service changes that require coordination are relatively rare

CTD.
▸Deploying a microservices-based application is also much more complex.
▸Monolithic app , simply packaged and deployed on one or more processes.
▸Microservices on the other hand ..
▸typically consists of a large number of services ~ processes ~ physical
nodes ( Netflix 600 nodes etc. )
▸Each service might have multiple runtime instances.
▸Service discovery mechanism.
▸successfully deploying a microservices application requires greater control of
deployment methods by developers, and a high level of automation.

SOMETHING FEELS WRONG ?
▸we mentioned more drawbacks than benefits. (?)
▸they are difficulties, but none of them require Rocket
science to be solved.
▸Complexity created by development team is manageable.
and sometimes useful to overcome a greater complexity.
▸Complexity created by out of hand increasing monolithic pile
of tens of thousands of line son code on the other hand, is
something that will guarantee a failure.

SOLID DEFINITION OF MICROSERVICES
CHARACTERISTICS OF MICROSERVICES
▸Services must have runtime dependency. ( Separate physical nodes, Docker
container, or separate processes on a single machine)
▸Domain Driven Design
▸each team is responsible for developing a functionality or domain around a
business. ( != Technology separation. have one UI team , one Server team
etc. )
▸each development team is likely to be full-stack.
▸Single Responsibility Principle
▸Do one thing. Do it well ( on of SOLID principle demonstrated by Unix utilities
)

CTD.
▸Explicitly Published Interface
▸Each service publishes an explicitly defined interface and
honors that all times.
▸Consuming service only cares about this interface.
▸Contacts are defined between services to standardize
communication.
▸Good practice : Don’t change and contact . Stay backward
compatible if changes are to be made.

CTD.
▸Independently Develop, Deploy, Upgrade, Scale, Replace.
▸Each service can be independently deployed, and redeployed again, without impacting the
overall system.
▸Each service can also scale independently on X-axis (horizontal duplication) or Z-axis
(lookup oriented splits)
▸Implementation of the service, or even the underlying technology stack, can change as
long as the exact same contract is published.
▸A service that requires to store data in a RDBMS can choose MySQL, and another service
that needs to store documents can choose Mongo.
▸Different teams can choose Java EE, NodeJS, Python, or whatever is most efficient for
them.
▸if we can do something, doesn't mean that we should!

CTD.
▸Light-weight Communication
▸Services communicate with each other using a light-
weight communication, such as REST over HTTP. (
Potential bottle neck)
▸An alternative mechanism is to use publish-subscribe
mechanism that supports asynchronous messaging. (
ActiveMQ )

WHERE DOES MICRO SERVICE
ARCHITECTURE STAND ?
▸As emphasized in this presentation, it’s on the either side of monolithic
development.
▸It has great similarity with SOA, but enforcing less composition and only
focusing un splitting and modularizing.
▸Microservices: a software architecture style in which complex applications
are composed of small, independent processes communicating with each
other using language-agnostic APIs.
▸Service-oriented architecture (SOA): an architectural pattern in computer
software design in which application components provide services to other
components via a communications protocol, typically over a network.

WHERE DOES MICRO SERVICE
ARCHITECTURE STAND ? EXAMPLE
▸If Uber were built with a SOA, their services might be:
▸GetPaymentsAndDriverInformationAndMappingDataAPI
▸AuthenticateUsersAndDriversAPI
▸If Uber were built with microservices, their APIs might be more like:
▸SubmitPaymentsService
▸GetDriverInfoService
▸GetMappingDataService
▸AuthenticateUserService
▸AuthenticateDriverService

REFACTORING INTO MICROSERVICES
REFACTORING INTO MICROSERVICES
▸Microservices also does not mean you need to throw away
your existing application.
▸Refactoring may not be trivial but in the long terms this has
benefits.
▸Refactoring a big monolithic application [using
microservices] can be the equivalent of a balloon payment
[for reducing technical debt] … you can pay down technical
debt one service at a time

NOTES
FINAL QUOTES AND NOTES
▸Almost all the successful microservice stories have started
with a monolith that got too big and was broken up.
▸Almost all the cases where I've heard of a system that was
built as a microservice system from scratch, it has ended up
in serious trouble.
▸Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the
organization's communication structure. ( Domain Driven! )
-- Melvyn Conway, 1967

NOTES
▸An Example of an empire of technology built upon micro services :
NETFLIX.
visit : http://netflix.github.io/
▸aside from how they manage their infrastructure, being able to publish
so many independent components ( micro services ) is another benefit.
▸Entire article is available in NGINX website describing how Netflix uses
NGINX for automated deployment and X-Scaling.
▸Docker shines when in comes to deploying micro services ( why
?)(runtime dependency)

NOTES
▸SOLID
▸Single responsibility principle - a class should have only a single responsibility
▸Open/closed principle - software entities … should be open for extension, but
closed for modification.
▸Liskov substitution principle. objects in a program should be replaceable with
instances of their subtypes without altering the correctness of that program.
▸Interface segregation principle. many client-specific interfaces are better than one
general-purpose interface.
▸Dependency inversion principle. one should “Depend upon Abstractions. Do not
depend upon concretions.

Micro service Arthicetcure

More Related Content

What's hot (9)

Similar to Micro service Arthicetcure (20)

Recently uploaded (20)

Micro service Arthicetcure