Movatterモバイル変換

Microservice ArchitectureViraj Brian Wijesuriyavbw@ucsc.cmb.ac.lk1SCS 4120 - Software Engineering IVBACHELOR OF SCIENCE HONOURS IN COMPUTER SCIENCEBACHELOR OF SCIENCE HONOURS IN SOFTWARE ENGINEERINGAll in One Place Lecture NotesDistribution Among Friends OnlyAll copyrights belong to their respective owners

• Definition:– In short, the microservice architectural style is an approach to developing asingle application as a suite of small services, each running in its own processand communicating with lightweight mechanisms, often an HTTP resourceAPI. These services are built around business capabilities and independentlydeployable by fully automated deployment machinery. There is a bareminimum of centralized management of these services, which may bewritten in different programming languages and use different data storagetechnologies [martinfowler.com]• On the logical level, microservice architectures are defined by a– functional system decomposition into manageable and independentlydeployable componentsSEIV – Microservices – Introduction2What is Microservices Architecture?

• 2011: First discussions using this term at asoftware architecture workshop near Venice• May 2012: microservices settled as the mostappropriate term• March 2012: “Java, the Unix Way” at 33rddegree by James Lewis• September 2012: “μService Architecture“ atBaruco by Fred George• All along, Adrian Cockroft pioneered thisstyle at Netflix as “fine grained SOA”SEIV – Microservices – Introduction3HistoryJames LewisFred GeorgeAdrian Crockcroft

• Area of consideration– Web systems– Built collaboratively by several development teams– With traffic load that requires horizontal scaling (i.e. loadbalancing across multiple copies of the system)• Observation– Such systems are often built as monoliths or layered systemsSEIV – Microservices – Introduction4The Problem

• One build and deployment unit.• One code base.• One technology stack (Linux, JVM, Tomcat, Libraries).• Benefits– Simple mental model for developers• one unit of access for coding, building, and deploying– Simple scaling model for operations• just run multiple copies behind a load balancerSEIV – Microservices – Introduction5Software Monolith

• Huge and intimidating code base for developers.• Development tools get overburdened– refactorings take minutes– builds take hours– testing in continuous integration takes days• Scaling is limited– Running a copy of the whole system is resource intense– It doesn’t scale with the data volume out of the box• Deployment frequency is limited– Redeploying means halting the whole system– Redeployments will fail and increase the perceived risk of deploymentSEIV – Microservices – Introduction6Problems with Software Monolith

SEIV – Microservices – Introduction7Monolith ArchitectureLoad BalancerMonolithic AppAccountComponentCatalogComponentRecommendationComponentCustomer ServiceComponentDatabaseMonolithic applications can be successful, but increasingly people are feelingfrustrations with them - especially as more applications are being deployed tothe cloud .

SEIV – Microservices – Introduction8Monolith vs Microservices

• A layered system decomposes a monolith intolayers.• Usually: presentation, logic, data access.• At most one technology stack per layer– Presentation: Linux, JVM, Tomcat, Libs, EJB client,JavaScript– Logic: Linux, JVM, EJB container, Libs– Data Access: Linux, JVM, EJB JPA, EJB container, Libs• Benefits– Simple mental model, simple dependencies– Simple deployment and scaling modelSEIV – Microservices – Introduction9Layered Systems

• Still huge codebases (one per layer).• ... with the same impact on development, building, anddeployment.• Scaling works better, but still limited.• Staff growth is limited: roughly speaking, one team per layer workswell– Developers become specialists on their layer.– Communication between teams is biased by layer experience (or lackthereof).SEIV – Microservices – Introduction10Problems with Layered Systems

SEIV – Microservices – IntroductionService Oriented Architecture• Maximum reuse [GOOD]• Maximum canonicality [GOOD] 11Service Oriented Architecture

SEIV – Microservices – IntroductionService Oriented Architecture• Incremental change [BAD]• Operationally complex [BAD] 12Problems with Service Oriented Architecture

SEIV – Microservices – Introduction13Lot of Services!!!

• Applications and teams need to grow beyond the limits imposed bymonoliths and layered systems, and they do in an uncontrolled way.• Large companies end up with landscapes of layered systems thatoften interoperate in undocumented ways.• These landscapes then often break in unexpected ways.• How can a company grow and still have a working IT architectureand vision?– Observing and documenting successful companies (e.g. Amazon, Netflix) leadto the definition of microservice architecture principles.SEIV – Microservices – Introduction14Growing Beyond Limits

