Download - 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
MICROSERVICES IN A NUTSHELL
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 )
MICROSERVICES IN A NUTSHELL
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 IN A NUTSHELL
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.
MICROSERVICES IN A NUTSHELL
DECOMPOSED VERSION OF TAXI PROJECT‣ Each functional area
of the application isnow implemented by its own microservice.
MICROSERVICES IN A NUTSHELL
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
MICROSERVICES IN A NUTSHELL
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 )
MICROSERVICES IN A NUTSHELL
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
PROS AND CONS OF MICROSERVICES
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.
PROS AND CONS OF MICROSERVICES
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
PROS AND CONS OF MICROSERVICES
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
PROS AND CONS OF MICROSERVICES
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
PROS AND CONS OF MICROSERVICES
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.
PROS AND CONS OF MICROSERVICES
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 )
SOLID DEFINITION OF MICROSERVICES
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.
SOLID DEFINITION OF MICROSERVICES
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!
SOLID DEFINITION OF MICROSERVICES
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 )
SOLID DEFINITION OF MICROSERVICES
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.
SOLID DEFINITION OF MICROSERVICES
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)
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.