micro service arthicetcure

MICROSERVICES

INTRODUCTION O

MS IN A NUTSHELLPROS AND CONSSOLID DEFINITION OF MSREFACTORING 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 isnow 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.


THE DRAWBACKS OF MICROSERVICES 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


THE DRAWBACKS OF MICROSERVICES 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


THE DRAWBACKS OF MICROSERVICES 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


THE DRAWBACKS OF MICROSERVICES 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 )


CHARACTERISTICS OF MICROSERVICES 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.


CHARACTERISTICS OF MICROSERVICES 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!


CHARACTERISTICS OF MICROSERVICES 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

FINAL QUOTES AND 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)

http://netflix.github.io/

NOTES

FINAL QUOTES AND 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

Internet