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
ü Transformingorganisationsthrough 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 leadership

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 practicesand 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 explicitas possible the Values at playin 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 learning

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 somewhere

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...

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

www.slideshare.net/dbryant_uk/qcon-ny-2016-the-seven-more-deadly-sins-of-microservices

THANKS...
@danielbryantuk
daniel.bryant@opencredo.com
http://muservicesweekly.com/
(Credit to Tareq Abedrabbo for inspiration/guidance)

Microservice Summit 2016 "Microservices: The Organisational and People Impact"

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie Microservice Summit 2016 "Microservices: The Organisational and People Impact"

Ähnlich wie Microservice Summit 2016 "Microservices: The Organisational and People Impact" (19)

Mehr von Daniel Bryant

Mehr von Daniel Bryant (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Microservice Summit 2016 "Microservices: The Organisational and People Impact"