Download presentation
Presentation is loading. Please wait.
1
Microservices Overview
2
What are the most common pain points in contemporary architectures?
Too Complex Apps get too big and complicated for a developer to understand over time. Shared layers (ORM, messaging, etc) have to handle 100% of use cases – no point solutions No Specialization Different parts of applications have different needs – more CPU, more memory, faster network, etc No Specialization Too Complex No Ownership Code falls victim to “tragedy of the commons” – when there’s little ownership, you see neglect Too Slow Teams split up by function – UI, application, middleware, database, etc. Too Slow No Ownership Too Fragile Inefficient Testing Too Fragile A bug will quickly bring down an entire application. Little resiliency Inefficient Testing Each change requires a complete testing cycle. Hard to support continuous delivery
3
How can microservices help?
Applications as monoliths Many, smaller, loosely coupled services Deploy everything, every time Each service can be deployed independently One data store to rule them all Choose the best store for the job Intra-process communication Lightweight communication between services Organized around technology layers Organized around business capabilities Dev is dev, Ops is ops Dev have Ops responsibilities, and vice-versa Server-side state, sessions Stateless instances, use shared store if needed Java can do everything Right technology for the task at hand
4
Microservices, a definition
“[…] the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. (Martin Fowler) Service Platform Monitoring Health Provisioning HA/Tolerance Service Discovery Load Balancing Gateways DevOps HTTP
5
Benefits – Scalability
Allow performance critical components to scale independently from the rest of the system Service Service Service Service Service Service Service Service Service Service Service
6
Benefits – Risk reduction
Update and deploy only the parts that need to be changed, not the entire system Enable powerful deployment patterns: canary deployments, green-blue deployments Service Service Service Service Service Service Service
7
Benefits – Resilient systems
Failures in a component don’t necessarily affect the rest of the application Coupled with graceful degradation patterns, can help systems become more resilient and better handle failure X Service Service Service Service Service Service
8
Fast delivery, frequent iterations
Benefits – Agility Allow critical parts of the system to be developed and iterated more quickly than others, independently Less to build, deploy, and test per each release since changes do not touch the entire system Service Service Service Service Service Service Fast delivery, frequent iterations Slower delivery
9
Benefits – Flexibility
As loosely coupled components, microservices can be implemented using different technologies and platforms, if needed, depending on requirements Service Service Service Service Service Service
10
Haven’t we seen this all before?
Microservices are, in reality, a practical subset of SOA All of the tenets of SOA also apply to microservices Boundaries are explicit Services are autonomous Services share schema and contract, not class Service compatibility is based on policy SOA Microservices Implementation Differences Favors centralized orchestration Needlessly complicated by SOAP Death by specification Favors distributed choreography REST + HTTP/S = simple Leverage what is already there
11
Common misconceptions about microservices
“Microservices removes the need for an Enterprise Service Bus” Don’t confuse the product with the pattern “Microservices solves the problems of SOA” Don’t confuse improper SOA deployments as problems with SOA “Companies like Netflix and LinkedIn use microservices, so we should too” Netflix and LinkedIn are in the platform business. Is that your business too? “We must choose microservices, or SOA” Use both?
12
Challenges and risks
13
Microservices are not a silver bullet
Architectural Challenges Organizational Challenges Delivery Challenges Most organizations are organized around horizontal technology layers – need to build small product-focused teams Much higher skills required Many developers will not want to do production support Microservices don't eliminate complexity – they simply moved it and often add to it Monolithic applications allow architects to deal with complexity in one body of code Microservices force the move to distributed computing Testing, logging, monitoring, security, versioning – all become much harder Polyglot persistence is hard to maintain A lot of duplicated effort since each team is independent and goal is to minimize dependencies
14
Services are simple, surrounding architecture is not
Inner Architecture Data Access Security Business logic Load Balancing Service Discovery DevOps Shared State OS Containers Messaging API Gateway Telemetry Monitoring Outer Architecture Building services is rather straightforward using one of the multiple frameworks currently available However, there is a relatively large amount of concerns and capabilities, some of them unique to microservices, that should be addressed before we decide to build microservices
15
There’s more to it than just selecting a runtime platform
Service Discovery Service A Telemetry Registration Instance 1 Logging Heartbeat Where is service X? Instance 2 Monitoring/ Alerting API Gateway Load Balancer HTTP/REST Instance 3 Platform Services HTTP/REST Configuration Service B Messaging Instance 1 Authenticate, authorize Events Instance 2 Identity And Access Management Instance 3 NoSQL RDBMS Identity Store
16
Decentralized data Independent data stores per service lead to fragmented views of data, e.g. shared/overlapping views of a “customer” or “sales order” entity Synchronizing data stores is typically outside of the scope of the microservice, but still needs to be addressed Out-of-band data synchronization makes it very hard to maintain strong consistency Service Service Service Service Service Service Data synchronization
17
Distributed computing is hard(er)
Microservices force a move towards distributed computing, and there are some basic things about distributed computing that we must always keep in mind Fallacies of distributed computing The network is reliable. Latency is zero. Bandwidth is infinite. The network is secure. Topology doesn't change. There is one administrator. Transport cost is zero. The network is homogeneous. CAP Theorem – Pick Any Two C Pick Any Two A P Consistency Each node shows the same data at all times Availability Each node is available for requests at all times Partition Tolerance Able to handle network outages
18
DevOps Organizations without highly mature DevOps processes should not even consider microservices architectures Building, deploying, and operating tens of applications across potentially hundreds of distributed components is only achievable through thorough automation Service DevOps HTTP Continuous Integration Continuous Delivery Versioning Deploment & Rollback Test automation Infrastructure as Code
19
Head of Infrastructure
“Any piece of software reflects the organizational structure that produced it” (Conway’s Law) Monoliths Microservices Produced by groups organized across technology layers Simple change requires extensive coordination across all of the different layers Business logic is spread everywhere because it’s easier to bury it in the layer you own No real ownership Produced by distributed, product-oriented organizations Small teams can make any change they want to an individual microservice Architecture clean because developers have 100% control True ownership Typical Enterprise Organization Structure Head of IT Head of Operations Head of DBAs Head of Infrastructure Head of App Dev Head of UI Head of Development Results Infrastructure RDBMS Application UI Microservices Organization Structure Results Product Lead API Application API Developer Sys Admin DBA JavaScript Developer Data store Application Infrastructure Developer Sys Admin NoSQL Admin Graphic Artist Data store API Developer Storage Admin Infrastructure Application Data store Infrastructure
20
Getting started with microservices
21
Microservices add complexity
The first rule of microservices: maybe you don’t actually need microservices Microservices add complexity For less complex applications, monoliths are always better in both the long and short-run For moderately complex applications, monoliths are still probably better in both the long and short-run For complex apps, microservices may pay off over time but it takes a long time to offset the high up-front investment required to do it Time Complexity Monolith Microservice Complexity Over Time
22
How to start? Monolith First Microservices first
Monoliths are easier to reason about, and simpler to build With an evolutionary approach, the application is first designed as a monolith and services are broken out as complexity increases This is the only viable approach when adapting an existing monolith Microservices first Starting with a microservice architecture may be risky, specially if there’s no prior experience In exchange for a higher initial effort investment the architecture is much more modular right from the onset
23
Microservice runtime platforms
Microservices make no demands about their runtime platform, although there definitely is a group of “microservice-friendly” platforms and frameworks, designed to support microservices with the absolute minimum footprint necessary Restify gokit Java JavaScript Go Scala
24
Microservices and containers
Microservices don’t need containers to run, but both concepts share the similar principles around building applications out of smaller components Container Cluster Manager Microservices OpenShift v3 Cloud Foundry Heroku Elastic BeanStalk Docker Swarm Kubernetes Mesos Amazon ECS Azure Container Service
25
What are we doing with microservices at Accenture?
26
Microservices Architecture at Marriott
Channels Each microservice is a Play Application, wrapped in a docker container. Akka actor modules are used within Play. The number of “pods” will be configured in the PaaS solution. Each deployment unit will be scaled by the PaaS solution. Akana Softlayer Cloud API Services Load Balancer (NginX) Shop Service /foo Shop Service /bar Book Service /foo Book Service /bar Shop Service /XYZ Shop Service /ABC Book Service /XYZ Book Service /ABC Zoom-in Logging cluster *Vormetric transparent encryption – Couchbase Encryption for PII requirement Possibly Docker couchbase image Websphere load balancing managed by Xerox Log consumers Couchbase Custer Firewall Service /XYZ Data Power Unidirectional XDCR Inventory Actors Availability Actors Pricing Actors Legacy datacenter Mainframe Reservations System jms Reservation Compute Node Couchbase Cluster Pricing Compute Node http/rest Other dependencies queue HPP Play Feature Container
27
Data microservices at Bawag
Lightweight, high performance data microservices use to provide the client’s online channels with near real-time data without causing any additional strain to the core banking mainframe systems Data services implemented on Dropwizard, scheduled on the shared resources of the cluster using Apache YARN Online Channel YARN Service Service Service Real-Time Service Service Service Mobile eBanking Core Banking Data Replication Mainframe Stream Processing Log File Replication Apache HBase Real-Time Real-Time
28
Getting started
29
Microservices with Spring (spring.io)
Hands-on Microservices with Spring (spring.io) Seneca.js, a microservices toolking for Node.js (examples) Restify, lightweight Node.js REST framework Amazon Lambda Getting Started Go-Kit, microservices in Go
30
Martin Fowler: Microservices
Further Reading Martin Fowler: Microservices Microservices: Four Essential Checklists when Getting Started 8 Questions You Need to Ask About Microservices, Containers & Docker in 2015 Microservices: A practical approach for business agility and rapid introduction of new digital services Microservices: Not a Free Lunch! Building Microservices (book) Lightweight Architecture Blueprint (Accenture)
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.