The promises and perils of microservices

The promises and perils of microservices A map for the adventurous developer

Uwe Friedrichsen – codecentric AG – 2015-2017

@ufried Uwe Friedrichsen | [email protected] | http://slideshare.net/ufried | http://ufried.tumblr.com

Must! … Do! … Microservices!

No, you don’t!

Microservices are an architectural choice

When do you need microservices?

If you need to go fast

Go fast? What do you mean with “fast”?

A bit of background …

Evolution of economy & markets

Formal part of value creation Solution: machine

Dynamic part of value creation

Solution: man

sluggishness/low dynamic high dynamic high dynamic

The historical course of market dynamics and the recent rise of highly dynamic and complex markets

The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.

t 1970/80 today

Age of crafts manu- facturing

Age of tayloristic industry

Age of global markets

1850/1900

Spacious markets, little competition

Local markets, high customi-zation

Outperformers exercise market pressure over conventional companies

We call the graph shown here the “Taylor Bathtub”. The “bathtub” curve

Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13



Solution: man




t 1970/80 today




1850/1900




We call the graph shown here the “Taylor Bathtub”. Pre-industrial era


Tailor-made solutions

“Mastery is key to success”



Solution: man




t 1970/80 today




1850/1900




We call the graph shown here the “Taylor Bathtub”. Industrial era


Cost-efficiently scale production

“Get more done with less people is key to success”



Solution: man




t 1970/80 today




1850/1900




We call the graph shown here the “Taylor Bathtub”. Post-industrial era


Continuously respond to changing demands

“Continuous customer communication

is key to success”

Key drivers Industrial era

•  Cost-efficiency •  Scalability •  Repeatability •  Stability

•  Efficiency & scale

Post-industrial era

•  Cycle times •  Adaptability •  Flexibility •  Resilience

•  Effectiveness & speed

Evolution of IT

1960 1970 1980 1990 2000 2010 2020

Complicated

(Business functions)

Complex

(Business processes)

Highly complex

(Business nervous system)

Software crisis

Software engineering

PC

LAN

Internet Business Support

of IT

Selective

Holistic

Complicated

Complex “Moore’s law”

Mobile IoT

1960 1970 1980 1990 2000 2010 2020

Complicated


Complex

(business processes)

Highly complex


Software crisis


PC

LAN


of IT

Selective

Holistic

Complicated


Mobile IoT

We are here …

1960 1970 1980 1990 2000 2010 2020

Complicated


Complex


Highly complex


Software crisis


PC

LAN


of IT

Selective

Holistic

Complicated


Mobile IoT

… but we still base most of our decisions on that

We are here …



Solution: man




t 1970/80 today




1850/1900




We call the graph shown here the “Taylor Bathtub”. Remember the bathtub curve?

This adds an additional twist …

1960 1970 1980 1990 2000 2010 2020

Complicated


Complex


Highly complex


Software crisis


PC

LAN


of IT

Selective

Holistic

Complicated


Mobile IoT

… but we still base most of our decisions on that

We are here …

Business is very different today …

… than it was back then

Role of IT today

Business

Market

IT today is a …

… Nervous System

… Medium … Product

… Differentiator

Disruptive Technologies

Business Support Systems

Continuous Conversation Digitization

IT today is a key success factor to survive in a post-industrial market

The traditional IT “best practices” are counterproductive because they solve

a completely different problem

We need to rethink IT!

Rethinking IT

What are the new drivers?

IT

Post-Industrialism Highly dynamic markets

Economic Darwinism Lean startup/lean enterprise

Continuous design

Digitization IT as a product

Digital conversation Social media

Contextual computing

Disruption Innovation through disruption Cloud, mobile, IoT, serverless

Big data analytics Data-driven enterprise

force change

on

What are the new goals?

IT

… be quick Short response times

Holistic IT value chain consideration

… be effective Focus on outcome, not output

… improve continuously Improvement as planned activity

needs to …

… be efficient Provide required throughput

… be robust High availability and adaptability

… be flexible Flexible response to changing needs

What are the building blocks?

Adaption DevOps Systemic optimization Inspect and adapt Quick feedback loops Continuous improvement …

