Another Of Your Harebrained Schemes: Why Executives Should (or Shouldn't) Back Microservices

Please log in to watch this conference skillscast.

You've bought into the dream of decentralisation and signed up for services and monitoring in place of objects and unit tests. Your team members are itching to write tiny applications in multiple languages and to deploy independent components many times a day. But before you can enter the brave new world of microservices, you'll likely need to convince someone in a suit that it's worth giving you time and money to try out this unfamiliar development method. CEOs, CTOs, CFOs, and others in the boardroom brigade are skeptical and risk-averse by nature. What problems might they see microservices solving for them, and are these sufficiently important issues to warrant substantial investment?

In this session, we'll look at the history of methodology innovations and reflect on why some fail (formal verification, tuplespaces) and others succeed (agile development, object-oriented programming). We'll remind ourselves about Moore's technology adoption lifecycle (innovators, early adopters, early and late majority). This will give us context for statements like these from real executives (sound familiar?):

• "Doing twice as much on the same budget is a good challenge for them."
• "Every developer wants to rewrite the code base from scratch."
• "All I ask for is faster development and the next thing I know they're all pairing or deploying or whatever."

I'll put the case that certain promised benefits of microservices should be music to the ears of the C-suite - but not necessarily for the same reasons they delight us techies. These include:

• easy, habitual rewriting - to eliminate development drag from long-term technical debt
• independent component deployment - to keep features flowing to key groups
• monitoring business metrics - as a check on the possibly unintended consequences of rapid change
• decoupled services with simple connectors - to help ease reallocation of people and resources

And I will argue that some elements of microservices may give execs the heebie-jeebies, and that if they are of sufficient concern, may indicate that microservices aren't suitable for the circumstances. For instance:

• a group of fast-evolving, independent components are likely to exhibit a certain amount of emergent behaviour, and if uncontrolled in a system with real-time effects, this can pose a huge risk (see Knight Capital 2012)
• building a multilingual team can be difficult and expensive, and maintaining the polyglot system they create may be impossible for traditionally-structured firms
• organisational barriers may make some practises impossible to adopt, or just politically difficult to consider - e.g. company policies on database administration or entrenched, separate QA or operations teams We will discuss these and other potential objections, as well as possible mitigations.

I hope attendees will find it helpful to have had this tour of microservices from the executive's point of view - both for making a case for the method in their organisations, and for carefully considering whether it is suitable for them.

YOU MAY ALSO LIKE:

• Sprinting In Place: The Cost of Missing Leadership Conversations (SkillsCast recorded in March 2019)
• Carving Microservices Out of the Monolith With Domain Storytelling (SkillsCast recorded in November 2022)
• Rethink Microservices (SkillsCast recorded in November 2022)