An afterwork on Microservices by @OCTO Technology Switzerland

I want my microservices!
AVENUE DU THEATRE 7 > 1005 LAUSANNE > SUISSE > WWW.OCTO.COM
28 juin 2018 - Geneva
@OCTOSuisse
#afterwork
#microservices

OCTO © 2018 - Reproduction interdite sans autorisation écrite préalable
2
Bertrand
LE FOULGOC
Senior Consultant
@OCTOSuisse
+41 79 138 01 22
blefoulgoc@octo.com
Alexandre
MASSELOT
Consultant
@OCTOSuisse
+41 75 418 79 34
amasselot@octo.com
OCTO © 2018 - Reproduction interdite sans autorisation écrite préalable 2

OCTO Technology: Transformation Catalyst
HUMAN & TOOLS
EXCUBATIONINCUBATION
SHARING KNOWLEDGE

It’s DevOps Season In Switzerland
5

It’s DevOps Season In Switzerland
DevOps vision et pratiques
May 2nd 2018
Êtes-vous API dans votre organisation ?
March 7th 2018
Décollez vers le Cloud !
December 6th 2017
I want my microservices !
June 28th 2018
DevOps: c’est arrivé près de chez vous
Afternoon - October 9th 2018
6
http://bit.ly/devopsgva

Why an event on Microservices?
7

 27 virtual machines entangled
 50 man.hours to deploy
 Outdated technologies
 No methodology
 No tests
 No monitoring
 Endless night calls
Experience Feedbacks 1/3
Converging towards a distributed architecture
BEFORE
 Product Owner position, with a
product mindset
 Software craftsmanship
 Infrastructure as Code
 The Dev & Ops wall fell
 A more serene team
 Practice spread to other
teams
AFTER (~ same people)
 It is a long journey
 Falling back to bad habits is
always a risk
BUT
A web portal aggregating complex flows of data
12-18 months

 “Allo OCTO. Can you come and bring DevOps|Microservices with you”
(insurances, banks, food, industry etc.)
 Customers seeking for a magic wand
 A tough journey through technological and organizational shifts
9
Common in calls

Successes & Failures in the same environment: a real estate digital company, with solid technical skills
10

T H E R E I S A B E T T E R
W A Y
What are
Microservices?
11

Evolution of coupling within complex applications
1990s (and earlier)
Monolith
Tight coupling
2000s
Traditional SOA
Looser coupling
2010s
Microservices
Decoupled
next
?

The term "Microservice Architecture" has sprung up over
the last few years to describe a particular way of designing
software applications as suites of independently
deployable services. While there is no precise definition of
this architectural style, there are certain common
characteristics around organization around business
capability, automated deployment, intelligence in the
endpoints, and decentralized control of languages and
Martin Fowler, 2014
13

From monolith to microservices
1. Regain control of your monolith
2. Split it in loosely coupled modules
14
runtime

If you cannot build a well-
structured monolith, what
makes you think microservices
are the answer?
Simon Brown
15
From monolith to microservices

 Distributed
 Context bounded
 Autonomous
 Responsible and accountable
for a given purpose
 Loosely coupled
 Lightweight messages
 Asynchronous
 Failure proof
 Evolutive
16
Microservices architectural style: some characteristics

 Distributed
 Context bounded
 Autonomous
for a given purpose
 Loosely coupled
 Asynchronous
 Failure proof
 Evolutive
17
 Biology
 Ecology
 Economics
 Social sciences

 Distributed
 Context bounded
 Autonomous
for a given purpose
 Loosely coupled
 Asynchronous
 Failure proof
 Evolutive
This is
OCTO’s
vision of
Architecture

W A Y
Motivations
Behind Microservices
19

 Booking a ski holiday in Switzerland
<Flight
<Car rental
<Chalet with ski equipment
 Monolithic application
20
HappySkiHolidays.com

Meet Moss’s team
Moss: Dev
So much code!
6 months to ramp up
Isolating a bug is so hard
Still on java 5!?
UI/UX Designer
My potential is wasted here
Moss keeps saying :
”we cannot to that”
Oprah: Ops
Two instances 24/7…
Just for the winter rush!?
Tech Lead
We need to scale
A full rewrite is too costly
Product Owner
The competition is onto us…
Why is this taking so long?