SEIV – Microservices – Introduction15Need of an Architectural Pattern

Yesterday’s best practice is tomorrow’santi-pattern.We inadvertently build architectures tosolve outdated problems.SEIV – Microservices – Introduction16Problem with Architectural Patterns

“organizations which design systems ...are constrained to produce designs whichare copies of the communicationstructures of these organizations”—Melvin ConwaySEIV – Microservices – Introduction17Conway’s Law

SEIV – Microservices – Introduction18Valued Business DriversBetter• Resilient• TechnologychoiceCheaper• Test effort• Cost ofmaintainingFaster• Change• Deployment• Execution

SEIV – Microservices – Introduction19Trends in Software DevelopmentPlatform asa ServiceAutonomousteamsContinuousDeliveryAgileOrganizationReactivemanifesto

SEIV – Microservices – Introduction20AvailabilityA single missing “;” brought down the Netflix website for manyhours (~2008)

• The term “micro” refers to the sizing: a microservice must bemanageable by a single development team (5-9 developers).• Functional system decomposition means vertical slicing (in contrastto horizontal slicing through layers).• Independent deployability implies no shared state and inter-process communication (often via HTTP RESTish interfaces).• Microservice is the ﬁrst architectural style developed for post-Continuous Delivery.SEIV – Microservices – Introduction21What is Microservices Architecture?

SEIV – Microservices – Introduction22Other definitions• Small andfocused ondoing onething well• Autonomous“Loosely coupled serviceoriented architecture withbounded contexts”Adrian Cockcroft (Netflix)“SOA done right”Anonymous“… services are independently deployable andscalable, each service also provides a firmmodule boundary, even allowing for differentservices to be written in different programminglanguages.”Martin Fowler (Thoughtworks)

• Each microservice is functionally complete with– Resource representation– Data management• Each microservice handles one resource (or verb), e.g. Clients,Shop Items, Carts, Checkout• Microservices are fun-sized services, as in “still fun to developand deploy”• Independent Deployability is key• It enables separation and independent evolution of– code base– technology stacks– scaling– and features, tooSEIV – Microservices – Introduction23Points about Microservices Architecture

• Each service has its own software repository.• Codebase is maintainable for developers – it fits into theirbrain.• Tools work fast – building, testing, refactoring code takesseconds.• Service startup only takes seconds.• No accidental cross-dependencies between code bases.SEIV – Microservices – Introduction24Independent Codebase

• Each service is implemented on its own technology stacks.• The technology stack can be selected to fit the task best.• Teams can also experiment with new technologies within asingle microservice.• No system-wide standardized technology stack also means– No struggle to get your technology introduced to the canon– No piggy-pack dependencies to unnecessary technologies or libraries– It‘s only your own dependency hell you need to struggle with• Selected technology stacks are often very lightweight– A microservice is often just a single process that is started viacommand line, and not code and configuration that is deployed to acontainer.SEIV – Microservices – Introduction25Independent Technology Stack

• Each microservice can be scaled independently• Identified bottlenecks can be addressed directly• Data sharding can be applied to microservices as needed• Parts of the system that do not represent bottlenecks canremain simple and un-scaled• Microservices can be extended without affecting otherservices– For example, you can deploy a new version of (a part of) the UIwithout re-deploying the whole system– You can also go so far as to replace the service by a complete rewrite– But you have to ensure that the service interface remains stableSEIV – Microservices – Introduction26Independent Scaling

• Communication between microservices is often standardizedusing• HTTP(S) – battle-tested and broadly available transportprotocol• REST – uniform interfaces on data as resources with knownmanipulation means• JSON – simple data representation formatREST and JSON are convenient because they simplify interfaceevolutionSEIV – Microservices – Introduction27Inter-communication

• Bounded Context is a central pattern in Domain-Driven Design.• It is the focus of DDD's strategic design section which is all about dealing withlarge models and teams.• DDD deals with large models by dividing them into different Bounded Contextsand being explicit about their interrelationships.SEIV – Microservices – Introduction28Bounded Context

• In computing, a polyglot is a computer program or script written in a valid formof multiple programming languages, which performs the same operations oroutput independent of the programming language used to compile or interpret it• Generally polyglots are written in a combination of C (which allows redefinitionof tokens with a preprocessor) and a scripting language such as Lisp, Perl or sh.• Complex applications combine different types of problems, so picking the rightlanguage for the job may be more productive than trying to fit all aspects into asingle language.• One of the interesting consequences of this is that we are gearing up for a shiftto polyglot persistence- where any decent sized enterprise will have a variety ofdifferent data storage technologies for different kinds of data.• This polyglot affect will be apparent even within a single application, a complexenterprise application uses different kinds of data, and already usually integratesinformation from different sources.SEIV – Microservices – Introduction29Polyglot Persistence

