Microservices Overview

1. Microservices Overview

2. What are the most common pain points in contemporary architectures? No Specialization 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 Different parts of applications have different needs – more CPU, more memory, faster network, etc No Specialization Too Complex No Ownership • Too Slow No Ownership Too Slow Code falls victim to “tragedy of the commons” – when there’s little ownership, you see neglect • Teams split up by function – UI, application, middleware, database, etc. Too Fragile Inefficient Testing Inefficient Testing • Too Fragile Each change requires a complete testing cycle. Hard to support continuous delivery • A bug will quickly bring down an entire application. Little resiliency

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) Platform Gateways DevOps Load Balancing Service Monitoring Service Service Service Service Health Service HTTP HTTP Provisioning HA/Tolerance Service Discovery

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. 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 • Implementation Differences • Favors centralized orchestration • Needlessly complicated by SOAP • Death by specification Microservices • 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” “We must choose microservices, or SOA” Don’t confuse the product with the pattern Use both? Don’t confuse improper SOA deployments as problems with SOA “Microservices solves the problems of 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?

12. Challenges and risks

13. 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 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 Microservices are not a silver bullet Architectural Challenges Delivery Challenges Organizational Challenges

14. Services are simple, surrounding architecture is not • 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 Outer Architecture Telemetry API Gateway Messaging Monitoring Inner Architecture Business logic Data Access OS Containers DevOps Security Shared State Service Discovery Load Balancing

15. There’s more to it than just selecting a runtime platform Service A Service Discovery Telemetry Registration Instance 1 Logging Heartbeat Where is service X? Monitoring/ Alerting Instance 2 Load Balancer API Gateway HTTP/REST Instance 3 Platform Services HTTP/REST Configuration Service B Messaging Instance 1 Authenticate, authorize Events Instance 2 Identity And Access Management NoSQL Instance 3 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 microservicesarchitectures Building, deploying, and operating tens of applications across potentially hundreds of distributed components is only achievable through thorough automation Continuous Integration Service DevOps Continuous Delivery Service Service Service Service Service Versioning Deploment & Rollback HTTP HTTP Test automation Infrastructure as Code

19. “Any piece of software reflects the organizational structure that produced it” (Conway’s Law) Monoliths Microservices • 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 • 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 Microservices Organization Structure Results Results Typical Enterprise Organization Structure API Product Lead Application API UI Head of IT Data store Developer Sys Admin DBA JavaScript Developer Application Application Infrastructure Head of Operations Head of Development Developer Sys Admin NoSQL Admin Graphic Artist Data store API RDBMS Infrastructure Developer Storage Admin Application Head of DBAs Head of Infrastructure Head of App Dev Head of UI Infrastructure Data store Infrastructure

20. Getting started with microservices

21. 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 Complexity Over Time Microservice Complexity Monolith Time

22. How to start? • 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 • Monolith 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

23. Microserviceruntimeplatforms 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 Scala JavaScript Go

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 Microservices Container Cluster Manager • 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 PlayApplication, wrapped in a dockercontainer. 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) Book Service /foo Book Service /bar Shop Service /foo Shop Service /bar Book Service /ABC Shop Service /ABC Book Service /XYZ Shop Service /XYZ Zoom-in Logging cluster Log consumers Couchbase Custer Service /XYZ Firewall Data Power Unidirectional XDCR Inventory Actors Availability Actors Pricing Actors Legacy datacenter jms Reservation Compute Node Pricing Compute Node Other dependencies http/rest Mainframe Reservations System Couchbase Cluster HPP queue 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 Data Replication Core Banking Stream Processing Mainframe Apache HBase Log File Replication Real-Time Real-Time

28. Getting started

29. 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. 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)