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)