W A Y
Challenges &
Solutions
22

Challenges
Moss: Dev
Oprah: Ops
We must pay tech debt first
Modularise the app
No shared state
Let’s define SLAs
React to traffic and failures
Interactions will get tricky
Compatibility, contracts…
Tech Lead

Technical challenges – Microservices fertile ground
12 Factors
Codebase
Dependencies
Config
Backing services
Build release run
Processes
https://12factor.net/fr/
Production Ready
Alerts
Apache & Tomcat
Automated canary analysis
Autoscaling
Chaos
Consistent naming
ELB config
Health check
Immutable machine images
Squeeze testing
Staged, red/black
deployments
Timeouts, retries, fall-backs
Design for failure
Service discovery
Disposability
Dev/prod parity
Port binding
Concurrency
Logs
Admin processes

Technical challenges – Some problems the team encountered
X Months

Technical challenges – Some problems the team encountered
 Distributed transactions
 Reactive Infrastructure
< Automated deployment
< Elasticity
< Discovery
< Design for failure
< Self-healing
 Tests
< Chaos engineering
< Consumer driven contracts

Distributed transaction (in a microservice architecture)
< A single event results in the mutation of two or more
separate sources of data which cannot be committed
atomically.
< Distributed transactions in microservices should be
avoided as much as possible.
< No more atomicity, eventual consistency instead
Technical challenges – Distributed transaction
http://www.grahamlea.com/2016/08/distributed-transactions-microservices-icebergs/

Choreography
< Sub-transactions, with associated revert sub-transaction
< Use idempotent transactions or handle failure manually
< Lock if you don’t want revert transactions (loss of availability,
gain in atomicity)
28
SCA
C AS
C S
C-1

Choreography
Natural, instinctive pattern
Simple, easy to understand
Minimal effort
No coupling to other components
Idempotence
design for failure
Scales with potentially exponential complexity
Cyclic dependencies are hard to diagnose
End to end testing is challenging
29

Orchestrator
< A log of transactions is maintained
< Reverse transactions are played sequentially in case of error
< Design for failure using idempotent transactions, including reverse ones
30
C AS C C-1S

 « Smart end-points, dumb pipes »
 Not as centralised governance
 It is just another service
 Ideally internal to the team
31
 Smart pipes often seen
 Centralised governance
 One service to rule them all…
 Maintained by one team, involves most teams
Looks like an ESB !?

Orchestrator
No cyclic dependencies
Centralised logic
Simplifies services
Easier to test
Linear complexity
Idempotence
design for failure
Single point of failure (redundancy helps)
Centralised logic
Stronger coupling
32

Technical challenges – The journey so far
What we’ve covered
< Requirements: create a fertile ground, understand
micro-service’s non-negotiable characteristics
< Transactions: control and master the ”availability VS
atomicity” trade-off
In the next section
< Reactive infrastructure: a system that reacts to
failure and changing traffic
< Tests: automating to mitigate the new risks involved
in the micro-services architecture style

 Define SLAs for each service
< RPO
< RTO
< Response time
< Maximum load
< Guaranteed uptime
< etc…
 Use current ones if you have no idea
< Prevents decay
< Informs potential users
Technical challenges – Measure
34

 System uptime is the product of services uptimes
< 99.99% uptime means 53 minutes downtime
< becomes 8 to 9 hours a year when combined
 Downtime will happen, make it a non-event
< Hystrix
< Resilient4j
< …
 Monitoring becomes more critical than ever
< Configure alerts
< Display important system metrics for all to see
Technical challenges – Monitoring
https://www.youtube.com/watch?v=SmRcSezrsZM
Josh Evans QCon San Fransisco 2016
35

 Leverage cloud technology
< Autoscaling groups
< Availability zones, regions.
< Cloudwatch alarms
 Built-in service discovery for on premises
< Kubernetes
< Marathon
< Mesos
 Use service registries directly
