Scale Snapshots: A Week of Cloud, Data, and Infrastructure Numbers

Amazon's playbook has long been to internalize a problem, build a tool to solve it, and then turn that tool into a product. Walking through a fulfillment center, you can see the whole ecosystem at work: Outpost, machine learning, IoT devices, all being dogfooded internally before being packaged for external customers. It's a model that turns operational necessity into revenue generation.

Big Numbers, Bigger Implications

The past week brought a flurry of data points that put the scale of modern infrastructure in perspective. From bandwidth bills and processor efficiency to new words for extremely large data sets, these are the metrics that matter for anyone building at scale.

Network economics can be surprising. Zoom, with its monthly traffic of 217,000 terabytes, reportedly sees dramatically different bills depending on the cloud provider. The same volume of data movement that would reportedly cost $11,186,406.55 per month on AWS would be billed at $1,843,630 on Oracle Cloud. It's a reminder that at massive scale, egress costs are not just a line item— they're a primary architectural consideration and a powerful negotiating lever.

Adiabatic superconductor microprocessors aren't just a conceptual curiosity. The first such working chip has been demonstrated, showing an 80x improvement in energy efficiency compared with the current state-of-the-art semiconductor devices. While still a long way from datacenter deployment, it's a signpost for where the physical limits of computing might move.

Even the Earth itself is a performance metric. The shortest day ever recorded was 1.4602 milliseconds shorter than the standard 24 hours, a small reminder that even our fundamental timekeeping has jitter. In more practical terms, Zoom has surpassed 300 million users, and Facebook Live handled 7.2 million peak simultaneous broadcast streams.

  • 58%: of a developer's time is spent figuring out code—not writing it, but understanding what's already there.
  • 7500: the number of nodes in a Kubernetes cluster described by OpenAI, "not for the fainthearted."
  • 10^15: queries per day served by Facebook's graph.
  • 2.5 petabytes: the estimated memory capacity of the human brain.
  • 50%: the reduction in Azure Active Directory CPU costs achieved by migrating to .NET Core 3.1.

Meanwhile, some very large numbers are in play at the enterprise level. Facebook closed out 2020 with $86 billion in revenue, while Apple's first quarter of 2021 pulled in $111.4 billion—a 21% jump, with international sales accounting for 64% of that revenue and double-digit growth in every product category. Apple now counts 1.65 billion installed devices, including over a billion iPhones.

Consumer data is also flowing at record rates. Netflix has crossed 200 million subscribers, generating $25 billion in annual revenue; it's now cash-flow-positive enough that it's stopped borrowing to fuel growth. DuckDuckGo handled 100+ million searches in a single day.

Storage, Compression, and Data Loss

The gulf between data generation and data storage remains vast. Fujifilm has demonstrated a magnetic storage tape that can hold 580 terabytes of data, one way to keep up with the deluge from photo and video capture. On the other hand, data can also get you into trouble if you don't watch the numbers carefully. Uber discovered they'd been defrauded out of $100 million, or two-thirds of their ad spend. Boeing agreed to pay $2.5 billion for a fraud conspiracy charge related to the 737 Max.

Smarter engineering can claw back costs in more benign ways, too. One team reported saving $11,500 simply by compressing messages by 30%—a reminder that tackling bandwidth proactively can have very direct financial payoffs.

And with so much data to store, we may need to update our SI prefixes. The proposed next step after exa-? Hella-, as in 10^27, presumably so we can soon talk about having a few hellabytes of data laying around.

The Complexity Tax: What Engineers Are Saying This Week

Every week brings a fresh crop of observations about how systems are built, and this cycle’s collection covers everything from the hidden costs of accidental complexity to the structural reasons why cloud migrations fail. A common thread runs through many of the remarks: the gap between what architects intend and what actually ships.

On Accidental Complexity

