Microservices Overview Copyright Accenture LLP All rights reserved

Microservices Overview Copyright © Accenture, LLP. All rights reserved.

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

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 Copyright © Accenture, LLP. All rights reserved.

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 Load Balancing Service HTTP Service Monitoring Dev. Ops Service Health Provisioning HA/Tolerance Service Discovery Copyright © Accenture, LLP. All rights reserved.

Benefits – Scalability Allow performance critical components to scale independently from the rest of the system Service Copyright © Accenture, LLP. All rights reserved. Service Service

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 Copyright © Accenture, LLP. All rights reserved. Service

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 Service Copyright © Accenture, LLP. All rights reserved. X Service

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 Fast delivery, frequent iterations Copyright © Accenture, LLP. All rights reserved. Slower delivery

Benefits – Flexibility As loosely coupled components, microservices can be implemented using different technologies and platforms, if needed, depending on requirements Service Copyright © Accenture, LLP. All rights reserved. Service

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 Implementation Differences § Favors centralized orchestration § Needlessly complicated by SOAP § Death by specification § Favors distributed choreography § REST + HTTP/S = simple § Leverage what is already there Copyright © Accenture, LLP. All rights reserved. SOA Microservices

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 Linked. In use microservices, so we should too” “We must choose microservices, or SOA” Copyright © Accenture, LLP. All rights reserved. Netflix and Linked. In are in the platform business. Is that your business too? Use both? 11

Challenges and risks Copyright © Accenture, LLP. All rights reserved.

Microservices are not a silver bullet Architectural 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 Copyright © Accenture, LLP. All rights reserved. Organizational Challenges • • • 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 Delivery Challenges • • • 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

Services are simple, surrounding architecture is not • Outer Architecture Telemetry API Gateway Messaging Inner Architecture • Monitoring Business logic Data Access OS Containers Dev. Ops Security Shared State Service Discovery Load Balancing Copyright © Accenture, LLP. All rights reserved. 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

There’s more to it than just selecting a runtime platform Service Discovery Service A Reg istra rtbe at HTT P Instance 1 Logging Instance 2 Monitoring/ Alerting /RES T Instance 3 Platform Services T ES /R TP HT API Gateway Hea Where is service X? Load Balancer Telemetry tion Service B Instance 1 Authenticate, authorize Identity And Access Management Configuration Messaging Instance 2 Events Instance 3 No. SQL RDBMS Identity Store Copyright © Accenture, LLP. All rights reserved.

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 Data synchronization Copyright © Accenture, LLP. All rights reserved. Service

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 A Pick Any Two 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 Copyright © Accenture, LLP. All rights reserved.

Dev. Ops Organizations without highly mature Dev. Ops 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 Continuous Integration Continuous Delivery Service Versioning Service Dev. Ops Service HTTP Deploment & Rollback Test automation Infrastructure as Code Copyright © Accenture, LLP. All rights reserved.

“Any piece of software reflects the organizational structure that produced it” (Conway’s Law) Monoliths Microservices § Produced by distributed, product-oriented § Produced by groups organized across organizations § Small teams can make any change they want to an individual microservice § Architecture clean because developers have 100% control § True ownership 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 Typical Enterprise Organization Structure Results Microservices Organization Structure API Product Lead UI Head of IT Head of Developme nt Application Head of App Dev Head of UI Developer Sys Admin DBA Java. Script Developer Data store Developer Sys Admin No. SQL Admin Graphic Artist Data store API Infrastructure Developer Storage Admin Application Data store Infrastructure Copyright © Accenture, LLP. All rights reserved. Application Infrastructure RDBMS Head of DBAs Application API Head of Operations Head of Infrastruct ure Results Infrastructure

Getting started with microservices Copyright © Accenture, LLP. All rights reserved.

The first rule of microservices: maybe you don’t actually need microservices Complexity Over Time Micr Complexity 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 oser v ice lith o Mon Time Copyright © Accenture, LLP. All rights reserved. 21

How to start? 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 Copyright © Accenture, LLP. All rights reserved. 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

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 Copyright © Accenture, LLP. All rights reserved. Scala Java. Script Go

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 Docker Swarm Kubernetes Mesos Amazon ECS Azure Container Service Copyright © Accenture, LLP. All rights reserved. • • Open. Shift v 3 Cloud Foundry Heroku Elastic Bean. Stalk

What are we doing with microservices at Accenture? Copyright © Accenture, LLP. All rights reserved.

Microservices Architecture at Marriott 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 Paa. S solution. Each deployment unit will be scaled by the Paa. S solution. Channels Akana API Services Load Balancer (Ngin. X) 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 Couchbase Custer Log consumers Softlayer Cloud Firewall Data Power Unidirectional XDCR Mainframe Reservations System jms queue Reservation Compute Node Couchbase Cluster Pricing Compute Node Inventory Actors http/rest HPP Legacy datacenter Copyright © Accenture, LLP. All rights reserved. Service /XYZ Availability Actors Pricing Actors Other dependencies Play Feature Container

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 Service Service Real-Time Mobile e. Banking YARN Mainframe Real-Time Copyright © Accenture, LLP. All rights reserved. Log File Replication Real-Time Stream Processing Data Replication Core Banking Apache HBase

Getting started Copyright © Accenture, LLP. All rights reserved.

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 Copyright © Accenture, LLP. All rights reserved.

Further Reading • • • Martin Fowler: Microservices • Microservices: A practical approach for business agility and rapid introduction of new digital services • • • Microservices: Not a Free Lunch! Microservices: Four Essential Checklists when Getting Started 8 Questions You Need to Ask About Microservices, Containers & Docker in 2015 Building Microservices (book) Lightweight Architecture Blueprint (Accenture) Copyright © Accenture, LLP. All rights reserved.