Why you should take a deep breath and think about it before you decide you should use a Microservices architecture

1

MICROSERVICES ARE NOT WORTH THE TROUBLE..??

JAMES BIRNIE

● James Birnie, lead consultant @ ThoughtWorks since June 2015

● http://www.jamesbirnie.com/● jbirnie@thoughtworks.com● Worked at a startup for 9 years● Worked in software since 1996

A Global Community of TechnologistsAbout ThoughtWorks

Croatia v England, 19:00 BST

Service alterations, buses will replace trains No longer wish to travel,

entitled to a full refund

Clementine’s Cat

Indifference...

Schrodinger’s Cat

Indifferent

Aloof

StandoffishArrogant Disinterested

Detached DistantUnresponsive

MICROSERVICES ARE NOT WORTH THE TROUBLE!!??

● Key Benefits of Microservices

● Complexity and where it lives

● Important Outcomes

● Microservices Trade-offs

● Outcomes based Case Studies

● Top tips for Microservices success

What will a Microservices architecture give me that I won’t get from a monolithic application?

13

THE MICROSERVICES PROMISES

KEY MICROSERVICES BENEFITS...

● Reduction of handovers and communication taxes○ Make Conway’s Law work FOR you

● Independent scalability of components● Independent codebases and releases● Components should be reduced in complexity● Technology diversity● System downtime can be reduced● They can enable platform thinking

The minimum required complexity in any system is fixed. Architectural choices can therefore only optimise or move this complexity.

15

WHERE IS MY COMPLEXITY?

COMPLEXITY OF A MONOLITHIC SYSTEM...

● 5 “Things” in the system

● Means up to 4 + 3 + 2 + 1 = 10 possible connections

● You have added 5 more possible connections

● Add one more “thing” to the system

● N “things” will have N(N - 1) / 2 possible connections

● For example 16 “things” will have 120 possible connections

REDUCE COMPLEXITY WITH MICROSERVICES…??

● 16 “things” have 120 possible connections

● Group together related “things” into contexts

● Only allow connections between related “things” or between contexts

● In this example the maximum number of connections is now reduced to 31

3

6

6

10

6

HANG ON…. SOMETHING IS MISSING HERE…?

HANG ON…. SOMETHING IS MISSING HERE…?

● Would all the “things” really connect to all the other “things”?

○ Wouldn’t it make sense, with or without Microservices, to only connect to related things?

● There may be multiple connections between different contexts

● What other complexity may be introduced?

COMPLEXITY HAS MOVED...

● Your Microservices components should be small enough to understand and reason with

● BUT, complexity has moved…○ Orchestration between components is now necessary○ It will be much harder to reason with and debug your

program logic○ You will have more, and more complex, tests○ You will have more builds○ You will have more technologies in play○ You will have a much bigger monitoring

and maintenance overhead

Microservices is a solution but too often it is invoked early and becomes an end, and hence a problem statement, in and of itself.

21

WHAT OUTCOMES ARE IMPORTANT?

HANDOVERS ARE BAD, LET’S REDUCE HANDOVERS...

1 - Intra team, empathetic handover

2 - Aligned team, sympathetic handover

3 - Transactional handover, no alignment, no empathy, no sympathy

NO TEAM SHOULD BLOCK ANY OTHER TEAM’S RELEASE

● Split the monolithic code base by contexts○ A carefully designed monolith will help with this

● Consider not splitting data contexts○ There may still be tensions over shared assets○ Databases can be logically segregated

● There might be a co-ordination overhead● Applications can be deployed

to the same servers

INDEPENDENT SCALABILITY OF COMPONENTS

● One size doesn’t always fit all but how important is it REALLY?

○ Will the management cost outweigh the benefit?● Infrastructure management tools that

provide better abstractions could help● You can scale app servers independently

that access a common datastore

STRONG MODULE BOUNDARIES ARE DESIRABLE

● Microservices reinforce modular structure, particularly important for large teams

● Microservices are decoupled by definition● Microservices can get Conway’s Law working in

your favour● Monoliths can also have good modular

structure but it is harder to enforce

Nothing in the world comes for free. What are the key trade offs that we have to consider before we use a Microservices architecture?

26

SO WHAT ARE THE DOWNSIDES?

THE MICROSERVICES PREMIUM

