Microservices are where it's at. Everything is easier to manage when it's micro, right? Micro code bases (less than 10 LOC), micro containers (less than 10Mb), and micro teams (less than one person???). 'Micro' things may appear to be easier to manage, but there is always a macro context, and working with people and teams is no exception. This talk presents some of the challenges the OpenCredo team have seen when implementing microservices within a range of organisations, and we'll suggest tricks and techniques to help you manage your 'micro' teams and the 'macro' level.
Topics covered include: empathy - because understanding others is at the heart of everything you do; leadership - advice on creating shared understanding, conveying strategy, and developing your team; organisational structure - from Zappos' holocracy to MegaOrg's strict hierarchy, from Spotify's squads, chapters and guilds, to BigCorp's command and control. There is a management style for everybody; and more
2. TL;DR
Implementing Microservices is easy
Implementing Microservice systems is complex
(This includes the associated organisational/people systems)
13/07/2016 @danielbryantuk
3. 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/
4. 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
5. @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
13/07/2016 @danielbryantuk
6. 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
7. 1. Strategy - situational awareness and leadership
13/07/2016 @danielbryantuk
8. 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
9. 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
13/07/2016 @danielbryantuk
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.620.6158&rep=rep1&type=pdf
12. 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)
14. 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
15. 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
16. 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/
17. 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/
18. 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
20. 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
21. 2. Feedback - visibility and constant learning
13/07/2016 @danielbryantuk
22. 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
26. 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
27. 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
28. Be prepared to talk about data liberation...
13/07/2016 @danielbryantuk
Microservice developers be like
F*cking monolithic database
Credit to Michael Hausenblas
29. 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
31. 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
33. 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
34. 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
35. Cross-functional Teams
• Spotify (bit.ly/1C46ZKo)
– Culture
• Amazon (bit.ly/1F3Dgkm)
– Communication
• Gilt (gi.lt/1rgyWvO)
– Strategic alignment
13/07/2016 @danielbryantuk
36. How does Devops fit into this?
• http://web.devopstopologies.com/
• @ matthewpskelton
• @beerops and @sigje
• Google SRE
13/07/2016 @danielbryantuk
37. 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
38. 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
41. 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
42. 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
43. 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