Process DevOps Agile Lean Feature Flow (no projects) Design Thinking …

Governance Beyond Budgeting Decentralized control Outcome-driven Lean EAM …

Organization DevOps Autonomous teams Cross-functional teams End-2-end responsibility Routine task automation …

People Craftsmanship T-shaped Responsibility Curiosity Empathy …

Technology Cloud Automation Microservice Heterogeneity Resilience …

(Some) Building Blocks

µService

•  “Microservices are the mapping of organizational autonomy to software architecture”

•  Limited in scope •  Self-dependent •  Loosely coupled

•  Improves •  Autonomy •  Response time (if done right) •  Elasticity

•  Trade-offs •  Higher design effort •  Harder to operate •  Distributed by default

•  Shared nothing •  No shared data •  No cross-service coordination

Still, do I really need microservices?

Take the quick test

Take the real magic triangle …

You may pick two

Good

Fast Cheap

Optimizing for quality and cycle times will result in higher costs

Optimizing for quality and costs will result in long cycle times

Optimizing for cycle times and costs will result in reduced quality

... and pick the two properties that are most important for you

You may pick two

Good

Fast Cheap

Industrial IT

Deliver large batches at minimized costs towards slow markets

Post-industrial IT

Quickly adapt to ever-changing needs of dynamic, fast-moving markets

Startup IT

Test hypotheses and pivot as fast as possible to discover a product-market fit

This is the domain

of microservices

Adaption DevOps Systemic optimization Inspect and adapt Quick feedback loops Continuous improvement …

Process DevOps Agile Lean Feature Flow (no projects) Design Thinking …

Governance Beyond Budgeting Decentralized control Outcome-driven Lean EAM …

Organization DevOps Autonomous teams Cross-functional teams End-2-end responsibility Routine task automation …

People Craftsmanship T-shaped Responsibility Curiosity Empathy …

Technology Cloud Automation Microservice Heterogeneity Resilience …

(Some) Building Blocks Can’t I just go for microservices

without all that other stuff?

Of course you can, but you shouldn’t …

… because you would pay the full price for µservices and hardly gain anything

What is the price for µservices?

Well, ever heard about µservice hell?

A single µservice is easy … … but the complexity of the business functionality remains the same

☛ Complexity is shifted from single µservices to µservice collaboration

µServices are usually self-contained … … i.e., µservices are independent runtime processes

☛ This results in a highly interconnected, distributed system landscape

Consequences •  Design is (a lot!) more challenging •  Implementation is more challenging •  Distributed systems are challenging

•  Lookup •  Liveness •  Partitioning •  Latency •  Consistency •  …

•  New challenges for “monolith developers” à µServices are not easy at all

Only go for microservices if you holistically aim for shorter cycle times

Characteristics 1.  Componentization via services 2.  Organized around business capabilities 3.  Products not projects 4.  Smart endpoints and dumb pipes 5.  Decentralized governance 6.  Decentralized data management 7.  Infrastructure automation 8.  Design for failure 9.  Evolutionary design

J. Lewis, M. Fowler, https://www.martinfowler.com/articles/microservices.html

Componentization via services •  Out-of-process separation of functionality (in contrast to libraries)

•  Independently deployable, replaceable and upgradeable

•  Explicit published service interface

•  Usually coarse-grained service interface due to remote call costs

Organized around business capabilities •  Not organized around technology layers, but business capabilities

•  Broad-stack implementation for a business area

•  Leads to cross-functional teams (Conway’s law)

•  Also possible for monolithic applications, but not the common case

Products not projects •  Avoid the project team/maintenance team responsibility separation

•  Team should own a product over its full lifecycle

•  “You build it, you run it” – full responsibility for the software

•  Ties in with organization around business capabilities

Smart endpoints and dumb pipes •  Avoid centralized business logic in smart communication mechanisms

•  Maximize decoupling by keeping all business logic in services

•  Minimize smartness of communication mechanisms

•  HTTP (& REST) and lightweight messaging are most commonly used

Decentralized governance •  Empower autonomous teams (and give them the responsibility)

•  Enable heterogeneous language and technology choices

•  Use an OSS-inspired approach for shared assets