• Features:– Distributed architecture– separately deployed components– Service components– Bounded context– Service orchestrationSEIV – Microservices – Introduction30Microservice Architecture (1)

SEIV – Microservices – Introduction31Microservice Architecture (2)Load BalancerAccount Service CatalogServiceRecommendationServiceCustomer ServiceServiceCatalogDBAPI GatewayCustomerDB

SEIV – Microservices – Introduction32Simple and Lightweight

SEIV – Microservices – Introduction33Independent Processes

SEIV – Microservices – Introduction34Language Agnostic APIs and Decoupled Services"Language agnostic" describes a software development paradigm where aparticular language is chosen because of its appropriateness for a particular task(taking into consideration all factors, including ecosystem, developer skill-sets,performance, etc.), and not purely because of the skill-set available within adevelopment team.

SEIV – Microservices – Introduction35Size matters (not)• It’s not aboutlines of code used• Small enough to– Be handled by asingle team– Not feel “big”

SEIV – Microservices – Introduction36SlicingChange your approach to vertical partitions• Modeled after organization’s domains• Owned by team• Top to bottom• Isolated from each other as much as possible

SEIV – Microservices – Introduction37From monolithic to microservices

SEIV – Microservices – SOA vs MicroservicesACID vs BASE38

SEIV – Microservices – SOA vs MicroservicesMultiple services work together as a system39

SEIV – Microservices – SOA vs MicroservicesSOA vs Microservices• What “Traditional” SOA got Right– Breaking monoliths into services– Focus on integration over internal coupling– Prefer BASE to ACID• What “Traditional” SOA Missed– Architecture is abstract until operationalized.– Impact of Conway’s Law– Didn’t support easy change (ESB pattern)– It is often thought as decomposition within tiers, and introducinganother tier – the service orchestration tier40

SEIV – Microservices – SOA vs MicroservicesSOA vs Microservices41Microservices Focus on ChangeThe API isthecontract…And theproduct“This iswhat Ineed…”“Here iswhat Ihave tooffer…”WSDL istheContractBackendApp is theProductAPIManagementPublic APIs:Better CustomerExperienceSOA:Better Apps +IntegrationMicroservices:Improved DeveloperExperience

SEIV – Microservices – CharacteristicsCharacteristics• Componentization via Services• Organized around Business Capabilities• Products not Projects• Smart endpoints and dumb pipes• Decentralized Governance• Decentralized Data Management• Infrastructure Automation• Design for failure• Evolutionary Design42

SEIV – Microservices – CharacteristicsComponentization via Services• What is a component? We think about how it relates to softwareinstead of software itself– Independently Replaceable, Independently Updatable• How we can do this: Libraries or Services?  We do with services• Interaction mode: share-nothing, cross-process communication• Independently deployable (with all the benefits), Explicit, REST-basedpublic interface• Sized and designed for replaceability– Upgrading technologies should not happen big-bang, all-or-nothing-style• Downsides– Communication is more expensive than in-process– Interfaces need to be coarser-grained– Re-allocation of responsibilities between services is harder 43

SEIV – Microservices – CharacteristicsOrganized around Business Capabilities (1)• The microservice approach to division is different,splitting up into services organized around businesscapability.• Such services take a broad-stack implementation ofsoftware for that business area, including user-interface,persistant storage, and any external collaborations.• Consequently the teams are cross-functional, includingthe full range of skills required for the development:user-experience, database, and project management.• Line of separation is along functional boundaries, notalong tiers.44

SEIV – Microservices – CharacteristicsOrganized around Business Capabilities (2)45Will this work?

SEIV – Microservices – CharacteristicsOrganized around Business Capabilities (3)46

SEIV – Microservices – CharacteristicsProducts not Projects• Most application development efforts that we see use a projectmodel: where the aim is to deliver some piece of software which isthen considered to be completed.• On completion the software is handed over to a maintenanceorganization and the project team that built it is disbanded.• Microservice proponents tend to avoid this model, preferring insteadthe notion that a team should own a product over its full lifetime.• A common inspiration for this is Amazon's notion of "you build, yourun it" where a development team takes full responsibility for thesoftware in production.• This brings developers into day-to-day contact with how theirsoftware behaves in production and increases contact with theirusers, as they have to take on at least some of the support burden.47

