microservice summit 2016 "microservices: the organisational and people impact"

Microservices: The organisationAl and People Impact

Daniel Bryant

@danielbryantuk

OpencRedo

TL;DR

Implementing Microservices is easy

Implementing Microservice systems is complex

(This includes the associated organisational/people systems)

13/07/2016 @danielbryantuk

Welcome to the early majority


Microservices are here

innovateordie.com.au/2010/05/10/the-secret-to-accelerating-diffusion-of-innovation-the-16-rule-explained/

What do I see in the field?

Most of the current problems with implementing microservices

are connected with people and organisational systems

this is good news, as we already have many solutions!


@danielbryantuk• Chief Scientist at OpenCredo

ü Transforming organisations through technology and teams

ü Agile, Lean, Architecture, CI/CD, DevOps

ü Microservices, cloud, Containers, Java, Go, Docker, Kubernetes

• London Java Community Associate

• Adopt OpenJDK and JSR

• InfoQ Editor, DZone MVB, VOXXED, O'Reilly


Today

• Strategy– Is your business ready for microservices?

– Technical leadership is vital

– Choosing Tools is challenging

• Feedback– Optimise for Visibility and learning (throughout the organisational stack)

• Responsibilities– Conway, spotify and cargo culting

– Devops is about sharing


1. Strategy - situational awareness and leadership13/07/2016 @danielbryantuk

Strategy - are Microservices A good fit?• “our 'mode TWO' apps are Microservices”

– No transformation / migration plan

– SOE evolution limited by SOR

– Lipstick on the pig

• Not understanding principles (Cargo-culting)– Teams not operating around Biz Functionality

– No leadership leads to building Mini-monoliths

• No Well-defined DevOps / SRE / Ops– Deployment/ops free-for-all


Is your business ready?• Critical success facts in software projects (1999)

– 1. Project managers don't understand user's needs

– 2. The project's scope is ill-defined.

– 3. Project changes are managed poorly.

– 4. The chosen technology changes.

– 5. Business needs change.

– 6. Deadlines are unrealistic.

– 7. Users are resistant.

– 8. Sponsorship is lost.

– 9. The project lacks people with appropriate skills.

– 10. Managers ignore best practices and lessons learned


citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.620.6158&rep=rep1&type=pdf

situational awareness


philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html

speakerdeck.com/acolyer/making-sense-of-it-all

Communicate the vision


Is your technical leadership (architecture) ready?


“If you can't build a [well-structured] monolith, what makes you think microservices are the answer?”

Simon Brown(bit.ly/1n7D0vp)

Tech Leadership - Responsibility, knowledge & tactics

• Promote shared understanding– Communication (bit.ly/1Ia3u8o)

• Risk management

• ‘Just enough’ up front design– Microservice glue and platforms

• Leadership principles– Autonomy, purpose & mastery


Is your dev/operations team ready?

• Fowlers Microservices Prerequisities

– Rapid provisioning

– Basic monitoring

– Rapid application Deployment

• The technical side of devops

– Audit Continuous integration/delivery

– Choosing Tooling is challenging


Tooling - The’Spine Model• Effective conversations make for effective

collaboration– Kevin Trethewey & danie Roux, Agile 2015

• It's a TOOL Problem– As a species, we have always been Tool users

and makers.

– We use _____ to get our work done

• People get stuck in a dilemma where equally plausible options are available – “Going up the Spine” breaks deadlock

http://spinemodel.info/explanation/introduction/

Tooling - The’Spine Model• PRACTICES before Tools

– Decide on the Practices that the tools are there to support

– We do _____ to create value

• PRINCIPLES before Practices– Decide on the Principles to measure those Practices against.

– We leverage _____ to change the system

• VALUES before Principles

– Make as explicit as possible the Values at play in the system.

– We optimise for _____

• NEEDS before Values– It all starts at Needs. Why does this system exist in the first

place?

– We are here to satisfy _____http://spinemodel.info/explanation/introduction/

Evaluation - Fitness functions

• Microservices as an Evolutionary Architecture

– Neal Ford and Rebecca Parsons

• Great for evaluation and documentation

– Platforms / Language

– Middleware

– Data stores


Matt Raible’s Comparison Framework


Final thoughts: Pick Your (Technical) Battles...…

• Optimize globally across the organisation– start small

– Product teams own thier languages and tools

