Upload
datawire
View
1.200
Download
0
Embed Size (px)
Citation preview
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
13/07/2016 @danielbryantuk
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!
13/07/2016 @danielbryantuk
@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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.620.6158&rep=rep1&type=pdf
situational awareness
13/07/2016 @danielbryantuk
philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html
speakerdeck.com/acolyer/making-sense-of-it-all
Communicate the vision
13/07/2016 @danielbryantuk
Is your technical leadership (architecture) ready?
13/07/2016 @danielbryantuk
“If you can't build a [well-structured] monolith, what makes you think microservices are the answer?”
Simon Brown(bit.ly/1n7D0vp)
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
Matt Raible’s Comparison Framework
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
Visibility for the business
13/07/2016 @danielbryantuk
Architectural feedback
13/07/2016 @danielbryantuk
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
Be prepared to talk about data liberation...
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
Opentracing & OpenZipkin
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
Cross-functional Teams
• Spotify (bit.ly/1C46ZKo)– Culture
• Amazon (bit.ly/1F3Dgkm)
– Communication
• Gilt (gi.lt/1rgyWvO)– Strategic alignment
13/07/2016 @danielbryantuk
How does Devops fit into this?
• http://web.devopstopologies.com/
• @matthewpskelton
• @beerops and @sigje
• Google SRE
13/07/2016 @danielbryantuk
Devops - define responsibilities
• Do you really want to build an entire microservices platform?
• Focus on what matters
– Ci/CD
– Mechanical sympathy
– Logging
– Monitoring
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
DevOps - Responsibilities
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
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
13/07/2016 @danielbryantuk
Bedtime reading
13/07/2016 @danielbryantuk
13/07/2016 @danielbryantukwww.slideshare.net/dbryant_uk/qcon-ny-2016-the-seven-more-deadly-sins-of-microservices
THANKS...
@danielbryantuk
http://muservicesweekly.com/
(Credit to Tareq Abedrabbo for inspiration/guidance)
13/07/2016 @danielbryantuk