● https://martinfowler.com/bliki/MicroservicePremium.html● Automated deployment● Monitoring● Dealing with failure● Eventual Consistency● Developer complexity● Complexity of service to service communication

○ Protocols and patterns○ Certificates, firewalls, all the THINGS!

IF THINGS AREN’T DONE WELL YOU MAY FIND...

● Releases need to be coordinated● Many different solutions to the same problems emerge

throughout your business● Funding must be product based or your infrastructure

could decay● Conway’s law can work for you or against

you - you may create different silos

Not every solution delivers what you want. Sometimes you can get into a bit of a mess with all the best intentions...

29

WHAT CAN GO WRONG SOMETIMES

SUBOPTIMAL MICROSERVICES PLATFORM IMPLEMENTATION

● Inconsistent product vision● Requirements constantly pivoting● Technology based microservices● Poor attention to maintainability● Immature devops practice● Waterfall funding● Inconsistent implementations● Strange technology choices

WHAT WE WERE DOING TO HELP TO IMPROVE THIS SITUATION

● Upskilling teams to instill a DevOps style “you build it, you run it” culture

● Fought hard to assign budgets to products● Redesigned microservices to more closely align with

business capabilities● Aligning teams around the services

Some solutions I’ve worked on or come across that helped deliver the Microservices promises without all of the associated overheads.

32

SOME OUTCOMES BASED SOLUTIONS

ALLOW TEAMS TO DEPLOY INDEPENDENTLY OF ONE ANOTHER...

● Enterprise solution in a startup that had evolved over a number of years

● As the company grew it became increasingly hard to coordinate releases across teams

● Monolithic solution with some services and Winforms applications consuming services

● Single relational database● Infrastructure in a managed

data centre

EVOLVED SOLUTION

MONOLITHIC RELATIONAL DATABASE

MONOLITHIC WEB APPLICATION

SOAP SERVICES

INTERNAL APPS

EVOLVED SOLUTION

MONOLITHIC RELATIONAL DATABASE

MONOLITHIC WEB APPLICATION

SOAP SERVICES

INTERNAL APPS

TECH TEAMS

WEB

TOOLS

INFRA

DB

BUSINESS TEAMS

SALES

PARTNERS

CS

CONTENT

MARKETING

HOW WE MOVED TO A BETTER PLACE...

● Code was refactored into assemblies● Shared assemblies, representing cross cutting

concerns, were made into packages● Codebase was split vertically to more accurately

mirror business divisions● Software teams became cross functional

aligned to a business vertical● Database remained monolithic● Infrastructure was largely unchanged

PLANNED SOLUTION TO ALLOW INDEPENDENT CODE RELEASES

MONOLITHIC RELATIONAL DATABASE

MONOLITHIC WEB APPLICATION

SOAP SERVICES

INTERNAL APPS

TECH TEAMS

WEB

TOOLS

INFRA

DB

BUSINESS TEAMS

SALES

PARTNERS

CS

CONTENT

MARKETING

MONOLITHIC RELATIONAL DATABASE DB

E-COMMERCE CSPARTNERSHIPSSUPPLY CONTENT

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES

THE OUTCOME...

● WE ACHIEVED…○ Separation of codebases allowing independent code releases○ A closer alignment between business units and the teams

delivering value to them

● WE DIDN’T ACHIEVE…○ Separate scalability of components○ Bounded data contexts

● WE AVOIDED…○ Managing eventual consistency○ Introducing extra developer complexity

TRYING TO BUST SILOS

● Publishing company refreshing its product offering● Attempting to leverage a platform created for the new

US market application● Many silos existed in the content creation space

centred on technology centric outcomes● It was taking an estimated 13+ months to deliver new

value to the product

WORKING THROUGH ENDLESS SILOS

40

I want to configure SOMETHING to subscribe to X and store data in THE

STORE

ENDLESS SILOS

RAW DOCUMENT

ABOUT 15 SILOED

PROCESSES

DOCUMENT DATABASE

CONTENT PRODUCTION

APPLICATIONS TEAMS

ENHANCED DOCUMENT

SHARED DISPLAY

SERVICES

US APP UK APP

A PRODUCT LED APPROACH

● We were initially asked to analyse the content enhancement process

● All silos knew exactly what their piece did but had little visibility of the overall picture

● We started asking product based questions● We simplified the content production process and owned