– Apply 'Natural selection' - Only officially support 'fittest' tools

• As Dan McKinley says, “Choose Boring Technology”

• The internal open source model works well with microservices


2. Feedback - visibility and constant learning13/07/2016 @danielbryantuk

Constant learning (and action)

• Microservices typically generate more data– This can stretch limitations within the organisation!

• Existing tooling is optimised towards monolithic applications– Aggregation and intelligence is vital

• Regular reviews and retrospection are essential– Take action from feedback and failures


Visibility for the business


Architectural feedback



www.infoq.com/news/2015/04/raffi-krikorian-rearchitecting

Conversations are vital for Tech Leads• Standards

– HTTP, REST, JSON, message format etc

– Documentation e.g. swagger, RAML, WADL

• Testing

– Consumer-based contracts (PACT, PACT-JVM, PACTO etc)

– E2e Automation, automation, automation

• Microservices framework/foundations – Architypes, base modules (Finagle, Karyon) etc


Talk about Testing - API simulation with Hoverfly

• Lightweight Service virtualisation

– Open source (Apache 2.0)

– Go-based / single binary

– Written by @Spectolabs

• Flexible API simulation

– developing against agreed apis

– Great for nfr testing


Be prepared to talk about data liberation...


Microservice developers be like

F*cking monolithic database

Credit to Michael Hausenblas

Operational visibility

• Logging

– The 10 Commandments of Logging

– The Log: What every software

engineer should know

• Monitoring

– Rob Ewaschuk's Philosophy on

Alerting”

– Brendan Gregg's USE method


Opentracing & OpenZipkin


Microservices enable agility

• When done well...

• Build, measure, learn– Design for impact

– Build-in signals and metrics

– Create a culture of experimentation and failing fast

• If you don'T collect the data and Take action to adapt...– there is limited benefit with microservices


3. Responsibilities - the buck always stops somewhere13/07/2016 @danielbryantuk

Conway'S law

“organizations which design systems are

constrained to produce designs which are

copies of the communication structures of

these organizations”

- Melvin conway


We hear this a lot...

“We’ve decided to reform our teams around squads, chapters and guilds”

• Beware of cargo-culting

– Repeat three times “We are not spotify”

• Understand the practices, principles, values etc


Cross-functional Teams

• Spotify (bit.ly/1C46ZKo)– Culture

• Amazon (bit.ly/1F3Dgkm)

– Communication

• Gilt (gi.lt/1rgyWvO)– Strategic alignment


How does Devops fit into this?

• http://web.devopstopologies.com/

• @matthewpskelton

• @beerops and @sigje

• Google SRE


Devops - define responsibilities

• Do you really want to build an entire microservices platform?

• Focus on what matters

– Ci/CD

– Mechanical sympathy

– Logging

– Monitoring


Devops - the 'fullstack engineer' myth

“I'M sorry, but if you'RE not designing the computer chips and

writing the website, then I don'T wanna hear from you”

Charity Majors (@mipsytipsy), CraftConf 2016

http://www.ustream.tv/recorded/86181845


DevOps - Responsibilities


In conclusion: Microservices will create change...13/07/2016 @danielbryantuk

Change Management is Essential

• Fair process (three ‘E’s)– Engagement

– Explanation

– Expectation

• Leading change

– Transformation is a process

– Communicate, plan, evaluate, learn, Empower

– Obtain buy-in from the top


Leading change

1. Establish sense of urgency

2. Create the guiding coalition

3. Develop a vision and strategy

4. Communicate the vision

5. Empower employees for broad-based action

6. Generate short-term wins

7. Consolidate gains and produce more change

8. Anchor new approaches in the culture


Wrapping up - Conclusion

• Strategy– Get your business ready for microservices

– Technical leadership (architecture) skills are vital

– Choosing Tools is challenging

• Feedback– Visibility and learning (optimise throughout the organisational stack)

• Responsibilities– Learn from Conway and spotify, but do not cargo cult blindly

– Devops (done right) is a prerequisite for microservices


Bedtime reading


13/07/2016 @danielbryantukwww.slideshare.net/dbryant_uk/qcon-ny-2016-the-seven-more-deadly-sins-of-microservices

THANKS...

@danielbryantuk

[email protected]

http://muservicesweekly.com/

(Credit to Tareq Abedrabbo for inspiration/guidance)