Dan Luu makes a pointed argument about the nature of complexity in real systems: “if we look at the future, the fraction of complexity that might be accidental is effectively unbounded.” He goes further, saying he has “never worked on a non-trivial problem that isn’t completely dominated by accidental complexity,” which renders the concept of essential complexity nearly meaningless on problems worth discussing.

Jessitron frames the same issue from a cost perspective: “Complexity in software is nonlinear. It goes up way, way faster than value.” An integrated architecture may look elegant in a diagram, but implementing it — and every subsequent modification — carries an ongoing ugliness tax.

One practitioner, ckiehl, reflects on lessons learned over six years: “Clever code isn’t usually good code. Clarity trumps all other concerns.” The same author notes that “designing scalable systems when you don’t need to makes you a bad engineer,” and that typified languages tend to win on teams with mixed experience levels.

Microservices: The Overcorrection

Several engineers shared cautionary tales about decomposition gone wrong. UseStrict describes an effort to modernize a monolithic customer billing application that ballooned into “20+ microservices, every DB technology imagineable,” plus a RabbitMQ message bus and heavy AWS orchestration. What should have been a targeted rewrite became “a multi-year ground-up effort” that was nowhere near production-ready when they left, burdened by “significant technical debt and code rot.”

Rather than scaling problems being the trigger for Kubernetes adoption, jacobr1 reports a different motivation: standardizing deployment patterns. “We migrated to k8s not because we needed better scaling… but because we kept inventing our own way to do rolling deploys or run scheduled jobs.” The move unified how containerized builds run locally versus in production and provided “a common set of patterns for managing deployed software.”

chubot offers a clarifying distinction: “scale has at least 2 different meanings.” Resource scaling doesn’t necessarily justify Kubernetes; workload diversity does.

Cloud Economics: The Pricing Problem

A recurring complaint is that cloud pricing models are so opaque that teams default to EC2 even when managed services would save money. bane reports that across the teams they’ve worked with, most cloud adoption stops at EC2 instances: “the difficulties in estimating pricing for those pieces” push teams toward what they can forecast. “Amazon is probably leaving billions on the table every year because nobody can figure out how to price things so their department can make their yearly budget requests.” One team abandoned SageMaker after seeing the pricing sheet, retreating to Jupyter and scikit-learn on EC2. Even cloud management tools, bane notes, mostly track instance costs rather than the full service catalog.

On the other side, ormkiqmike argues that managed services are a “complete game changer,” particularly for enterprises: “The amount of time/effort enterprises have to do keep their systems’ patched/updated, managed services are way cheaper.”

The Architecture of AWS’s Origins

A former Amazon engineer, @DanRose999, recounts the crisis-driven birth of AWS. In 2000, Amazon was “burning $1B/yr” on “expensive Sun servers” after the dot-com bubble burst. “Site stability was critical,” so the company spent heavily on the most reliable hardware, even though Sun’s proprietary stack was costly and sticky. The team spent a year ripping out Sun and replacing it with HP/Linux — work that @DanRose999 says “formed the foundation for AWS.”

Two insights from Jeff Bezos were foundational. First, the company had “all this excess server capacity for 46 weeks/year” due to retail seasonality — why not rent it out? Second, Bezos pushed to “decouple internal dependencies so teams could build without being gated by other teams,” and the architectural APIs needed for that loose coupling “became the API primitives for AWS.” Bezos framed it via the electric grid analogy: nobody builds a generator to open a shop in 1900, so why build a datacenter in 2000?

The crisis made the hard architectural shift palatable: “without this crisis, it’s unlikely the company would have made the hard decision to shift to a completely new architecture.” The author’s lesson: “Never let a good crisis go to waste!”

Google Cloud’s Missed Opportunity

Another former insider, @MohapatraHemant, argues that Google had everything in place by 2008 to lead cloud — and fumbled it. “We should’ve been the market leaders,” but the failure came down to “bad timing, worse productization, and worst GTM,” with a “common thread: engineering hubris.” A telco CxO once told them: “you folks just throw code over the fence.” The lessons distilled: “consumers buy products; enterprises buy platforms”; distribution advantages beat product and tech advantages; and companies that reach product-market fit then underinvest in sales and marketing risk staying niche or getting taken down.

