Api360 Summit The Automated Monolith

Post on 07-Jan-2017

217 views 3 download

Transcript of Api360 Summit The Automated Monolith

The Automated MonolithFetching victory from the jaws of defeat

@hlgr360https://de.linkedin.com/in/hrreinhardt

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

Microservice Architecture to the Rescue

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

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

And this …

Stabilize Optimize Transform

The 3 Stages of Lean Transformation

Execution of strategy is a function of

Culture

StructureTechnology

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)

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

› 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

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

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

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

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

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

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

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

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

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