But, the old systems don’t just die. They are replaced. Furthermore, in most cases, homegrown systems are replaced in stages. In those stages, the old systems have to talk to the new systems. Someone has to know how to make the new speak to the old, and vice versa. Typically, the young tykes don’t know (or want to know) how to make the old systems listen. Nor do the crusty old pre-retirees know how to make the newfangled systems talk to their beloved creatures.
So, there’s a role to be filled by a calculating technologist: technology hospice. Helping the old systems die comfortably and with dignity is a task that should not be underestimated. And, of course, most people will jump ship before it sinks, either via retirement or by sidestepping into another technology realm. By being the last one left to support still-critical systems, you can pretty much call the shots. It’s risky, in that once the technology really is gone, you’ll be an expert in something that doesn’t exist. However, if you can move fast enough, you can look for the next dying generation of legacy systems and start again.
The adoption curve has edges at either end. How far out on the edges do you want to be?”
(My Job Went to India - 52 Ways To Save Your Job (2005) pp.22-23 /The Passionate Programmer 2e (2009) (webarchive) p.25)
by Chad Fowler Professional Systems Euthanizer
Legacy • Chad Fowler • GOTO 2014
Rocky Mountain Ruby 2016 - Kill "Microservices" before its too late by Chad Fowler
- Impermanence—the ironic key to systems that survive
- Tiny Components
- Disposable Components
- The System is the Asset—Code is a Liability
- No Shared Code
- Immutable == disposable
- “small project” == “impermanent project”
- Microservices is not an architecture
- Systems that survive are made of components that can change
RubyConf 2017: Keynote: Growing Old by Chad Fowler
- How do you create systems that survive?
- Reference to RailsConf 2014 - All the Little Things by Sandi Metz:
- Code is “this big”
- Cell Analogy
- 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
Software that Fits in Your Head • Dan North • GOTO 2016
- Productive ≠ Effective
- Optimze for Replaceability
- Fits in My Head (earlier version)
- Replaceable Component Architecture
- Dreyfus Squared
- Spike & Stabilize
- Attend to the Team's Health
- Dis-cardable Code
-
Today, we suffer from an almost universal idolatry of giantism. It is therefore necessary to insist in on the virtues of smallness—where this applies (E. F. Schumacher; Small Is Beautiful: A Study of Economics As If People Mattered, 1973).
-
Software development does not have economies of scale. Development has Diseconomies of scale. Allan Kelley
-
So small that a single service can be readily discarded (if it can’t, it ain’t micro).
-
- Virding’s First Rule of Programming
(Babylon 5 s4e09: Atonement) Dukhat: When others do a foolish thing, you should tell them it is a foolish thing. They can still continue to do it, but at least the truth is where it needs to be.