The operational frustration shows up too. @Suhail says Google made them talk to sales over a single GCP VM during the holidays: “Which sales person will care about our account against their quota?” Meanwhile, rsdav offers a counterpoint after working across all three major clouds: “If you were to ask me which one I’d use for a net new project, it would be GCP — no question,” praising BigQuery in particular. @justinkan reports that startups hear plenty from AWS but not from Google Cloud, asking: “Does anyone at Google Cloud work on startups?”

ARM: Price-Performance Wins

Percona’s testing of PostgreSQL on ARM-based AWS EC2 instances found consistent results: “ARM-based instance is 25 percent cheaper, it is able to show a 15-20% performance gain in most of the tests over the corresponding x86 based instances.” The verdict was “conclusively better price-performance in all aspects.”

On the architecture side, @stuntpants argues that arm64 is essentially “the Apple ISA,” designed to serve Apple’s microarchitecture plans. Apple contracted ARM to design a new ISA over a decade ago, planning “to go super-wide with low clocks, highly OoO, highly speculative.” The M1’s performance isn’t a consequence of the ARM ISA; rather, “the ARM ISA is so because of Apple core performance plans a decade ago.”

PostgreSQL vs. MySQL, Old and New

Small Datum’s sysbench comparison of older and newer PostgreSQL and MySQL versions found a reversal: “old Postgres was slower than old MySQL while new Postgres is faster than new MySQL courtesy of CPU regressions in new MySQL.” The InnoDB clustered primary-key index helps some queries by avoiding extra random I/O for non-PK columns, but hurts others when the larger clustered index can’t be cached while a smaller Postgres index can.

Scaling Realities and Limits

Geoff Huston examines why IPv4 remains viable: NATs “are the reason why in excess of 20 billion connected devices can be squeezed into some 2 billion active IPv4 addresses.” NATs extend the address space by up to 32 extra bits and enable time-based address sharing, but “they do not transform the address space into an infinitely elastic resource.” The inevitable choice, Huston argues, is fragmentation of the IPv4 Internet or further IPv6 deployment.

jandrewrogers notes that data models have scaled dramatically: “Exabyte scale working data models have been something I’ve needed to consider in designs for at least a few years,” and “we are surprisingly close to overflowing 64-bit integers in real systems.”

On the human side of scaling, General John Murray worries about drone swarm defense: “a human may be required to make that first decision, but I am just not sure any human can keep up.” The question is how much human involvement is needed for “nonlethal decisions.”

Ranking Algorithms and Their Side Effects

An engineer who wrote Instagram’s feed algorithm claims Twitter’s ranking has a structural flaw: “Twitter needs to lower the click-probability weighting,” because content with thread icons dominates feeds. “You are infinitely more likely to ‘click’ on something that has a little thread 🧵 icon in it,” which feeds outrage and rubbernecking. The result is a “network effect where a small ranking change has a huge effect on online discourse.” The author concluded with self-awareness: “Look at me! I’m writing a thread right now and I hate them.”

GraphQL, Datasources, and Architectural Debates

Sam Newman clarifies his criticism of GraphQL-based services: “it’s an issue with direct coupling with underlying datasources,” not with GraphQL itself. @jevakallio takes a sardonic view of the hype, saying GraphQL lets you “mess about doing clever schema introspection metaprogramming all day long and get paid twice what a normal API programmer does because nobody else understands what is going on.”

@copyconstruc points out how the decade closed: “The 2010s began with the idea that scaling infinitely wasn’t possible with an RDBMS.” By 2020, options included “MySQL with Vitess, Postgres with CockroachDB, Aurora, and custom solutions like Cloud Spanner.”

qeternity reports hands-on experience running “HA Postgres setups on k8s” four years after such ideas were dismissed: “Local nvme access with elections backed using k8s primitives” works beautifully.

