Microservices and consequences

Damien Plard

The context● Continuity● Change● Developer● SysEng● Architecture

○ Microservice● Team● Organization

● Conway● Position / Role● Mastery● Agile● Scrum● Decentralization● Hierarchy● ...

The context● Continuity● Change● Developer● SysEng● Architecture

○ Microservice● Team● Organization

● Conway● Position / Role● Mastery● Agile● Scrum● Decentralization● Hierarchy● ...

All those topics interfere with each other!

The context

We have to explain how they are linked.

But why having something new?

We are already changing:● of architecture● of product

For a new environment,we need to re-think our response.

Back in time

“ To understand the futureWe have to go back in time

cf. https://www.youtube.com/watch?v=2tdanFiy0H8, PitBull

Before…

…there were monoliths.

But what was problematic then?

For monolith see: https://en.wikipedia.org/wiki/Monolithic_application

Before… Issues out of reach● Stages

○ Not like live○ Not like prelive○ Dev

● Properties● Complexity● Ancient pieces● Mysql slave’s chain● Grails

● Inheritance○ SVN○ Tool chain

● Deployment○ Rollback forbidden○ Downtime○ Very hard sometime○ Too long

Before… No change possible● Stages

○ Not like live○ Not like prelive○ Dev

● Properties● Complexity● Ancient pieces● Mysql slave’s chain● Grails

● Inheritance○ SVN○ Tool chain

● Deployment○ Rollback forbidden○ Downtime○ Very hard sometime○ Too long

Those are just symptoms.

What we missed is the ability to change.

A new hope target

Let’s build something little and easy to change.

That’s where “Microservices” are interesting.

Microservices

“ These services are small, highly decoupled and focus on doing a small task

cf. https://en.wikipedia.org/wiki/Microservices

Conway’s law

But there’s Melvin Conway’s law:

“ organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

cf. https://en.wikipedia.org/wiki/Conway's_law

Conway’s law… reversed

cf. “entwickler special” volume 4, page 25

If we want to build microservices,we need to change our organization structureaccording to the architecture of our product.

Conway’s law… reversed

If we want to changefrom monolith to microservices,

Then we need to changefrom departments to teams.

cf. “Organisation für komplexität” Niels Pfäging, page 47

From monolith to microservices

From departments → to teamsOrder Team

Middleware Team

Database Team

Frontend Team

Supply Team

Inventory Team

→

From monolith to microservices

dev + ops + business → devops

Order Team

Middleware Team

Database Team

Frontend Team

Supply Team

Inventory Team

→

Devops

Or with a picture:

cf. “Continuous Delivery and DevOps - A Quickstart Guide” Paul Swartout, page 46

Devops

“ DevOps is a software development method that emphasizes communication, collaboration [...], integration, automation, and measurement of cooperation between software developers and other IT professionals.

cf. https://en.wikipedia.org/wiki/DevOps

Devops

To rephrase it:People should work as a team which is cross-functional, relying on trust and focused on a product.

But wait… This is...

Agile

Values:

“ ● Individuals and interactions over Processes and tools● Working software over Comprehensive documentation● Customer collaboration over Contract negotiation● Responding to change over Following a plan

cf. http://agilemanifesto.org/

Agile

Principles:

“ 1. Customer satisfaction by early and continuous delivery of useful software...

4. Close, daily cooperation between business people and developers...

10. Simplicity—the art of maximizing the amount of work not done—is essential

cf. http://www.agilemanifesto.org/principles.html

Devops + Agile => CD

If:● We have cross-functional teams (Devops)● We release as often as possible (Agile)

Then we can have continuous deployment.

The team

The team is the new unit of the organization.

The team is cross-functional and focused on creating value.

There’s no hierarchy nor command-control. cf. “Organisation für komplexität” Niels Pfäging, page 55

Objection!

The team can not be let working by its own.

It needs to create value needed by our customer.

cf. Phoenix Wright

The periphery

Between the team and the customer, there’s the periphery.

“ The periphery is the only part [...] with market contact.

cf. “Organisation für komplexität” Niels Pfäging, page 56-59

The periphery

So we need to define a role:

Guess what… well, guess who...

● Responsible for product vision● Final arbiter of requirements questions● Accepts or rejects each product increment● Considers stakeholder interests

The product owner

“ ● Responsible for product vision● Final arbiter of requirements questions● Accepts or rejects each product increment● Considers stakeholder interests● [...]

cf. http://scrumreferencecard.com/scrum-reference-card/#Scrum-Roles

The product owner

“ ● Business value driver● Daily decision maker● Vision Keeper● Heat shield● [...]

cf. “Coaching Agile Teams” Lyssa Adkins, page 171

Time for a conclusion, doesn’t it?

Back on our target

We want to be prepared to change.

Adopting microservices is the best solution.

To produce microservice we need to adopt Agile methods and devops teams.

Back on our target

Whatever we create, it will be based on the moment, the knowledges and the assumptions we have.

We will fail.

Back on our target

We can’t fear the failure.We have to be prepared for it.

We have to be prepared to evolve on our methods and our decisions.

The one and only purpose

“

Let’s prepare it!

The only thing that is constant, is change.cf. Heraclitus, 535 BC - 475 BC

www.neofonie.de/microservices

github.com/neofonie