The title is of course tongue-in-cheek though he does elaborate on what he perceives as the primary drivers behind the microservices hype:

Embrace change

Impermanence is the key to a surviving system

The system is an asset

Code is a liability

Essentially he is advocating that replace-ability at the “tiny component level” is a key attribute to a successful system (interesting position in an industry that is often obsessed with reuse). This presentation could be seen as an extension of Goto 2014 - Keynote: Legacy - Chad Fowler (Systems Euthanizer). Whatever you may think of the talk as a whole, it is sure to contain some thought provoking tidbits.

Chad Fowler’s RubyConf 2017 Keynote is a continuation of the established theme. This time the cell analogy threads throughout to highlight the idea of components for replaceability rather than reusability.

Unless you’ve been living under a rock, you probably already know that microservices is the architecture du jour. Coming of age alongside this trend, Segment adopted this as a best practice early-on, which served us well in some cases, and, as you’ll soon learn, not so well in others.

Briefly, microservices is a service-oriented software architecture in which server-side applications are constructed by combining many single-purpose, low-footprint network services. The touted benefits are improved modularity, reduced testing burden, better functional composition, environmental isolation, and development team autonomy. The opposite is a Monolithic architecture, where a large amount of functionality lives in a single service which is tested, deployed, and scaled as a single unit.

In early 2017 we reached a tipping point with a core piece of Segment’s product. It seemed as if we were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded.

Eventually, the team found themselves unable to make headway, with 3 full-time engineers spending most of their time just keeping the system alive. Something had to change. This post is the story of how we took a step back and embraced an approach that aligned well with our product requirements and needs of the team…