Rocky Mountain Ruby 2016 - Kill "Microservices" before its too late by Chad Fowler

[peerreynders]

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 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).

[DianaOlympos]

[minhajuddin]

Wow, really nice talk. First time I am hearing about impermanence. Thanks for sharing.

[peerreynders]

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 micro).

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).

[peerreynders]

####Dan North: Software that Fits in Your Head - Goto Amsterdam 2016-June-14

The talk essentially drives to the conclusion that a Replaceable Component Architecture is one of the “Big Ideas” behind Microservices - i.e. it is important to optimize for replaceability.

[peerreynders]

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.

Various highlights:

• How do you create systems that survive?
• Reference to RailsConf 2014 - All the Little Things by Sandi Metz:
  “All of the problems we cause have the same simple solution … Make smaller classes, make smaller methods, and let them know as little about each other as possible.”
• Code is “this big”
• Kill and replace cells regularly - forces you to work with small components
• The System is the asset; Code is a liability
• Immutable Infrastructure - Never Upgrade Software on an Existing Node
• Immutability in Code
• Functions as a service
• Never edit a method. Always rewrite it.
• Mutability of a system is enhanced by the immutability of its components
• Heterogenous By Default
• Assume Failure (Joe Armstrong/Erlang reference) - MTBF vs MTTR
• Test Are a Design Smell - Tests are coupling
• Experience the Worst Case Scenario so You don’t Have to Fear It.
• Homeostatic Regulation
• Pinterest spot instances
• Services own and encapsulate data
• The Big Rewrite - No More

[AstonJ]

@peerreynders

The talk essentially drives to the conclusion that a Replaceable Component Architecture is one of the “Big Ideas” behind Microservices - i.e. it is important to optimize for replaceability .

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

[AstonJ]

Haven’t read this yet but it may be of interest to readers of this thread…

What are Microservices? + How to Consolidate & Scale Them

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…