Lessons Learnt from a Microservice Transformation.

1. The Automated Monolith
Fetching victory from the jaws of defeat

2. @hlgr360
https://de.linkedin.com/in/hrreinhardt

3. Introducing – Our Service Platform
http://fineartamerica.com/featured/big-ball-from-a-cable-twisted-pair-aleksandr-volkov.html
- 5 to 10 days to deploy
- 2 releases a year
- Months to test
- White box testing
- Deployed on hosted hardware
- test != prod
- Not an ESB, but worse
- Serves a wide range of services from
a single entity

4. Microservice Architecture
to the Rescue

5. Lets start simple and extract (just) User Management
9 months later - It was a complete failure
- Lost test coverage (Remember white
box testing?)
- Scope creep (lets fix all the things
which bugged us)
- Project complexity grew out of control
(Leading Indicator: “We just need X
more developers”)
- Agile became frAgile
- Team morale and spirit were
destroyed

6. And then I remembered this
http://martinfowler.com/bliki/MicroservicePrerequisites.html
What did Fowler state as minimum:
- Rapid provisioning
- Basic Monitoring
- Rapid application deployment
And based on our experience
- Automated Testing

7. And this …
Stabilize Optimize Transform
The 3 Stages of Lean Transformation

8. Execution of strategy is a function of
Culture
StructureTechnology

9. So we reset the project (but kept the team)
• Strictly time-boxed phases (3 Months)
• Move from Agile to wAgile but with Critical Chain PM approach
• Additional focus on team culture, attitudes, and challenge
• Phase 1 (Dev and Test) => reduced time to deploy from 5-10 days to 30 min
• Infrastructure as Code (Docker)
• Rapid deployment via Cloud (Azure)
• Build and deployment automation through Go.CD
• Inmutable Server
• Phase 2 (ongoing)
• Test automation (plus switch from white to black box testing)

10. Team should not be allowed
to switch to other (non-
project) tasks
More clear requirements
needed.
I feel the lack of management
/ progress tracking.
Bad communication
Lack of intermed. milestones
Lessons learned results “We want to“:
• have effective Project Management
• deliver reliably and talk about it
• have a good working relationship
with clear roles & responsibilities
Lack of trust
Atlantic development is
slow, we avoid it
whenever we can.
We need the “good guys”
to handle the run biz.
There’s nobody else.
If we want to keep
Atlantic, we need to be
more agile. More self
responsible. But
obviously this doesn’t
work out.
The Timisoara team doesn’t
perform. We are thinking
about alternatives.
Drawing by Olaf Klöppel, PM at Haufe-Lexware

11. › Highly motivated
team who is proud
of what they are
doing
› First release was on time, in scope and budget
› Public Meetup in TIM, Brown Bag in Freiburg, blog
article, DevOps Day and application to speak at a
conference
› Spoke to multiple project teams about our
experiences, several picking up bits from our project
› We have a clear scope on
how to improve Atlantic
further with clear business
benefits
Drawing by Olaf Klöppel, PM at Haufe-Lexware

12. Drawing by Olaf Klöppel, PM at Haufe-Lexware

13. Drawing by Olaf Klöppel, PM at Haufe-Lexware

14. Drawing by Olaf Klöppel, PM at Haufe-Lexware

15. Drawing by Olaf Klöppel, PM at Haufe-Lexware

16. Drawing by Olaf Klöppel, PM at Haufe-Lexware

17. Struture: Critical Chain Project Management
• Progress tracking with „buffer consumtion“
• Weekly
• Update of plan and review of buffer:
• Green – do not interfere
• Yellow – prepare to act
• Red – act(!) together with the team
• Management focus
• The updated plan also shows the critical chain
(usually a resource) so it avoids worrying about
delays in non critical tasks
Best Case
Official
Olaf Klöppel, PM at Haufe-Lexware

18. Culture: Mission Command (Auftragstaktik)
- Build Cohesive Teams through Mutual Trust
- Create Shared Understanding
- Provide a Clear Intent
- Exercise Disciplined Initiative
- Use Mission Orders
- Accept Prudent Risks

19. Lessons learnt
• Do the basics first (yes, you need to be that tall)
• Focus initially on creating throughput for follow-up phases
• Remember technology, culture and structure need to be aligned
with each other and your goal
• Stabilize the team after failure by being “agile” with your
methodologies (from Agile back to wAgile back to Agile)
• If you need to do a pivot or reset, do it with ‘Shock and Awe’
• Leadership is important during vulnerable phase
• Don’t do an all-out MSA carve-out because of MSA, but focus on
where you need speed of change. Leave the rest automated.
• Move from IT-driven to product-centered team approaches mid-term

20. Stay in touch
• http://dev.haufe.com/the-automated-monolith/
• http://www.slideshare.net/HaufeDev/the-automated-
monolith
• Github: https://github.com/Haufe-Lexware
• Blog: http://dev.haufe-lexware.com
• Twitter: @HaufeDev