The title is of course tongue-in-cheek though he does elaborate on what he perceives as the primary drivers behind the microservices hype:
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 has been the
CTO at 6Wunderkinder since 2013 but is also the (co)author of a number of Ruby/Rails books and The Passionate Programmer 2e (was My Job Went to India - 52 Ways to Save Your Job).
Wow, really nice talk. First time I am hearing about impermanence. Thanks for sharing.
Kevlin Henney weighing in on the notion of discard-ability.
Not really sure though that in an OO environment obsessed with reuse people are ready to see:
So small that a single service can be readily discarded (if it can’t, it ain’t
in the “Pro” column for microservices.
PS/Off topic: This is interesting even if you don’t have a C++ background:
Kevlin Henney - Functional C++ (Caution: @48:30 possible manifestation of Virding’s First Rule of Programming).
#Dan North: Software that Fits in Your Head - Goto Amsterdam 2016-June-14
The talk essentially drives to the conclusion that a
is one of the “Big Ideas” behind Microservices - i.e. it is important to Component Architecture Replaceable . optimize for replaceability
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.
This really resonates with me - and I think when more people cotton on to PragDave’s radical approach to development with Elixir, it’s going to be a h u g e selling point
Haven’t read this yet but it may be of interest to readers of this thread…
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…