•  Use consumer-driven contracts

Decentralized data management •  Allow different conceptual data models between services

•  Allow different storage choices per service (“polyglot persistence”)

•  Strive for transactionless coordination between services

•  Embrace eventual consistency

Infrastructure automation •  “Make deployment boring”

•  Automate tests

•  Automate deployments

•  Automate management of services in production

Design for failure •  Design services that they can tolerate the failure of other services

•  Constantly reflect on how service failures affect the user experience

•  Be able to detect failures quickly

•  If possible, restore service automatically

Evolutionary design •  Evolutionary evolve the service landscape

•  Can be used as transition path from a monolith

•  Emphasis on replaceability and upgradeability

•  Make sure service changes don’t break its consumers

How can we avoid µservice hell?

No silver bullet

Topic areas

Design Interfaces

User Interface Frameworks

Datastores Developer Runtime Environment

Deployment Production Resilience

"It seems as if teams are jumping on µservices because they're sexy, but the design thinking and decomposition strategy required to create a good µservices architecture are the same as those needed to create a well structured monolith.

If teams find it hard to create a well structured monolith, I don't rate their chances of creating a well structured µservices architecture.”

- Simon Brown

http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html

"In theory, programming languages give us all we need to encapsulate state and environment - we just need to use them well.

Maybe we just don’t have the discipline? Maybe we had to explicitly advocate the practice of writing services running in completely different environments using different languages to trigger the sort of encapsulation that we want? If that’s the case, we can either see it as a clever self-hack or something we were forced into by the fact that we programmers are adept at overcoming any sort of self-discipline we try to impose on ourselves.

Perhaps both are true.”

- Michael Feathers

https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton

Design •  Master modularization first •  Strive for low coupling and high cohesion •  Forget about functional decomposition and layered architecture •  Rethink DRY and resusability – avoid deployment dependencies

Foundations of design •  High cohesion, low coupling

•  Separation of concerns

•  Crucial across process boundaries

•  Still poorly understood issue

•  Start with •  Understanding organizational boundaries

•  Understanding use cases and flows

•  Identifying functional domains (à DDD)

•  Finding areas that change independently

•  Do not start with a data model!

Dismiss reusability

•  Reusability increases coupling

•  Reusability leads to bad service design

•  Reusability compromises availability

•  Reusability rarely pays

•  Do not strive for reuse

•  Strive for replaceability instead

”If every service needs to be updated at the same time it’s not loosely coupled”

- Adrian Cockcroft

http://de.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices

Interfaces •  Plan for interface evolution •  Remember Postel’s law •  Consider BFF services (and API gateways) •  Synchronous vs. asynchronous

µS

Request/Response : Horizontal slicing

Flow / Process

µS µS

µS µS µS

µS

Event-driven : Vertical slicing

µS µS

µS

µS µS

Flow / Process

Order Fulfillment Service

Online Shop

Payment Service

Credit Card Provider

Shipment Service

Warehouse System

<Foreign Service> <Own Service>

Coupon Management

Promotion Campaign

Management Loyalty

Account Service

Payment Provider

PayPal

Loyalty Management

Accounts Receivables

Music Library

E-Book Library

Video Library

E-Mail Server

Coupon

Credit Card

Coordinate

Warehouse

Coordinate

Assets

Notify Cust.

PayPal

Coordinate

Order confirmed

Online Shop

Credit Card Provider

Warehouse System

<Foreign Service>

<Own Service>

Coupon Management

Campaign Management

Account service

Credit Card Service

Loyalty Management

Accounts Receivables

Music Library

E-Book Library

Video Library E-Mail Server

PayPal

PayPal Service

Warehouse Service

Promotion Service

Bonus Card Service

Coupon Service

Music Library Service

Video Library Service

E-Book Library Service

Notification Service

Payment authorized Digital asset provisioned

Payment failed

<Event>

Order fulfillment supervisor

Track flow of events Reschedule events in case of failure

Services are responsible to eventually succeed or fail for good, usually incorporating a supervision/escalation hierarchy for that

User Interface •  Be prepared for multiple UIs for multiple devices, target groups, etc. •  Separate UI and service by change cohesion, not by dogma •  Decouple via client centric BFF service •  Take optimizations for slow and no connectivity into account