The Elephant in the Room

Pat Helland delivers a blunt verdict on terminology: “The word consistent is not consistent. I pretty much think it means nothing useful. Eventual consistency means nothing both now AND later. It does, however, confuse the heck out of a lot of people.”

Infrastructure and Politics

Anne Schilling lays out the hardware behind Parler — which earned attention as the service struggled to stay online: 40 instances with 64 vCPUs and 512 GB RAM, 70-100 machines with 768 GB RAM, plus several hundred smaller instances, moving 300-400 GB/min of internal traffic. Edward Snowden notes that WhatsApp’s sellout drove “probably the biggest digital migration to a more secure messenger we’ve ever seen,” straining Signal’s team.

The Pirate Bay’s resilience draws a contrast: started by kids and run by people with substance and money problems, it survived censorship pressure from the US, European, and Russian governments for almost two decades. Meanwhile Parler and Gab — “all the money around but no skills or mindset” — struggled despite political support.

Cory Doctorow puts the free software argument sharply: “Forty years ago, we had cake and asked for icing on top of it. Today, all we have left is the icing, and we’ve forgotten that the cake was ever there.”

Akin’s laws get quoted on two fronts: “Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective,” and “there’s no justification for designing something one bit ‘better’ than the requirements dictate.”

On the future of Moore’s Law, Charles Leiserson warns: “We can’t just leave it to the technologists to give us more performance every year. Moore’s Law made it so they didn’t have to worry about that so much, but the wheel is turning.” Neil Thompson notes that 3D integration’s near-term gains run into serious heat-dissipation problems, likely mirroring the diminishing returns seen with multicore processors.

The Week in Outages: Vaccine Sites, Slack, and the Stubborn Physics of Demand Spikes

Every scalability discussion eventually collides with a basic truth: systems fail when demand exceeds design assumptions. This week's stories offer a catalog of such failures, from public infrastructure to enterprise messaging platforms. Germany's NRW state launched its vaccination registration portal only to see it collapse under the weight of 700 requests per second. The problem isn't that the load was extraordinary — it's that the system was built as if such load would never arrive. Bavaria's online schooling platform mebis broke down similarly, despite the fact that the number of students and their usage times were known in advance. Kaiser Permanente left patients on hold for hours because their scheduling system could not handle the influx.

The unifying theme: capacity planning is not a technical afterthought. It is a matter of public health infrastructure when the system in question is a vaccine registration site. And in the corporate world, the same dynamics play out. Slack's January 4th outage traced back to an unusual-but-forecastable event: the post-holiday return to work. Traffic on that Monday spiked because client caches were cold, and users pulled down far more data than usual. The company explained that its architecture had evolved from a single AWS account into multiple VPCs connected by AWS Transit Gateways (TGWs). On that day, one of those TGWs became overloaded. The rush to provision new instances then hit two bottlenecks: the Linux open files limit and an AWS quota cap. The lesson Slack drew was practical — they set a reminder to request preemptive TGW upscaling at the end of the next holiday season.

Big Iron Makes a Comeback

While the world rushes to the cloud, Let's Encrypt demonstrated that sometimes the answer is still a very large, very expensive server. The certificate authority's new database box is a 2U machine with dual AMD EPYC 7542 processors (64 cores, 128 threads), 2TB of RAM, and 24x 6.4TB Intel P4610 NVMe SSDs. The result was dramatic: median API request time fell from ~90ms to ~9ms. CPU utilization dropped from 90% to about 25%, and average query response time improved threefold, from ~0.45ms to ~0.15ms.

The cost? The company didn't disclose it, but Dell's site prices such a machine around the $200k mark, though commenters on Hacker News suggested the real-world price would be significantly lower. A historical comparison: a 64-processor Sun Starfire with 256GB of RAM, circa 2000, cost well over a million dollars, consumed an entire rack's worth of space, and ran processors at a glacial 250-650MHz.

