So here are some interesting links with some commentary about programming languages for distributed systems, cellular architecture, and advisory process for teams.
Programming the cloud ought to be delightful
The article could be summed up with:
-
Microservices can get complicated
-
Managing infrastrure is painful and different from programming the domain
-
Programming languages have a lot of tooling that we can’t use for infrastructure work in a cohesive way
-
Ideally, it would be nicer if we could:
- Deploy with a function call
- Service calls are one line of code
- Storage is typed too
What happened is that they implemented this ideal into something that you can test, now and for free.
Many concerns come to mind when considering using this in a “real-life project”
- Where is it actually deployed and how?
- How to implement metrics and logs that one wants? I can kind of guess this, but I wonder if this is part of the language
- How to deal with errors?
I am sure a lot o can be answered by playing around with it Still, I might try it out and see what I can learn from it.
Slack’s Migration to a Cellular Architecture - Cooper Bethea
It can be interesting to read these types of write ups. This post goes over:
- Detecting failures in distributed systems is a hard problem. Some examples.
- Interesting link to a paper on grey failures, meaning a subtle underlying fault. The paper is called: Gray Failure: The Achilles’ Heel of Cloud-Scale Systems Link to paper and how these types of errors generally result in poor performance and other types of inefficacies.
- Due to these pervasive grey failures, they decided to make some changes in the architecture.
- The post includes some details about the changes to infrastructure.
There were mentions of follow up posts that I didn’t find. I look forward to the next post where the author maybe will describe how they came to these decisions and what alternatives they considered. If you do read the post, you might find some of the images included are a bit blurry, making them hard to read.
Edit: I didn’t know what cellular architecture was. My initial reading tells me it’s a way to contain failure by having partial or full copies of software systems (cloud providers probably love this 💸). Link to aws article on how to implement cell based architecture
Scaling the Practice of Architecture, Conversationally - Andrew Harmel-Law
A blog post I keep coming back to, either to read or share. At it’s core it explains why top-down decision making doesn’t work and what you can get when you work collaboratively. And it’s so well written (yes I am envious!)
The premise is that everyone can make decisions as long as they consult with those affected by that decision and people with experience in that area. There are four activities that support this premise: Decision Records to document decisions, an Architecture Advisory Forum for conversations, Team-sourced Architectural Principles to provide guidance, and a Technology Radar to understand the landscape. Are they all totally suitable to you right now? It depends 😀. It does give you some strong foundations to try for something that works in your teams and organisations.
The article goes over how this affects teams, changes to the role of the architect, how this approach works with the company strategy and how to make it happen. The cherry at the top is an example. At the very worst it will make you think and there are some great external links.
Resources for later in the week
-
An Introduction to Residuality Theory by Barry M O’Reilly I watched this and I really enjoyed it, I am compiling notes about it, so this is comming on the next post.
-
Being a PM at Microsoft: Thriving in ambiguity I watched the video associated with this and liked it, so this is for the future too