Roads Full of Compute, Not Cars Full of Sensors

Instead of turning every car into a rolling sensor-studded supercomputer, roads could be lined with stationary edge command and control pods. These pods would offload computing, sensing, and traffic management duties. Cars, in this model, become mostly remote-controlled pleasure palaces, addressing concerns around compute capacity, latency, and interoperability.

Number Stuff

  • 204 billion: app downloads in 2019, up 6% since 2018 and 45% since 2016. Consumer spending hit $120 billion, a 2.1x increase from 2016. Growth is driven by emerging markets like India, Brazil, and Indonesia.
  • $100 billion: projected mobile game spending in 2020. Arcade and puzzle games lead global downloads.
  • 82%: remote workers who have no plans to return to an in-office setting.
  • 579: active Facebook open source repositories, with 170 new ones added in 2019 and 82,000 commits total.
  • .5%: IPv4 allocation growth rate, less than one-tenth the rate seen in 2010.
  • 44%: faster growth in UK tech investment compared to the US and China in 2019.
  • 100 million: daily phishing attacks blocked by Google. Interestingly, being in a bad mood makes you less likely to fall for an attack.
  • 2.8 billion: people using a Facebook property. The company operates 11 datacenters in the US, 3 in Europe, and 1 in Asia. Full-stack optimization lets these facilities use 38% less electricity and 80% less water than average.
  • 15%: the share of Basecamp’s operations budget spent on Ruby/Rails application servers.
  • 2.5%: projected global economic growth for 2020, with 1.4% in advanced economies and 4.1% in developing ones.

The Week in Quotes: Cloud Economics, Clock Speeds, and the Cost of “Best”

Each week brings a fresh batch of commentary on the state of infrastructure, software, and the industry at large. This edition covers everything from the economics of cloud and NoSQL to the physics of CPU clocks and the future of internet interfaces.

Cloud Efficiency and the Jevons Paradox

James Hamilton's take on cloud computing offers a counterpoint to the idea that operator efficiency necessarily reduces total compute. He argues that if cloud providers vanished, workloads wouldn’t disappear. The primary constraint on new IT workloads isn't cost but complexity and skills. “If machine learning, as just one workload example, keeps getting easier (it will), then computing usage will continue to go up rapidly,” he notes, adding that increased computing is often better for the environment.

Data from Salesforce’s early years, shared by @chetanp, provides a concrete example of the economics involved. The company’s cumulative cash burn to its 2004 IPO was just $30M, with revenue scaling dramatically alongside free cash flow in the run-up to going public, suggesting SaaS scaling can be cash efficient.

The Speed Plateau and the Real Cost of Building

@slava_pestov highlights a seismic shift in hardware expectations. While typical CPU clock rates hit a wall at 2.8 GHz in 2002 and remain there today, the last 18 years have been defined by architectural advancements rather than raw speed. The days of the “megahertz wars,” it seems, are truly over.

A cautionary thread on DIY software economics comes from @brandonsavage. Building a tool that seems like a simple $200/mo SaaS can quickly become the most expensive solution ever: “It takes a $100,000/yr engineer 3 months to build... You saved $2400 but spent $28,846 building it yourself.” The same cost-conscious logic applies to database choices. @Jessitron warns against the “drop-in replacement fallacy,” advising teams to consider if they have the internal skills, drivers, and operational tools to support a “high-scale” solution like Mongo before adopting it.

Reconsidering NoSQL and Serverless Semantics

The conversation around NoSQL continues to evolve. While @sogrady notes that the term’s usage appears to be in decline, the underlying architectural principles remain central to scaling discussions. Rick Houlihan argues that those who successfully scale NoSQL databases learn that “NoSQL is about simple queries that facilitate CPU conservation so performance is driven by proper denormalized data modeling.” He suggests that debates should shift from API features to operational characteristics, which is where born-in-the-cloud services like DynamoDB can excel.

The semantics of modern service names also drew fire from @OldManKris: “'Serverless' means you have servers, but can’t configure/customize them. 'No-code' means there is code, but you can’t change it. 'NoSQL' means you have to learn a new query language and implement your own transaction mechanisms.”

Decoding the BGP and Hardware Frontiers

Geoff Huston’s analysis of BGP activity suggests that while updates are growing in both IPv4 and IPv6, they are growing more slowly than the number of routed prefixes. This points to a network that is increasing in density but holding a constant diameter, leading to stable convergence times in IPv4 and a bounded upper limit in IPv6.