SEIV – Microservices – CharacteristicsSmart endpoints and dumb pipes (1)48What’s the problem here?

SEIV – Microservices – CharacteristicsSmart endpoints and dumb pipes (2)• Applications built from microservices aim to be as decoupled and ascohesive as possible - they own their own domain logic and act more asfilters in the classical Unix sense - receiving a request, applying logic asappropriate and producing a response.• These are choreographed using simple RESTish protocols rather thancomplex protocols such as WS-Choreography or BPEL or orchestration by acentral tool.• Microservice teams use the principles and protocols that the world wideweb (and to a large extent, Unix) is built on.• Often used resources can be cached with very little effort on the part ofdevelopers or operations folk.• Uses HTTP request-response with resource API.• Messaging over a lightweight message bus. The infrastructure chosen istypically dumb (dumb as in acts as a message router only) - simpleimplementations such as RabbitMQ or ZeroMQ don't do much more thanprovide a reliable asynchronous fabric - the smarts still live in the end pointsthat are producing and consuming messages; in the services. 49

SEIV – Microservices – CharacteristicsDecentralized Governance• Principle: focus on standardizing the relevant parts, and leverage battle-tested standards and infrastructure• Rather than use a set of defined standards written down somewhere onpaper, prefer the idea of producing useful tools that other developers canuse to solve similar problems to the ones they are facing.• These tools are usually harvested from implementations and shared with awider group, sometimes, but not exclusively using an internal open sourcemodel.• What needs to be standardized– Communication protocol (HTTP)– Message format (JSON)• What should be standardized– Communication patterns (REST)• What doesn‘t need to be standardized– Application technology stack50

SEIV – Microservices – CharacteristicsDecentralized Data Management• Each service can choose the persistence solution thatfits best its– Data access patterns– Scaling and data sharding requirements• Only few services really need enterprisey persistence• Structured programming – shared global state is a bad thing!!!• Microservices prefer letting each service manage its own database, either differentinstances of the same database technology, or entirely different database systems -an approach called Polyglot Persistence. You can use polyglot persistence in amonolith, but it appears more frequently with microservices.51

SEIV – Microservices – CharacteristicsInfrastructure Automation• Having to deploy significant number of servicesforces operations to automate the infrastructure for– Deployment (Continuous Delivery)– Monitoring (Automated failure detection)– Managing (Automated failure recovery)• Consider that:– Amazon AWS is primarily an internal service– Netflix uses Chaos Monkey to further enforceinfrastructure resilience52

SEIV – Microservices – CharacteristicsInfrastructure as a code practices1. Use definition files2. Self-documented systems and processes3. Version all things4. Continuously test systems and processes5. Small changes rather than batches6. Keep services available continuously53

SEIV – Microservices – CharacteristicsDesign for Failure• A consequence of using services as components, is that applicationsneed to be designed so that they can tolerate the failure of services.• Since services can fail at any time, it's important to be able to detectthe failures quickly and, if possible, automatically restore service.• Microservice applications put a lot of emphasis on real-timemonitoring of the application, checking both architectural elements(how many requests per second is the database getting) and businessrelevant metrics (such as how many orders per minute are received).• Semantic monitoring can provide an early warning system ofsomething going wrong that triggers development teams to follow upand investigate.• Microservice teams would expect to see sophisticated monitoring andlogging setups for each individual service such as dashboards showingup/down status and a variety of operational and business relevantmetrics 54

SEIV – Microservices – CharacteristicsEvolutionary Design• The key property of a component is the notion of independent replacementand upgradeability - which implies we look for points where we can imaginerewriting a component without affecting its collaborators.• Indeed many microservice groups take this further by explicitly expectingmany services to be scrapped rather than evolved in the longer term.• The Guardian website is a good example of an application that was designedand built as a monolith, but has been evolving in a microservice direction.• The monolith still is the core of the website, but they prefer to add newfeatures by building microservices that use the monolith's API.• This approach is particularly handy for features that are inherentlytemporary, such as specialized pages to handle a sporting event.• Such a part of the website can quickly be put together using rapiddevelopment languages, and removed once the event is over.• Similar approaches at financial institutions where new services are addedfor a market opportunity and discarded after a few months or even weeks.55

SEIV – Microservices – Why and WhenWhy use Microservices Architecture• Faster and simpler deployments and rollbacks– Independent Speed of Delivery (by different teams)• Right framework/tool/language for each domain• Greater Resiliency– Fault Isolation• Better Scaling– A microservices architecture puts each element of functionalityinto a separate service and scales by distributing these servicesacross servers, replicating as needed.• Better Availability– If architected right56

