Speaker: Justin Reock @jreock
For more, see the table of contents
References
- “It’s no longer the big beating the small, but the fast beating the slow”
- Book: The Goal – Eliyahu Goldratt. Theory of Constraints for Business Productivity. Business fiction.
- Book: Phoenix Project. Similar to The Goal but software business fiction
- Book: The Machine that Changed the World
- Book: Organizational physics – the science of growing a business. Short. Why businesses fail
Constraints
- Change focus from costs to throughput
- Layoffs reduce costs but decreasing costs
- Need to both decrease costs and increase throughput
- Cost = organizational cost
- Inventory = Code
- Throughout = Money
- Doesn’t really matter what improve as long as constantly improving something because entropy makes things worse if do nothing.
DevOps
- Chose supported free software and open first policy
- Deploy in cloud/containers
- If do container and not 12 factor, don’t see benefits
- APIs are everything now. Govern APIs
- Build fail-fast culture. Near instant release (and therefore patch)
Problems with Closed Development
- Slow to obtain
- Inflexibility in growth/scaling. ex: fixed number licenses
- Can’t modify
- Can’t benefit from others
- Lose growth vs giving competitors features
- Less oversight, less security
Path
- Individual physical servers
- Virtual machines
- Containers (stripped down OS powered by one underlying OS)
- Created ecosystem with proliferation of microservices – Kubernetes (Greek word for captain). Now can have virtual datacenter in a box
12-Factor
Series of characteristics to increase odds of success in cloud/containers. The less you do for an app, the more friction you will have going to cloud/containers.
- Codebase – in version control, deploy often
- Dependencies – explicitly declare and isolate
- Config – store in env. Env variables popular again
- Backing Services – treat as attached resources
- Build. release, run – separate strategies
- Processes – one or more stateless processes
- Port binding – how to expose services
- Concurrency – Docker gives for free
- Disposability – fast startup, graceful shutdown
- Dev/prod parity – keep as similar as possible
- Logs – push events out to central system via event streams
- Admin processes – manage as one offs
Coding
- About flow
- Use left and right brained activities
- Problem solving – hypothesis and feedback from build system.
- Feedback feels good and keeps in state of creative flow
- The longer you wait for a build, the less happy you are
- Few track local build times.
- Waste waiting for and debugging local and CI builds
- 10x developer – organizational culture matters more than individuals
Benefits of faster cycle time
- Less idle time
- Less content switching – people can’t multi task. Also, bad for brain to try
- More focus
- Build more often
- Earlier quality checks
- Few expensive downstream incidents
- Smaller change sets
- Fewer merge conflicts
- More efficient troubleshooting
- Faster mean time to recovery
Trends
- 1970s – JIT manufacturing
- 1980s – Business process reengineering
- 1990s – Change management
- 2000s – Agile, Lean Six Sigma
- 2010s – DevOps
- 2020+ DPE (developer productivity engineering)
DPE
- Engineering approach to productivity
- Acceleration and analytics tech to improve dev experience
- build cache – Gradle has option to use. Also Gradle Enterprise brought to Maven
- Aligns with management goals – faster TTM (time to market), reduced cost, improved quality
- https://gradle.com/learning-center-by-objective/
- https://gradle.com/developer-productivity-engineering/handbook/
My take
Good mix of current and historical examples from outside computing (I didn’t blog about the history part), I hadn’t heard of 12-Factor prior to reading the abstract for this talk. I would have liked more time on it since it is a third of the title, but the talk flowed well as is.