On the storage side, Micron’s new 16Gb DDR5 DRAM chip promises significant architectural gains. It supports the same DIMM density with half as many chips as an 8Gb part, reducing power and processor load, while claiming an 85% memory performance increase over its DDR4 counterpart. Further out, UK scientists have reportedly developed “UK III-V,” a universal memory technology that would use roughly 1 percent the power of current DRAM, though density considerations currently make it a more suitable DRAM replacement than a NAND flash rival.

Bert Hubert points to a massive trend in the telecom industry: vendors like Huawei are not just selling equipment but also deploying, configuring, and maintaining it, with direct operational control over infrastructure for over 100 million European subscribers. On the user side, @GeeWengel offers a warning about observability costs, recounting a configuration mistake in Azure Application Insights that resulted in a bill for “several thousand dollars” over the Christmas vacation.

Graviton2 and the ARM Server Moment

James Hamilton argues that AWS's Graviton2 may finally be the first high-volume ARM server. The chip packs over 30 billion transistors into a 7nm process, with 64KB instruction and data caches plus 1MB of L2 cache per core. Each vCPU is a full non-shared core rather than an SMT thread, and the design includes dual SIMD pipelines per core with ML-optimized int8 and fp16 support. A fully cache-coherent L1 and a 2TB/s full-mesh fabric connect the parts, while 100% encrypted DRAM sits behind eight channels at 3200 MHz.

The significance is less about the specs and more about timing: ARM servers have long been described as inevitable, but this chip is in customers' hands at meaningful scale.

Cloud Strategy as a Discipline

Trek10's "Ten Commandments for Cloud Decision-Makers" is a useful checklist for executives who treat cloud adoption as a purely technical migration. The list is blunt about common failure modes: pretending cloud is only an engineering problem, skipping training, choosing tools from familiarity bias, and solving fake problems. The counter-prescription is to measure cloud as a value center, trust partners, optimize for engineering time, and build momentum by demonstrating value early.

Reddit's Infrastructure AMA

Reddit's infrastructure team took questions and offered a detailed look at their stack. Search runs on Solr with Lucidworks Fusion on top, deployed as self-managed clusters in EC2, with internal APIs and async pipelines for real-time indexing. The team uses both Postgres and Cassandra, frequently putting memcached in front of Postgres.

Cost management gets serious attention. The team invested heavily in consistent cost-allocation tagging across a long-lived infrastructure, aggressively manages reserved instances, and ranks cost impact as compute > memory > network > storage. Engineering teams receive cost tags for their own services, though the team hasn't gone heavy on enforcement because RI and CDN savings apply broadly anyway.

On the monitoring side, metrics flow to Wavefront through three paths: a Diamond sidecar for system metrics, custom collectors and scripts for third-party tools, and statsd-based instrumentation libraries that all services use for request and response metrics. Sentry handles error tracking, and postmortems are blameless. One notable incident involved RabbitMQ running out of file descriptors, crashing, and returning with corrupted data, disrupting both async processing and some in-request message publishing.

Infrastructure is predominantly AWS, with Terraform for provisioning and Puppet in non-Kubernetes environments. All new services deploy to k8s, and the team runs its own clusters on EC2 rather than using EKS. Deployments use Drone for CI and Spinnaker for k8s, with an in-house tool called Rollingpin for non-k8s deployments. Databases remain self-managed or on RDS; the team hasn't tried stateful services in k8s. Auto-scaling relies on CloudWatch alarms and custom tooling, typically targeting the p50 CPU statistic. Capacity mix is mostly reserved instances, some on-demand, and very little spot.

Notable AWS features: Cost Explorer, CloudTrail, Config, and the Personal Health Dashboard all get praise for different operational needs.

Frameworks, the Edge, and Scaling on the Web

Scaling React server-side rendering turned out to be less about React-specific tuning and more about general architecture. A technical deep-dive on the topic lays out a progression of improvements that compound to a 1288x capacity gain, starting with dependency upgrades (Node 4/React 15 to Node 8/React 16 yielded about 2.3x), then load-balancing strategy (round-robin over random bought roughly 1.4x headroom), and a client-side rendering fallback providing an 8x emergency escape hatch. Isomorphic rendering for whole pages, with server-side rendering only the first page per session, gave another 5x for typical five-page sessions. Component caching in low-risk areas added 1.4x, and aggressive caching of most components delivered 10x or more at higher risk.

A separate piece on serverless tradeoffs observes that serverless offers little over traditional deployment for steady-state scaling. The real issues surface in control and operational fit: an Azure Functions evaluation found documentation gaps, configurable event hub options not exposed by the runtime, a different architectural skill set, and complications for cache-heavy designs since functions can be recycled without warning.

Networking, Storage, and the Future of IO