< Eureka (Spring stack)
< Apache Zookeeper
< Consul
< etcd
Technical challenges – Elasticity, self healing, resilience
36

 Define a stable state, using a control group
 Introduce variations in the experiment group
 Measure differences and act accordingly
https://principlesofchaos.org
Control group Experiment group
Technical challenges – Chaos engineering

 Maturing very rapidly
 Lots of libraries and tools to chose from
 Don’t start with tests in prod
Technical challenges – Chaos engineering
https://github.com/dastergon/awesome-chaos-engineering
Security testing in AWS
Chaos monkey equivalent for Docker

https://martinfowler.com/articles/microservice-testing/
Technical challenges – Know your classics
VS.
Manual
User Interface
Integration
Unit
Unit
Integration
End to end
Component
Exploratory

Technical challenges – Communication
What we’ve covered
< Reactive infrastructure: SLAs, monitoring, alerting,
self-healing, automated scaling,…
< Tests: infrastructure, service level
In the next section
< Tests: interaction between connected services,
consumer driven contracts

 The impact of an API change is greatly increased
< Deployments happen independently
< Service dependencies are multiplied
 Working with separated teams
< Release management
< Version management
 RESTful API design
< Harmonise
< Use clear guidelines
 Consumer driven contract
Technical challenges – Services interactions

Technical challenges – Know your classics
Postel’s LAW – Robustness principle
« Be conservative in what you send, be liberal in what you accept »

 The PACT is written and maintained
< By consumers
< Using pull requests
 Library available in many languages
< Java, JavaScript, .NET, Ruby, Go, Swift, Python
 Well documented, not trivial though
https://github.com/pact-foundation/
Technical challenges – Consumer driven contract

Step 1 – Define consumer expectations
Consumer Provider
PACT
HTTP Request
HTTP Response

Step 2 – Verify expectations on Provider
Consumer Provider
PACT
HTTP Request
HTTP Response

 Each PACT change triggers automated tests
 Spring proposes another great option
https://spring.io/guides/gs/contract-rest/
https://cloud.spring.io/spring-cloud-contract/
https://github.com/pact-foundation/

 Distributed
 Context bounded
 Autonomous
for a given purpose
 Loosely coupled
 Asynchronous
 Failure proof
 Evolutive

W A Y
Culture
&
Organisation

“Organisations which design systems
[...] are constrained to produce designs
which are copies of the
communication structures of these
organisations.”
Melvin Conway, 1967
49

Corollary #1:
the software interface structure of a
system will reflect the social
boundaries of the organization(s) that
produced it.
Corollary #1:
the software interface structure of a
system is bounded by the social
boundaries of the organization(s) that
produced it.

“No matter how it looks at first,
it's always a people problem”
Gerald Weinberg

They have tougher problems than ours, but we can get inspiration
Other disciplines than IT have organisational challenges
Auftragstaktik
 Leaders share the vision
 Orders must be clear and minimalistic
 Independence is given to ground teams
(XIXth century)

Systemic
Team level
organisation

1 service = 1 business responsibility
The team perimeter: 1 team = 1 business purpose
 People are dedicated to 1 team (modulo exceptions)
 Multi competencies (PO, Dev, Ops, UX etc.)
 5-12 persons
 Stable through time
 Consequence: your monolith organisation
must be reshaped

 A team can choose
< its technology
< Its methodology
< Its rituals
< Its inner organisation principles
 From upper management, autonomy needs trust
< Trust must be given upfront
< And trust induces risks
< But risk is a side effect of action.
55
A team is autonomous
A micro-service is not tied to other services inner intricacies

 Dev + Ops together
 Must honor SLAs
 Dev are also on pager duty
 Quality becomes not negotiable
56
A team is accountable
A micro service is resilient, automatically deployed
“You build it, you run it”
Werner Vogels, cto@amazon.com (1)
(1) Yes, colleague of the CEO who proposed to fire anyone
who did not expose their data through an API, or left
open backdoors in their services…

 Blind autonomy can be a risk:
< Reinventing the wheel
< Inefficient continuous improvement
< Operational and technological drift
 A balance must be found between variance and standardisation
 Warning: beware of the temptation to impose technical solutions top-down