the whole outcome● Cycle time was reduced to days

OWNING THE WHOLE OUTCOME

RAW DOCUMENT

ABOUT 15 SILOED

PROCESSES

DOCUMENT DATABASE

ENHANCED DOCUMENT SHARED

DISPLAY SERVICES

US APP UK APP

RAW DOCUMENT

PRODUCT FOCUSSED

ENHANCEMENT

PRODUCT SPECIFIC

‘MICROSERVICE’

PRODUCT DISPLAY SERVICE

CYCLE TIME REDUCED TO DAYS

● WE ACHIEVED…○ Shorter cycle times by removing the need to traverse silos○ Separate scalability by deploying to separate virtual servers○ A greater understanding of customer focus

● HOWEVER...○ We imposed a greater requirement on our team

to manage deployments○ We reengineered rather than reused code○ We had to monitor and support

our components

THE OUTCOME...

Microservices are a great tool to deliver some great outcomes. But they come with a cost. Understand the outcomes you want and ask if you can sustain the cost.

45

SO WHEN SHOULD WE USE MICROSERVICES?

TIP #5: YOU CAN START WITH A MONOLITH

● Design it well, it will be easier to break up● You can deliver outcomes one by one

○ Split the code bases and use libraries○ Find a way to deploy pieces separately○ Split your teams when the bounded contexts emerge

● Many successful Microservices implementations started as monoliths

● Think about scale - Microservices really start to pay off at scale

TIP #4: UNDERSTAND THE COST OF MICROSERVICES

● Business needs to understand the ongoing cost of maintenance of the system

● You will need to invest in developer experience● Monitoring and alerting may need improvement● Understand how to deal with failure● Eventual consistency must be managed

TIP #3: YOU NEED STRONG TECHNICAL LEADERSHIP

● The technical direction needs to be consistent● The tech leadership needs to be backed by a long term

committed business● Follow conventions and document your

design decisions ● Committed advocates for the

architecture will help

TIP #2: UNDERSTAND WHAT OUTCOMES YOU WANT

● Ask yourself “If Microservices is the answer, what is the question”

● Clearly understand the outcomes you need● You don’t have to go “full” Microservices to deliver

desirable outcomes● Understand what good looks like

TIP #1: MICROSERVICES ARE GREAT - WHEN DONE WELL!

● You have to be this tall to use Microservices!● You will need a high devops maturity● Make sure you have buy in at all appropriate levels● Product thinking and customer focus will go a long way

to making Microservices a success

SOME USEFUL BOOKS...

Please feel free to come and talk to me after the session if you want a more involved answer or just fancy a chat!

52

ANY QUESTIONS?

OTHER PREREQUISITES

● IS THERE SOMETHING IN THE FUNDING MODEL TO ANSWER HERE? DOES WATERFALL FUNDING MEAN THAT IT WILL BE HARD TO MAINTAIN A GOOD MICROSERVICES INFRASTRUCTURE?

● HOW CAN YOU PROPERLY SEGREGATE THE DIFFERENT TEAMS AND PARTS OF THE SYSTEM?● AT SLC WE HAVEN’T PROPERLY SEGREGATED THINGS● MATURITY OF PRODUCT OWNERSHIP● PRODUCT THINKING - SERVICES AS PRODUCTS● TENSION BETWEEN HOW FEATURES ARE DELIVERED AND HOW THEY CONSUME CAPABILITY● THIS IS RESOLVABLE BY GOOD PRODUCT THINKING

OTHER OUTCOMES THAT CAN BE FACILITATED?

● Maybe more of a reason to use Microservices - it enables platform thinking. But is this a good thing without product focus?

EVOLVED SOLUTION BEFORE MANAGED CHANGE

MONOLITHIC RELATIONAL DATABASE

MONOLITHIC WEB APPLICATION

SOAP SERVICES

INTERNAL APPS

TECH TEAMS

WEB

TOOLS

INFRA

DB

BUSINESS TEAMS

SALES

PARTNERS

CS

CONTENT

MARKETING

PLANNED SOLUTION TO ALLOW INDEPENDENT CODE RELEASES

MONOLITHIC RELATIONAL DATABASE DB

E-COMMERCE CSPARTNERSHIPSSUPPLY CONTENT

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES

FRONT ENDS

SERVICES