A more productive way to think about it: can a single machine, with 153,600GB of raw storage and the bandwidth of 24 NVMe drives, outperform a distributed cluster for certain workloads? As one commenter observed, a single modern server with PCIe 4.0 can achieve ridiculous throughput — millions of IOPS and data scans at over 100GB/s. You may need clusters for resiliency, but raw throughput is no longer a reason to distribute.

Rethinking the Database Monolith

Chess.com's story is a masterclass in practical database scaling. The site grew from under 1 million unique daily users a year ago to over 4 million today, with more than 8 million games played each day. Their MySQL fleet handles over 7 billion queries daily, backed by 20-25TB of data across 60-80 billion records.

The existential threat was ALTER TABLE. Growing features meant constant schema changes, and each alter required taking half the hosts out of rotation, running the change, and swapping them back — only during off-peak hours. The solution wasn't a new database. It was moving writes off the main cluster. They spent one week moving logs to a dedicated database, one month moving games, and over two months migrating puzzles. The result brought them comfortably under 80% of replication capacity at peak.

Their other trick: move logic out of the database. Sorting, merging, and filtering now happens in application code. Two separate queries with perfect indexes are faster than one query with a join. No foreign keys means faster inserts and updates. The database is still MySQL — but it's now a database doing only what a database should.

A Serverless Reality Check

The serverless dream often curdles into a different kind of complexity. One developer described moving a serverless project back to Ruby on Rails: "When the building blocks are too simple, the complexity moves into the interaction between the blocks." The flow of a Lambda publishing to SNS, another picking it up, writing to DynamoDB, and a third sending an email — the interactions happen outside the application, invisible and hard to reason about.

The critique extends to observability. As one commentator argued, serverless applications are "hyperobjects" — you can't visualize the system because the architecture is implicit, scattered across event buses and queues. The developer's verdict on serverless: "It promised exciting adventures, but gravity sucked me in and I spent most of my efforts dealing with its complexity, instead of focusing on my product."

What Actually Makes the Web Slow

A study that rendered a million web pages yielded a surprisingly simple conclusion: the number of requests matters more than the number of kilobytes. Fewer, larger requests beat many small ones. Use HTTP/2 or better where possible, and avoid render-blocking requests — prefer async loading. This finding aligns with the longer-standing obsession with connections: one team reported reducing database connections from 15,000 to under 100 by introducing a proxy that polls on behalf of servers and funneling event publishing through an API instead of direct inserts.

ML Applied to Your Own Infrastructure

Dropbox uses machine learning to save a reported $1.7 million annually on document previews. The insight: much pre-generated content was never viewed. They built a prediction pipeline that fetches file-specific signals and feeds them into a model that predicts whether a preview will be used. Pre-warming only those files they're confident will be viewed replaced an estimated $1.7 million in compute costs with $9,000 in ML infrastructure per year.

Skeptics question the math. Working in an innovation ML lab, one engineer noted, "we have a hard time identifying use cases with real added values." Another dismissed the savings as insufficient to justify a maintenance team. And Datto's attempt to predict hard drive failures with ML was less successful. The takeaway: ML is promising for infrastructure optimization, but use cases are neither obvious nor universally applicable.

Rust in the Trenches

1Password's production Rust experience, shared this week, reads as a tempered endorsement. Memory safety — the original draw — remains a core benefit, particularly for a company entrusted with customers' secrets. The absence of a runtime and garbage collector yields performance gains. Strong type rules make APIs difficult to misuse; the compiler catches invalid paths before execution. An often-overlooked feature, the procedural macro system, enables sharing types between Rust and client-side languages like Swift, Kotlin, and TypeScript.

The one disappointment? WebAssembly. The team had hoped to leverage Rust-to-WASM compilation more extensively in their browser extension. "It did fall short for us in one key area," they acknowledged, without elaborating on specifics.

Cache Management, Push Architecture, and Other Tactics