57
Cross team drift

 Community of practice, to share skills
 Core component teams, on specific
domains (security…)
 Opportunistic channels (coffee machine, 20%
R&D, people switching hackathons)
58
Cross team knowledge sharing
Communities
of practice
Core component team

 Agile can scale:
< Scrum of Scrum
< Product owner synchronization
< Public demo
 Use different time scales (vision, roadmap, sprint
etc.) to share and adapt
 Communication between teams must be lean.
 Communication between teams nurtures healthy
conflicts and is regular.
59
Inter team roadmap communication
Microservices are autonomous, not isolated

Inter team operational communication
Microservices are autonomous, not isolated
“Everything must be made as
simple as possible, but no simpler.”
Albert Einstein

But what will happen to middle management?

“Culture eats Strategy for breakfast”
Peter Drucker
“You cannot change culture, but
you can change behaviors
(and behaviors become culture)”
Damon Edwards

Are you afraid?

Systemic
Team level
organisation

Systemic
Team level organisation

Software Craftsmanship
 Motivations: get better and share knowledge
 Developing software is as prestigious job
 Technical mastering shall be celebrated by the company
ww.jaegerguitars.com

 Bet on collaboration before IQ
 Rituals are not enough.
 Mutual trust, psychological safety with:
< Feedback
< Collaborative decision
 Acknowledge and welcome failure
69
Communication within the team

Conway’s Lay, corollary #2
(aka “the reverse Conway maneuver”)
Change your team and organisational structure to
promote your desired architecture. Ideally your
technology architecture will slowly morph to match your
business architecture
70

W A Y
And now,
Shall I go?
71

Success & Failure : a digital firm, with a solid set of technical skills and great culture
14 microservices, fan out – fan in messaging system
Continuous delivery
Partial infra as code
Bamboo – not versioned
Granularity way too thin
Operational nightmare
Great team
Complete autonomy
Documentation lacking
Designed by one person
Infamous project
72

14 microservices, fan out – fan in messaging system Huge product - 10,000+ classes
Continuous delivery
Great team
Complete autonomy
Infamous project
Great team
Complete autonomy
Customised rituals
Consensus approach
Developing PO
Wrong Tech choice
Continuous delivery
Infrastructure as code
Coverage, modularity
Tactical peeling
No naming conventions
Very complex
73

14 microservices, fan out – fan in messaging system
Continuous delivery
Great team
Complete autonomy
Infamous project
Huge product - 10,000+ classes
Great team
Complete autonomy
Customised rituals
Consensus approach
Developing PO
Wrong Tech choice
Continuous delivery
Infrastructure as code
Coverage, modularity
Tactical peeling
No naming conventions
Very complex
74

Conclusion
This was just a peek at a very demanding architectural style
Consulting
& Transformation
Training Program myUSI
Conferences
Why
< Beware of over-engineering
How
< Fertilise your technical, cultural and organisational ground
What
< Identify the ideal candidate

DID YOU LIKE THE CONFERENCE?
Please fill in the questionnaire and return it on your way to the cocktail !
OCTO TECHNOLOGY > THERE IS A BETTER WAY 76OCTO © 2018 - Reproduction interdite sans autorisation écrite préalable 76

DevOps
8 présentationsDes retours
d’expérience
C’EST ARRIVÉ
PRÈS DE CHEZ VOUS
Un après-midi pour apprendre et partager
Genève, le 9 octobre 2018, de 13h à 19h
Des solutions
pratiques
77
LES PLACES
SONT LIMITÉES
INSCRIVEZ-VOUS!
http://bit.ly/devopsgva

An afterwork on Microservices by @OCTO Technology Switzerland

Recommandé

Recommandé

Contenu connexe

Similaire à An afterwork on Microservices by @OCTO Technology Switzerland

Similaire à An afterwork on Microservices by @OCTO Technology Switzerland (20)

Plus de OCTO Technology Suisse

Plus de OCTO Technology Suisse (20)

Dernier

Dernier (20)

An afterwork on Microservices by @OCTO Technology Switzerland