Issue #114
Container publishing system, notes on Paxos, how NATS came to be, Dependency confusion ...
Truth is ever to be found in simplicity, and not in the multiplicity and confusion of things.
— Isaac Newton
Posts
Staying safe with .NET containers
How container image publishing system works - #microsoft #devblogs
Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies
When downloading and using a package from any of these sources, you are essentially trusting its publisher to run code on your machine. So can this blind trust be exploited by malicious actors? - #medium #alex.birsan
How Are Award-winning Systems Research Artifacts Prepared (Part 1)
Manuel Rigger from ETH Zurich will tell us about how he prepared his award-winning artifacts at OSDI’20 and OOPSLA’20. Manuel generously shared his OSDI’20 AE review. - #sigops
There’s a famous result called FLP impossibility: Impossibility of Distributed Consensus with One Faulty Process. But we’ve just presented Paxos algorithm, which works as long as more than half of the processes are alive. What gives? FLP theorem states that there’s no consensus algorithm with finite behaviors. Stated in a positive way, any asynchronous distributed consensus algorithm is prone to live-lock. This is indeed the case for Paxos. - #matklad #github
Service Fabric and Kubernetes: community comparison, part 1 – Distributed Systems Architecture
I would like to share some of what I have learned when adopting Service Fabric and try to compare it with the currently most popular container orchestrator, Kubernetes, which runs numerous different distributed applications today. - #microsoft #docs
Analytical Model for Capacity and Degradation in Distributed Systems
cost planning — where over-provisioning is useful, where it is not, and the return on investment from over-provisioning.
pipeline degradation — by externally measurable parameters to gauge the health of a pipeline and its relationship with the Service Level Agreement (SLA) - #salesforce #engineering
Distributed Systems & team size
I normally prefer teams of 3 to 6 developers. I like to have contact with developers once a week at least. The more attention I can pay each person, the better I can learn their strengths and weaknesses. Larger than 5 developers and I start having to partition work and my ability to cycle through the whole team starts to lag. Beyond 10 developers and I have to essentially create two teams. - #medium #shawn-hartsock
The Log: What every software engineer should know about real-time data's unifying abstraction
You can't fully understand databases, NoSQL stores, key value stores, replication, paxos, hadoop, version control, or almost any software system without understanding logs; and yet, most software engineers are not familiar with them. I'd like to change that. - #linkedin #engineering
Podcasts
NATS with founder Derek Collison
-What was the idea behind NATS & where it came from
-The technical choice to use Go & broker based system design
-Simplicity as a feature
-Security
-Liftbridge
-Running a popular open source project as a company
-Jetstream & what the future holds for NATS
A Discussion with Clare Liguori from AWS Container Services
Clare Liguori, Principal Software Engineer for AWS Container Services, discusses the influence of DevOps and GitOps on the container space, why migrating your app to containers also improves observability, and how Chaos Engineering has become even more important.
Books
Beej's Guide to Network Programming
Videos
Anna: A KVS for Any Scale (Chenggang Wu, UC Berkeley)