For aging cache implementations, the CLOCK algorithm replaced LRU in OpenLDAP's backend back in 2006. Where LRU pops pages out and tacks them onto a list — requiring locks — CLOCK uses a circularly linked list with a clock-hand pointer and a Referenced flag per entry. This reduces locking overhead substantially in multi-threaded environments.

Uber's real-time push platform deserves attention for scale alone: over 1.5 million concurrent connections and more than 250,000 messages per second. Their architecture moved from 80% polling to a push model using TCP-based persistent connections. Message delivery follows increments sequence numbers over an SSE connection — if message seq#3 isn't delivered, the connection has failed. The stack includes Netty, ZooKeeper, Helix, Redis, and Cassandra. Their next-generation protocol will be built on gRPC.

OkCupid's GraphQL migration offered a warning about measurement methodology. They implemented a "Shadow Request" — loading page data from REST as normal, then loading the same data from GraphQL in the background, measuring, and discarding. The first release was twice as slow (1200ms versus 600ms), but the root cause wasn't GraphQL itself: it was a build accidentally set with NODE_ENV to development, an unoptimized Docker base image, the overhead of serving from a separate API origin, and an un-batched user endpoint. Fix each and the gap narrowed, then vanished.

Management Wisdom, Distributed

Supercell's Ilkka Paananen distilled company culture into a few principles: small independent teams (cells) operating as startups within the larger company; a hiring bar that asks whether the new person raises the company's average quality; the decision to let teams decide whether to kill or release their own games. The rationale for the latter echoes Conway's Law — shifting responsibility to the team increases its sense of ownership. Only one in ten games makes it out; celebrating the learnings from failure is part of the culture.

GitHub's deployment improvements highlight the value of a good UI. Previously, deploys were tracked across multiple Slack messages — hard to piece together. Their new system uses a state machine with two canary stages: 2% of traffic for the majority of issues, and a second stage at 20%. One surprising practice: code is canary deployed to production before the PR is merged. As an engineer explained, this allows for extraordinarily fast rollback — reverting and undeploying is quicker than opening, reviewing, and approving a revert branch.

A 45-year veteran of the software industry distilled his lessons: Beware the Curse of Knowledge. Smart people comfortable with complexity are especially prone to assuming others see what they see. Focus on fundamentals — teamwork, trust, communication, consensus, automated testing, and clean design. Simplicity. Seek first to understand. Beware lock-in. And honest acknowledgment when you don't fit a role.

Quote of the week: "If you can't audit and verify the contents of a package, you are mass distributing a weapon, not a product." — a comment on the SolarWinds build process compromise. The argument: build servers should only build changes approved against a change request ID; every line of code should be reviewed by multiple sets of eyes from different groups; and images should be verified against a manifest of intended contents before distribution. A digital signature alone says nothing about what's inside.

Edge Caches, Serverless Memory, and Streaming Data-Flow

Several new projects tackle the cost and performance problems of distributed storage and caching from unconventional angles. mit-pdos/noria is a streaming data-flow system from OSDI'18 that acts as a fast storage backend for read-heavy web applications. It behaves like a database but precomputes and caches relational query results, keeping those cached results up to date as underlying persistent base tables change. Noria relies on partially-stateful data-flow to limit memory overhead while supporting dynamic runtime data-flow and query changes.

InfiniCache takes a different approach by building an in-memory object caching system entirely on ephemeral serverless functions. Presented at FAST'20, the system exploits and orchestrates serverless functions' memory to deliver elastic, pay-per-use caching. Its design combines erasure coding, intelligent billed duration control, and an efficient data backup mechanism to balance availability, cost, and the risk of losing cached state. An AWS Lambda implementation achieved tenant-side cost savings of 31–96x versus ElastiCache for a large-object production workload, delivered 95.4 percent data availability per one-hour window, and produced performance comparable to a typical in-memory cache.

Twitter's in-memory cache infrastructure also came under scrutiny in a large-scale OSDI'20 analysis of hundreds of clusters. The study characterized workloads across traffic patterns, TTL, popularity, and size distributions, revealing more write-heavy and skewed use cases than previously reported, plus unusual temporal patterns. TTL proved an important and sometimes defining parameter of working sets. Simulations of ideal replacement policies had surprising results: FIFO was the best choice for a large number of workloads.

