MRH.io logo

MRH.io logo

Adaptive Leadership for Technical Projects

🌌 OrbitDB
P2P databases for the distributed web, build on CRDTs
🦀 Rust IPFS
A Rust implementation of the Interplanetary File System
📈 TallyLab
A privacy-first, end-to-end encrypted time-series data platform
Hack for the Sea
An annual hackathon where technology and the ocean meet.
This website does not track you.
The best way to reach out is via e-mail.

Notes: “Good Enough” Architecture

by Stefan Tilkov

April 01, 2020Talk Notes, GOTO 2019, Stefan Tilkov, Software Architecture, Microservices

@ stilkov | slides | video

Abstract: In this session, we’ll take a look at some of the ways we can determine whether the development efforts we’re undertaking suffer from too much or too little focus on architecture. We’ll examine a number of real-world examples that are intended to inspire either admiration or terror, and try to find some recipes of how we can get more of the former and less of the latter in our own projects.


Definitions of Architecture

ISO/IEC/IEEE 42010:

Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

Grady Booch:

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change

Stefan Tilkov:

Whatever the architect considers important enough to merit their attention

Graph of software scaling dimensions

Different organizations and applications will require different architectures, and those architectures will change over time

Cases:

#1 Non-Extensible Extensibility

Highly customizable multi-tenant e-commerce solution with lots of features, which has to balance between large customers with specific needs and small customers with generic needs

  • If you attempt to design something that satisfies everybody, you will satisfy nobody.
  • Highly specific is often preferable to generic

#2 Perilously fine-grained

Large-scale B2B food retailer building a new logistics system, hired >200 developers to build a microservice-based system. Each developer “owned” a microservice, which was hell to scale. Eventually moved away from ‘EntityService’ pattern

  • Everybody wants to be Netflix but nobody is
  • Small is not always beautiful
  • Refactoring within team boundaries much easier than globally
  • Ignore organizational parameters at your own risk

#3 Your system WILL be dynamic

Large-scale insurance system with >100 developers. 2 releases / year with 2-week modeling period What if you miss this slot?

  • Centralized responsibility hurts
  • Faces with too much rigidity, a way around the rules will be found
  • Just because you’re used to it doesn’t make it acceptable

#4 Free-style Architecture

A small E-Commerce / Online shop which grew fast to 100-120 developers over ~10 self-contained teams

  • Avoid increasing the numbers of developers if you can
  • Move to system of systems
  • If you don’t actively create an architecture, be prepared to deal with the one that emerges.
  • Loose coupling requires very few rules, but they need to be enforced strictly

Strength of decoupling

#5 Cancerous Growth

Financial services provider with independent brokers as clients, 20 years of company history. Spun off new company and just copied system and then shared the database. Also implemented own encryption in Borland C++ and noticed bug after encryption own database

  • Successful systems often end up with the worst architecture
  • Unmanaged evolution will lead to complete chaos
  • Don’t be afraid of some light architectural governance

#6 Improve with less intelligence

Bank with multiple CotS systems, phased out proprietary solution to replace with OSS. Replaced “Magical Integration Broker” with much more simple dockerized pubsub solution.

Final Takeaways

  1. Don’t be afraid of architecture
  2. Choose the simplest thing that will work
  3. Create evolvable structures
  4. Manage your system’s architectural evolution
  5. Don’t create road blocks - create value and get out of the way

Have a talk you want to see notes on? E-mail mark@mrh.io