Scientific computing has shifted its bottleneck from FLOPS to IOPS. A plasma simulation can generate a single frame over 50 TB for one timestep; a two-photon mouse brain imaging run produces up to 100 GB per hour, and electrocorticography records at 280 GB per hour. One response is the Intel Distributed Asynchronous Object Storage (DAOS) project, which moves off block-based POSIX file systems toward transactional object stores. DAOS organizes data into containers supporting different schemata (filesystem, key/value, database table, array, graph) with metadata for access patterns, redundancy (replication or erasure code), and striping policy.

From a storage economics perspective, a Library of Congress meeting summary notes that tape's areal density limits are not the physics constraint they are for HDD; tape bit cells are 60x larger, and 2025 projections for tape density have already been demonstrated in labs. The summary sees tape as strategic in public and hybrid clouds, and flags a twelve-year-old technique for verification -- the data owner sends a nonce and the provider must compute a hash of the nonce plus data -- as still missing from cloud APIs.

Odd Ends

Sonos announced it will stop updating legacy products in May, prompting real anger. The complicated part: newer gear that connects to older gear would need to keep speaking old protocols, which is a development and testing burden. The deeper critique is about identity and support lifecycles -- when does a product stop being what it was? Both sides have a defensible view, but the brand cost of cutting off customers who invested heavily can outweigh the engineering savings.

A thread on Etsy's early architecture -- PHP against Postgres, later a catastrophic Python rewrite attempt advised by a Twisted consultant -- drew sharp commentary that most of those mistakes happen when engineering management is absent or inexperienced: solving problems with rewrites in different languages, rewriting open-source software before using it, consultants confirming decisions, no one in charge, and competing internal initiatives.

Finally, a caution against full decentralization comes from a DDoS mitigation story where the only effective solution was re-inserting a global intermediary (Cloudflare) and blocking Tor exit nodes. The takeaway: decentralized systems must still account for spammy bad actors.

Open-Source Finds

fabiolb/fabio is positioned as a fast, modern, and zero-configuration load balancing router for HTTP(S) and TCP traffic, specifically designed to route to applications managed by Consul.

For those working at the edge, Nexenta/edgefs offers a high-performance, low-latency data fabric with a small memory footprint. Released under the Apache License v2.0 and developed in C/Go, it is built around decentralized immutable metadata consistency. This design allows it to sustain network partitioning for extended periods—up to many days—while still providing a consistent global namespace through a unique version reconciliation technique.

Research Highlights

Reconfigurable Architecture for Parallel Patterns

A paper on Plasticine introduces a spatially reconfigurable architecture aimed at efficiently executing applications composed of parallel patterns. These patterns, which have emerged from recent research, serve as high-level abstractions that capture data locality, memory access patterns, and parallelism across dense and sparse applications. According to the paper, cycle-accurate simulations show Plasticine delivering up to a 76.9× improvement in performance-per-Watt over a conventional FPGA across a wide range of these applications.

Buffer Sizing via Control Theory

Another paper, Control Theory for Buffer Sizing, explores using control theory to determine appropriate buffer sizes for core Internet routers. The theory predicts whether the network is stable—specifically, whether TCP flows are desynchronized. If they are, small buffers suffice; the research posits that small buffers actually encourage this desynchronization, creating a virtuous circle.

Fine-Grained Clock Synchronization

Presented in Exploiting a Natural Network Effect for Scalable, Fine-grained Clock Synchronization, the HUYGENS software system leverages a synchronization network with three core ideas. First, it uses coded probes to identify and reject impure data affected by queuing delays, jitter, or NIC timestamp noise. Second, it applies Support Vector Machines to estimate one-way propagation times, achieving clock synchronization within 100 nanoseconds. Finally, it exploits the transitive property of synchronized clocks—a natural network effect—to further detect and correct errors. The system attains synchronization within a few tens of nanoseconds under varying loads, with negligible overhead on link bandwidth.

Historical Perspective on NTDS

A historical account, The Story of the Naval Tactical Data System, details resistance from prospective commanding officers of guided missile frigates in 1962. Uncomfortable with automation, they vowed that "no damned computer" would tell them what to do or fire their nuclear-tipped missiles, planning to take their ships to sea with the new system turned off.

Predicting Serverless Workflow Costs

Moving away from guesswork, a proposal for Predicting the Costs of Serverless Workflows outlines a methodology combining input-parameter-sensitive function models with a Monte-Carlo simulation of an abstract workflow model. This allows designers to predict, compare, and optimize expected costs and performance without time-intensive experiments. The evaluation shows the approach predicting response times and output parameters with 96.1% accuracy, and in a case study with two audio-processing workflows, it achieved a 96.2% accuracy in cost prediction.