VSHN.timer #197: Very Large-Scale Deployments

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about how some systems have to dramatically scale to serve millions of users with an acceptable quality of service.

1. The Slack team has migrated the most critical user-facing services from a monolithic to a cell-based architecture over the last 1.5 years. But what is a „cell-based architecture“, and how does it work?

https://slack.engineering/slacks-migration-to-a-cellular-architecture/

2. The Red Hat team has run tests to find out the maximum number of pods per node that can be run on OpenShift 4.13 clusters with equal or better performance, and the answer is 2500.

https://cloud.redhat.com/blog/running-2500-pods-per-node-on-ocp-4.13

3. AWS S3 is the original object storage service with an HTTP REST API. It consists of a frontend with a REST API, a namespace service, a storage system full of hard disks, and many background operations. Andy Warfield, VP and distinguished engineer at S3, explains how AWS designed S3 for massive scalability.

https://www.allthingsdistributed.com/2023/07/building-and-operating-a-pretty-big-storage-system.html

4. Mainframe computers are often seen as ancient machines—practically dinosaurs. But mainframes, which are purpose-built to process enormous amounts of data, are still extremely relevant today. But how do they work, and who uses them? ArsTechnica reports.

https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/

5. Red Planet Labs just built a Twitter-scale Mastodon instance from scratch in only 10k lines of code, which they will soon open source, and it offers unprecedented scalability. Check it out.

https://blog.redplanetlabs.com/2023/08/15/how-we-reduced-the-cost-of-building-twitter-at-twitter-scale-by-100x/

Are your systems designed for scalability? Have you ever programmed mainframe applications? Would you like to share some scalability tips and tricks with our readers? Get in touch with us, and see you next week for another edition of VSHN.timer.

PS: check out our previous VSHN.timer editions about Quality Assurance, SLAs & SREs: #6, #34, #43, #66, #104, #136, and #162.

PS²: do you prefer reading VSHN.timer in your favorite RSS reader? Subscribe to this feed.

PS³: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.