Frameworks •  Not the most important issue of µservices •  Should support at least uniform interfaces, observability, resilience •  Nice if also support for uniform configuration and discoverability •  Options are legion – choose the one that fits your needs best

Datastores •  Avoid the “single, big database” – embrace “polyglot persistence” •  Avoid distributed transactions – usually a sign for a poor design •  Try to relax temporal constraints (and make actions idempotent) •  Treat your storage as being “ephemeral”

Development Runtime Environment •  Developers should be able to run (parts of ) the application locally •  Provide automatically deployable “development runtime environment” •  Containers and schedulers are your friends •  Make sure things build and deploy fast locally

Deployment •  Continuous deployment pipeline is a must •  Unify deployment artifact format •  Use either IaC tool deployment … •  … or distributed infrastructure & scheduler

Production readiness

•  You need to solve at least the following issues •  Configuration, Orchestration/Choreography, Discovery, Routing, Observability, Resilience

•  Bad news: No standard solution (yet) in sight •  Good news: Available solutions evolve quickly

Configuration •  Netflix Archaius

Orchestration/Choreography •  Mesosphere •  Nomad •  Kubernetes •  Swarm

Discovery •  Netflix Eureka •  Apache ZooKeeper •  Kubernetes •  Etcd •  Consul

Routing •  Netflix Zuul & Ribbon •  Twitter Finagle

Monitoring •  Hystrix •  Twitter Zipkin (Distributed Tracing)

Measuring •  Dropwizard Metrics

Logging •  ELK •  Graylog2 •  Splunk

Slide is mostly obsolete due to

missing updates for some months

A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.

Leslie Lamport

Failures in complex, distributed, interconnected systems are not an exceptional case •  They are the normal case

•  They are not predictable

•  They are not avoidable

Microservice-based systems are complex, distributed, interconnected systems

Failures in microservice-based systems are not an exceptional case •  They are the normal case

•  They are not predictable

•  They are not avoidable

Do not try to avoid failures. Embrace them.

resilience (IT) the ability of a system to handle unexpected situations

-  without the user noticing it (best case) -  with a graceful degradation of service (worst case)

Resilience •  Resilient software design is mandatory •  Start with (functional & technical) isolation and latency control •  Add automated error recovery and mitigation •  Separate control and data flow

Event/data flow Event/data flow

Resource access

Error flow Control flow

µS

Isolation

Separation of control/error and data/event flow

W

Flow / Process

W W W W W W W

S S S

S

S

Escalation

Core

Detect Treat

Prevent

Recover

Mitigate Complement

Supporting patterns

Redundancy

Stateless

Idempotency

Escalation

Zero downtime deployment

Location transparency

Relaxed temporal

constraints

Fallback

Shed load Share load

Marked data Queue for resources

Bounded queue

Finish work in progress

Fresh work before stale

Deferrable work Communication paradigm

Isolation

Bulkhead System level

Monitor

Watchdog

Heartbeat

Acknowledgement

Either level

Voting

Synthetic transaction

Leaky bucket Routine

checks

Health check

Fail fast

Let sleeping dogs lie

Small releases

Hotdeployments

Routine maintenance

Backuprequest

Anti-fragility

Diversity Jitter

Error injection

Spread the news

Anti-entropy

Backpressure

Retry

Limit retries

Rollback Roll-forward

Checkpoint Safe point

Failover

Read repair

Error handler

Reset Restart

Reconnect

Fail silently

Default value

Node level

Timeout

Circuit breaker

Complete parameter checking

Checksum

Statically

Dynamically

Confinement

Wrap-up

•  Microservices are no free lunch

•  Use if business responsiveness is crucial •  Complement with additional measures

•  Know the “what” of microservices

•  Reduce stress by especially taking care of •  Good functional design

•  Production readiness (incl. resilience)

•  New challenges for developers (& ops)

So, hope your hell will be more like this …

@ufried Uwe Friedrichsen | [email protected] | http://slideshare.net/ufried | http://ufried.tumblr.com

The promises and perils of microservices

Software

Transcript of The promises and perils of microservices