!!! ATTENTION: Highly unstructured braindump content !!!
Day 1
The Self-Steering Organization: From Cybernetics to DevOps and Beyond
Nice intro intro cybernetics and systems theory. Nothing really new for me as I’m into system theory a very little bit. Keywords: Auto autopoiesis, systems theory, cybernetics, empathy, feedback.
Ceci n’est pas #devops
- “DevOps is culture, anyone who says differently is selling something. Tools are necessary but not sufficient. Talking about DevOps is not DevOps.”
- fun experiment replace every occurrence of “DevOps” with “empathy” and see what happens ;-) reminded me of the “butt plugin”)
Cognitive Biases in Tech: Awareness of our own bugs in decision making
- Talk is mainly backed by the book “Thinking, fast and slow”
- Brain is divided in System 1 and System 2
- System 2 gets tired easily: Do important decisions in the morning (e. g. monolith vs. micro-service), postpone trivial ones to the evening (e. g. what to cook for dinner)
- great hints for better post mortems
5 years of metrics and monitoring
- great recap on infoq
- You really have to focus on how to visualize stuff. Looks there needs to be expertise for this in a company which wants to call itself “metrics driven” or “data driven”
- We have to be aware of Alert fatuigues:
- noise vs. signal
- not reacting to alerts anymore, because “they will self-heal anyway in a few minutes” (we call this “troll-alert” internally, which is a very bad description for an alert coming from a non-human system which is apparently not able to troll)
Ignites
Repository as an deployment artifact - Inny So
- talking about apt.ly - application+environment as atomic release tags
Day 2
Running a fully self-organizing/self-managing team (or company)
- good recap at infoq
- interesting open allocation work model, but with managers, feedback loops, retrospectives and planning meetings. They call it “self-selection”
- it’s sometimes better to let people go instead of trying to keep them
- people need explicit constraints to work in, otherwise they don’t know their and others boundaries
[Automation with humans in mind: making complex
systems predictable, reliable and humane](https://gist.github.com/s0enke/0ac2f6a0cce307d9cddc)
- InfoQ ;-)
Open spaces
Internal PaaS
I hosted a session on “Why/How to build an internal PaaS”. The reason for doing this is building a foundation for (micro-)services: Feature Teams should be able to easily deploy new services (time to market <1hour). They should not care about building their own infrastructure for: Deployment of appliations of different languages (PHP, Ruby, Java, Python, Go …), metrics, monitoring, databases, caches etcpp.
So I had a quick look, e.g. at flynn.io or deis.io, which pretend to do what I want, and I hoped someone actually using stuff like that might be right here.
The session itself was a bit clumsy: I guess I couldn’t explain my problem well enough, or it actually is no problem. Or the problem is too new as there was no one in the room who actually had more than 2 micro-services deployed.
But anyway, talking about what I want to achieve actually helped me to shape my thoughts.
Microservices - What is important for Ops
- Session hosted by MBS
- If a company wants to migrate to / implement microservices, an Ops team should insist on 12-factor-app style in order to have a standardization
- Have a look at Simian Army which has been implemented to mitigate common bad practices in microservice architecture, e. g. make everyone aware of fallacies of distributed computing.
- Not really for Ops, but for devs:
- EBI / Hexagonal programming style from beginning on, so it doesnt matter (in theory) if monolithic or service-oriented. In theory easy to switch
- Jeff Bezos Rules
- Generally having a look at Domain Driven Design and orienting (e. g. using repository and entities instead of ActiveRecord)
All the videos
Other Recaps
Like what you read?
You can hire me or make a donation via PayPal!