Consistency and Replication at Scale

Facebook contributed FlightTracker to OSDI'20, a family of APIs and systems that manage consistency for online access to its graph. FlightTracker implicitly provides read-your-writes guarantees and can be explicitly configured for alternative consistency levels in special use cases. It enables flexible communication patterns between caches, extends consistency guarantees to cross-shard indexes and materialized views, and offers a uniform client primitive across multiple data stores. All of this arrives while preserving the efficiency, latency, and availability benefits of asynchronous replication, handling billions of users and more than 10^15 queries per day.

On the replication protocol side, Compartmentalized Paxos proposes decoupling individual bottlenecks into distinct components that can scale independently. The approach increased MultiPaxos throughput by 6x on a write-only workload and 16x on a mixed read-write workload without specialized hardware. Because it is a technique rather than a protocol, practitioners can apply compartmentalization incrementally to their existing protocols.

Rethinking Distributed Databases

AnyDB challenges the assumption that a distributed DBMS must pick a single architecture. Instead of baking in a shared-nothing or other fixed model, the proposed architecture-less DBMS mimics any architecture on a per-query basis on the fly, without reconfiguration overhead. Initial results show significant speed-ups across varying workloads compared to a traditional DBMS locked into a static architecture.

For storage engines, bytedance/terarkdb positions itself as a RocksDB replacement that improves tail latency, throughput, and compression. Developers can usually migrate an existing RocksDB instance to TerarkDB without drawbacks. The ballista-compute/ballista project is a proof-of-concept distributed compute platform written primarily in Rust and powered by Apache Arrow. Its architecture lets other languages such as Python, C++, and Java participate as first-class citizens without serialization overhead penalties.

Systems Performance and Decision-Making References

Two major reference works appeared recently. Systems Performance: Enterprise and the Cloud (2nd edition, 2020) adds coverage of BPF, BCC, bpftrace, perf, and Ftrace, removes most Solaris content, and brings Linux and cloud computing material current. The author wrote it after six years as a senior performance engineer at Netflix. Algorithms for Decision Making offers a broad introduction to decision making under uncertainty, covering problem formulations and solution algorithms. Readers noted the book's linear programming formulation for optimal value functions is underrated by the CS community, though control theory also offers simple, robust methods for state-to-state problems when online learning is not required.

Cloud Gaming and Event-Driven Traffic Patterns

A network analysis of three cloud gaming services—Google Stadia, NVIDIA GeForce Now, and Sony PS Now—collected more than 200 packet traces under various settings and network conditions. GeForce Now and Stadia use the RTP protocol for multimedia streaming, with Stadia relying on standard WebRTC APIs; both are bandwidth-hungry, consuming up to 45 Mbit/s depending on network and quality. PS Now uses only undocumented protocols and never exceeds 13 Mbit/s.

The case for event-driven architecture continues to build. Proponents argue that the real-time effect will drive adoption, particularly when interfaces and protocols for connecting to real-time event data streams become as standardized and simple to use as HTTP.

Mobile, Telecom, and UAV-Supported Networks

SkyCore moves the Evolved Packet Core to the edge to support untethered and reliable operation of multi-UAV LTE networks. The SDN-based edge-EPC architecture also applies to future RAN technologies like 5G and 6G. Even in terrestrial networks where EPC-RAN communication is reliable, operators can push EPC functionality to edge clouds or cell towers to achieve the ultralow latency that 5G use cases demand.

Outside the datacenter, the tech industry is entering its second 50 years with a broader geographic and regulatory footprint. China now has more smartphone users than Europe and the United States combined, with India close behind. The trends Covid accelerated—$20 trillion in retail, brands, TV, and advertising being overturned, and software remaking industries from cars to pharma—point to technology becoming a regulated industry.