Api360 Summit The Automated Monolith
Download as PPTX, PDF•1 like•491 views
The document discusses the challenges faced when attempting to transition a monolithic application to microservices. An initial attempt to extract a single service failed due to lost test coverage, scope creep and increased complexity. Lessons were learned around the need for rapid provisioning, monitoring, deployment and automated testing. A reset was implemented with time-boxed phases, infrastructure as code using Docker, and deployment automation. This successful approach focused on stabilizing the team through an emphasis on culture, structure and technology alignment to deliver reliably on time and budget.
Api360 Summit The Automated Monolith
- 1. The Automated Monolith Fetching victory from the jaws of defeat
- 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