SEIV – Microservices – Why and WhenWhen to use Microservices Architecture (1)• When you need to support Desktop, web , mobile, Smart TVs,Wearable, etc... or you don't know in future which kind of devices youneed to support.• You are developing a server-side enterprise application. It mustsupport a variety of different clients including desktop browsers,mobile browsers and native mobile applications. The application mightalso expose an API for 3rd parties to consume. It might also integratewith other applications via either web services or a message broker.The application handles requests (HTTP requests and messages) byexecuting business logic; accessing a database; exchanging messageswith other systems; and returning a HTML/JSON/XML response.• You have lot of people in your organization and organize them in waythat make sense/break teams into useful group.57

SEIV – Microservices – Why and WhenWhen to use Microservices Architecture (2)58microservices approach without good cause - Microservice Envy

SEIV – Microservices – Why and WhenMicroservice Premium59Microservice Premium

SEIV – Microservices – ChallengesMicroservices Challenges60Can lead to chaos if not designed right …

SEIV – Microservices – ChallengesComplexity• Distributed Systems are inherently Complex– N/W Latency, Fault Tolerance, Retry storms ..• Operational Overhead– TIP: Embrace DevOps Model61

SEIV – Microservices – ChallengesService Discovery (1)• 100s of MicroServices– Need a Service Metadata Registry (DiscoveryService)62Account Service CatalogServiceRecommendationServiceCustomer ServiceServiceXService YServiceZServiceRegistryService(e.g. Netflix Eureka)

SEIV – Microservices – ChallengesService Discovery (2)63

SEIV – Microservices – ChallengesChattiness (and Fan Out)• The biggest issue in changing a monolith into microservices lies inchanging the communication pattern.• A naive conversion from in-memory method calls to RPC leads to chattycommunications which don't perform well.• Instead you need to replace the fine-grained communication with acoarser -grained approach.642 Billion Requests per day on Edge ServiceResults in ~20 Billion Fan out requests in ~100 MicroServices1 Request 1 RequestMonolithic App MicroServices

SEIV – Microservices – ChallengesMicroservice Silo Architecture65

SEIV – Microservices – ChallengesTesting• A single microservice isn‘t the whole system.• A clear picture of upstream and downstreamservices is needed for integration testing• Refer to deck: http://martinfowler.com/articles/microservice-testing/66

SEIV – Microservices – ChallengesPrerequisites (1)• Before you go into production with a microservices system,you need to ensure that you have key prerequisites in place– Rapid Provisioning• Dev teams should be able to automatically provision newinfrastructure– Basic Monitoring• Essential to detect problems in the complex systemlandscape– Rapid Application Deployment– Devops Culture67microservices approach without good cause - Microservice Envy

SEIV – Microservices – ChallengesPrerequisites (2)• These are optional things will improve your microservicessystem– Traceable Business Transactions– Continuous Delivery– Product-centered teams– Multi-Dev Environment– Infrastructure as code– Have experiences and Knowledgeable about Domain-DrivenDesign68

SEIV – Microservices – ChallengesVersioning (1)• With a monolith any changes require a full build anddeployment of the entire application.• With microservices, however, you only need to redeploy theservice(s) you modified.• This can simplify and speed up the release process.• The downside is that you have to worry about changes to oneservice breaking its consumers.• The traditional integration approach is to try to deal with thisproblem using versioning, but the preference in themicroservice world is to only use versioning as a last resort. 69

SEIV – Microservices – ChallengesVersioning (2)• Microservice architectures enable independent evolution ofservices – but how is this done without breaking existingclients?• There are two answers– Version service APIs on incompatible API changes– Using JSON and REST limits versioning needs of service APIs• Versioning is key– Service interfaces are like programmer APIs – you need to know whichversion you program is in.– As service provider, you need to keep old versions of your interfaceoperational while delivering new versions.70

SEIV – Microservices – ChallengesAPI compatibility• There are two types of compatibility• Forward Compatibility– Upgrading the service in the future will not break existing clients– Requires some agreements on future design features, and the designof new versions to respect old interfaces– imagine processing new messages arriving to the service with newdata.– Postel’s law: ‘be conservative in what you do, beliberal in what you accept from others’• Backward Compatibility– Newly created service is compatible with old clients– Requires the design of new versions to respect old interfacesThe hard type of compatibility is forward compatibility!71

