Upgrade to Pro — share decks privately, control downloads, hide ads and more …

bla bla microservices bla bla: director's cut

bla bla microservices bla bla: director's cut

Everyone is talking about microservices, but there is more confusion than ever about what the promise of microservices really means and how to deliver on it. In this talk we will explore microservices from first principles, distilling their essence and putting them in their true context: distributed systems.

We will start by examining individual microservices and explaining why it is important to adhere to the core traits of autonomy, isolation, single responsibility, exclusive state, asynchronicity, and mobility. But what many people forget is that microservices are collaborative by nature and only make sense as systems. It is in between the microservices that the most interesting and rewarding, but also challenging, problems arise—here we are entering the world of distributed systems.

Distributed systems are inherently complex, and we enterprise developers have been spoiled by centralized servers for too long to easily understand what this really means. Slicing an existing system into various REST services and wiring them back together again with synchronous protocols and traditional enterprise tools—designed for monolithic architectures—will set you up for failure. What we need in order to build resilient, elastic, and responsive microservices-based systems is to embrace microservices as systems and re-architect them from the ground up using reactive principles.

Jonas Bonér

October 04, 2016
Tweet

More Decks by Jonas Bonér

Other Decks in Programming

Transcript

  1. ONE DEFINITION SUPPORTS MULTIPLE AUTONOMOUS TEAMS ORGANIZED TO SCALE THE

    DEVELOPMENT WHERE THE TEAMS CAN DEVELOP, DEPLOY AND MANAGE THEIR SERVICES INDEPENDENTLY
  2. > Commands diverge into unpredictable outcomes from definite beginnings ˰

    decreased certainty > Promises converge towards a definite outcome from unpredictable beginnings ˰ improved certainty
  3. Organizations which design systems ...are constrained to produce designs which

    are copies of the communication structures of these organizations. — Melvin Conway
  4. MESSAGE-PASSING ALLOWS FOR LOCATION TRANSPARENCY ONE COMMUNICATION ABSTRACTION ACROSS ALL

    DIMENSIONS OF SCALE CORE ˰ SOCKET ˰ CPU ˰ CONTAINER ˰ SERVER ˰ RACK ˰ DATA CENTER ˰ SYSTEM
  5. The Unix philosophy: Write programs that do one thing &

    do it well. Write programs to work together. — Doug McIlroy
  6. The truth is the log. The database is a cache

    of a subset of the log. — Pat Helland
  7. THE LOG IS A DATABASE OF THE PAST NOT JUST

    A DATABASE OF THE PRESENT
  8. YOU NEED TO SEPARATE THE STATELESS PART — THE BEHAVIOR

    FROM THE STATEFUL PART — THE KNOWLEDGE
  9. But I'll take my time anywhere. I'm free to speak

    my mind anywhere. And I'll redefine anywhere. Anywhere I roam. Where I lay my head is home. — Wherever I May Roam by Lars Ulrich, James Hetfield (Metallica)
  10. WHY WOULD I NEED VIRTUAL ADRESSING? 1. Load-balancing between stateless

    services 2. State replication of stateful services 3. Relocation of a stateful service
  11. In a distributed system, you can know where the work

    is done or you can know when the work is done but you can’t know both — Pat Helland
  12. INSIDE DATA: OUR CURRENT PRESENT OUTSIDE DATA: BLAST FROM THE

    PAST BETWEEN SERVICES: HOPE FOR THE FUTURE — PAT HELLAND (DATA ON THE INSIDE VS DATA ON THE OUTSIDE)
  13. Words are very unecessary. They can only do harm. Enjoy

    the silence. — Enjoy the Silence by Martin Gore (Depeche Mode)
  14. The contents of a message are always from the past!

    They are never “now.” — Pat Helland
  15. WE HAVE TO RELY ON EVENTUAL CONSISTENCY BUT DON'T BE

    SURPRISED IT'S HOW THE WORLD WORKS
  16. Be conservative in what you do, be liberal in what

    you accept from others. — Jon Postel
  17. In general, application developers simply do not implement large scalable

    applications assuming distributed transactions. — Pat Helland