Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023

This presentation was recorded at YOW! Australia 2023. #GOTOcon #YOW
yowcon.com
Gregor Hohpe - AWS Senior Principal Evangelist
RESOURCES
/ ghohpe
/ ghohpe
eaipatterns.com
ABSTRACT
Let’s be honest, the tech we have today is amazing but it can also be complex. So, it’s only natural that the platforms we build want to hide that complexity to improve productivity, avoid mistakes, and reduce cognitive load. So, the more complexity we can hide, the better our platform?
Actually no - we need to be careful that we create useful abstractions, not dangerous illusions.
This talk reflects on two decades of building complex distributed systems, highlighting where abstractions helped and where illusions led to major disappointments. [...]
TIMECODES
00:00 Intro
05:05 Platform abstraction
09:34 Abstractions vs composition
19:02 Abstractions vs Illusions
34:45 Distributed system abstractions
45:55 Summary
47:26 Outro
Read the full abstract here:
yowcon.com/sydney-2023/sessio...
RECOMMENDED BOOKS
Gregor Hohpe • Platform Strategy • leanpub.com/platformstrategy
Gregor Hohpe & Bobby Woolf • Enterprise Integration Patterns • amzn.to/3Zj2mfB
Gregor Hohpe • The Software Architect Elevator • amzn.to/3m3athI
Hohpe, Danieli, Landreau & Hashmi • Cloud Strategy • amzn.to/3KzMr8q
Vlad Khononov • Balancing Coupling in Software Design • amzn.to/3SwU6Gv
Peter Sbarski • Serverless Architectures on AWS • amzn.to/3hJzEUM
/ gotocon
/ goto-
/ goto_con
/ gotoconferences
#ComplexDistributedSystems #DistributedSystems #SoftwareArchitecture #PlatformAbstraction #ControlFlow #Abstraction #GregorHohpe #YOWcon
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf...

[@raffaeleloi]

Great presentation !!
The balance between build abstractions vs illusion is an awesome analogy and I think that is part of our lives as a software engineers.
I like this way of thinking and I really agree that we always need to find the balance in everything that we do:
- Build abstraction
- Don't abstract too much
- Use patterns
- Don't segregate the system to only use patterns in everything
- Hide details and information
- Don't hide too much
Sometimes we cannot achieve the best design from the first time, but to have the mindset to always do an incremental design and improve the places we pass is a great thing as well.

[@jameskim4274]

Phenomenal well presentation!

[@TechTalksWeekly]

This talk has been featured in the #6 issue of Tech Talks Weekly newsletter. Congrats Gregor!

[@georgerogers1166]

GM had been doing so since the 30s.

[@illiakailli]

Was surprised by "RPC - the worst illusion" claim, as it doesn't make much sense. It is a useful abstraction as well as justified simplification and is very appropriate in vast majority of scenarios. RPC does not pretend absence of partial failures, as local calls don't pretend it either: anyone who wrote multithreaded code is aware of that. Similar story with congestion, retries and whatever else was mentioned.

[@architectelevator]

What I tried to highlight is that a local method call (commonly) behaves quite differently from a remote call. You won't expect the invocation to fail due to the method being unavailable or worry about latency. Most local method calls won't have retry logic, e.g. if someone calls myString.toUpperCase() they won't have logic to retry that. There are always exceptions, so I am basing the example on common usage like one method calling another.

[@gravisan]

How about solve problems, not build abstractions...

[@ConductiveFoam]

Because good abstractions help solve problems
Also, if an abstraction becomes ubiquitous we cease to even realize it's there

[@mardukbp]

As explained in the talk abstractions (should) provide a language for describing the solution to a problem. This is a key point. The names of classes and methods (or modules and functions) should provide a vocabulary that allows people to communicate ideas about a certain domain (technical or business). As stated in the preface of SICP, software should be written for humans to understand and only incidentally for computers to execute. Unfortunately this is not how most people are taught to write software and therefore it's not uncommon to find bloated codebases which consist of layers upon layers of mindless abstractions, which make it very hard to understand what problem they are actually trying to solve.

[@orange-vlcybpd2]

Problems which can be solved without abstractions are trivial. Also your very math from the elementary school, is all abstraction. What you see on your monitor is abstraction of the signals inside the computer. Its an abstraction which helps us interpret the signals. Abstraction is the cornerstone in the foundation of our human cognition.

[@aybgim3850]

Mediocre coders solve instances of problems. Good software engineers build solutions for classes of problems. This is where abstractions come into play.

[@mardukbp]

@@aybgim3850 This is not true. It's like saying that all the Physicists that came before Newton or Maxwell were mediocre because they didn't come up with a general framework for solving problems in a given domain. A framework so general that it allows solving classes of problems arises only after solving lots of individual problems. As Newton said, he achieved what he did because he was standing on the shoulders of giants. Great scientists and engineers acknowledge this. They don't call people names.

[@szeredaiakos]

Aye('so much').hate().hooks();