SEIV – Microservices – ChallengesFurther Challenges• Transactions– Instead of distributed transactions, compensations are used (as inSOA)• Authentication– Is often offloaded to reverse proxies making use of authentication(micro)services• Request logging– Pass along request tokens– Add them to the log– Perform log aggregation72

SEIV – Microservices – BenefitsBenefits of Microservices• Asynchronicity• Integration & Disintegration• Complected (intertwined)Deployments• Evolutionary Architecture• Reduction of release risk• Backends for Frontend73

SEIV – Microservices – RecommendationsInverse Conway Maneuver74Build teams that look like the architecture you want(and it will follow).

SEIV – Microservices – RecommendationsEfferent Coupling• Strive for low efferent coupling for your team.• Efferent Coupling (Ce) is also known as OutgoingDependencies or the Number of Types inside a Package thatDepend on Types of other Packages. Ce is a metric forpackages. In short, this measure includes all the types withinthe source of the measured package referring to the types notin the measured package.• Teams with low efferent coupling deliver relativelyindependently into a common integration pipeline (withoutfearing breaking each others builds.75

SEIV – Microservices – RecommendationsDo choreography instead orchestration• What is service orchestration? It's the process of managingdifferent services and the dependencies between themsuch that we promote the principles of loose coupling.• What is choreography? Choreography is the process ofagreeing, between the dancers, how a dance will beperformed before it is performed.• One thing with micro-services that people get caught up onis how to do orchestration. The answer is don't. Instead ofdoing orchestration, do choreography.76

SEIV – Microservices – RecommendationsLow coupling and high cohesion• Low coupling and high cohesion.• Coupling: Measurement of dependency betweentwo components. Expressed as sensitivitytowards propagation of changes and errors.• Cohesion: Degree to which parts of a modulebelong together.77Coincidentalcohesion(worst)• randomLogicalcohesion• same in natureTemporalcohesion• executed at aparticular timeProceduralcohesion• part of fixedexecutionsequenceInformationalcohesion• operating on thesame dataSequentialcohesion• Output of one isused as input byanotherFunctionalcohesion(best)• contributing to asingle task

SEIV – Microservices – RecommendationsMonolith First• Teams using a microservices architecture have a commonpattern.• Almost all the successful microservice stories have started with amonolith that got too big and was broken up• Almost all the cases a system that was built as a microservicesystem from scratch, it has ended up in serious trouble.• This pattern has led many of people to argue that you shouldn'tstart a new project with microservices, even if you're sure yourapplication will be big enough to make it worthwhile.• Instead begin with a monolith, keep it modular, and split it intomicroservices once the monolith becomes a problem.78

SEIV – Microservices – RecommendationsAnother solution to monoliths – Cookie cutter scaling• Microservices is an antidote to monoliths• Cookie cutter scaling is another antidote to monoliths, withthe right build infrastructure and DevOps.79

SEIV – Microservices – EpilogueAdvantages of Microservices• Each micro service is small and focused on a specific feature / businessrequirement.• Microservice can be developed independently by small team ofdevelopers (normally 2 to 5 developers).• Microservice is loosely coupled, means services are independent, in termsof development and deployment both.• Microservice can be developed using different programming language(Personally I don't suggest to do it).• Microservice allows easy and flexible way to integrate automaticdeployment with Continuous Integration tools (for e.g: Jenkins, Hudson,bamboo etc..).• The productivity of a new team member will be quick enough.• Microservice is easy to understand, modify and maintain for a developerbecause separation of code,small team and focused work.80

SEIV – Microservices – EpilogueDisadvantages of Microservices• Microservice architecture brings a lot of operations overhead.• DevOps Skill required (http://en.wikipedia.org/wiki/DevOps).• Duplication of Effort.• Distributed System is complicated to manage .• Default to trace problem because of distributed deployment.• Complicated to manage whole products when number ofservices increases.81

SEIV – Microservices – EpilogueWho uses Microservices?• Most large scale web sites including Twitter, Netflix, Amazonand eBay have evolved from a monolithic architecture to amicroservices architecture.82Microservices at Netflix

SEIV – Microservices – EpilogueBuilding Microservices83Microservices Resource Guide: http://martinfowler.com/microservices/Microservices Articles: http://martinfowler.com/tags/microservices.html

Movatterモバイル変換

Change Language

Microservice Architecture

Embed presentation

Recommended

More Related Content

What's hot

Similar to Microservice Architecture

Recently uploaded

Microservice Architecture