Runtimes, infrastructure, and APIs tend to get more granular. Maybe we're just in the unbundling phase (implying a future bundling phase), or maybe it's a byproduct of moving functionality to the edge (the network is the bottleneck),  or perhaps this is just a general form of progress (breaking things down into abstractions).

At a basic level, granularity lets us bin-pack workloads. Different workloads have varying levels of safety when it comes to resource sharing and allocation. Isolation happens at the operating system level (virtual machines), process level (containers), and thread level (v8 isolates). Hardware security module (HSM) workloads and edge functions need different security guarantees.

But it's also changed the way that we write code. Virtual machine managers might be smart enough to overcommit memory, but it's difficult to have the granular knowledge to know when it's safe to preempt. Doing it at the process level (containers) can make it easier to handle interrupts and restarts. Once compute gets granular enough, it might not even matter.

Fault-tolerant infrastructure creates less error handling code at the application level. Noisy neighbor applications that misbehave and suck up CPU and RAM might crash other processes. If you deploy on something like AWS Lambda, the process will still crash, but you can limit the blast radius.

Smaller APIs are often easier to integrate into existing infrastructure. For example, carved-out authentication or authorization APIs are much easier to add to your application than Active Directory (in theory).

Granularity won't solve everything (there's no silver bullet). But it gives us more building blocks.

Ethereum is planning to move from proof-of-work to proof-of-stake next month. As someone who has participated in large open-source projects before, it's impressive that the developers were able to make such a drastic shift to the network. Here's what you need to know.

• There will no longer be any Ethereum mining. This should substantially lower the energy requirements of the network.
• Instead, incentives will be allocated by staking or depositing your Ethereum into nodes. Anyone can do this or join a pool (although the minimum is 32 ETH to run your own).
• You currently can't withdraw your staked eth. There are plans to add the ability to unstake it in a future fork. See Costs of Participating in Decentralized Networks.
• The exact date is unknown because the network will switch at a total terminal difficulty (a function of the hash rate) of 5.875e22, which is predicted to be September 14th, 2022.

• Ethereum still makes the same tradeoff in regards to availability vs. consistency.
• Tokens issued as rewards will decrease over time. This means that Ethereum will become deflationary at some point – the burn rate will be greater than the mint rate.

Some open questions:

What happens to the miners? There are companies that have invested significant resources into physical hardware that will now be useless (for Ethereum). Some predict they will hard fork the chain and continue operating the existing chain using the state before the merge. When Ethereum faced a massive hack in 2016, the developers chose to reverse the transaction and hard fork the chain. The original chain, Ethereum Classic, still lives on with an unaltered history, and the Ethereum Classic Token market cap is non-zero (~$2 billion).

What are the risks of proof-of-stake? Ethereum doesn't have on-chain governance, so a malicious actor couldn't change the rules. However, with 33% of the total Ethereum staked, you could halt the network and prevent new transactions from happening. With 66%, you could validate malicious blocks. Compare this to the 51% attack in traditional proof-of-work blockchains.

Other chains already run proof-of-stake, but none as large as Ethereum. It will be interesting to see the outcome of the merge. There are a lot of incentives and stakeholders (pun intended).

I'm optimistic for the developers and ecosystem. Whether or not you believe in the mission, the sophistication of the open-source infrastructure behind Ethereum is impressive. So, if there's a decentralized team to pull this off, it's probably the Ethereum team.

Yet, there are always risks:

Never rewrite the code from scratch.
– Things You Should Never Do by Joel Spolsky

Ship of Theseus

The Sailing Ship Effect

Few tools walk the right line between declarative and imperative like make.

Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. It began with an elaborate idea of a dependency analyzer, boiled down to something much simpler, and turned into Make that weekend. Use of tools that were still wet was part of the culture. Makefiles were text files, not magically encoded binaries, because that was the Unix ethos: printable, debuggable, understandable stuff.
– The Art of Unix Programming

make build a directed-acyclic build graph (DAG) of dependencies, and uses file modification times to decide whether or not the outputs need to be rebuilt.

Why is make so successful?

• Does not manage the state itself. No database of file modification times, checksums, or build output files that could cause bad states to happen. Instead, make just compares the file modification times of the outputs to the inputs.
• Not fully declarative. While this is an undesirable property for excessively large systems, it is good enough for 80% of projects (Pareto principle for build systems). Declarative-ish syntax for the rules you care about and simple PHONY rules for tasks you don't.
• Easy escape hatches. Makefile syntax isn't great for complicated configurations. Using make as the entry point for a variety of bash scripts usually isn't too bad.
• For most configurations, not excessively templated. In some ways, the tough-to-learn syntax has prevented Makefiles from looking like Helm charts or Jinja templates.
• Other Lindy reasons we might not know.

Of course, there's always room for improvements in a 46-year-old piece of software. Some of these features might be out of scope, but a short list of ideas.

• Reconciling docker builds with makefile targets in $ make docker. Many language-specific tools already do a weak form of this – yarn or npm will runs tasks in the context of your node_modules directory. Docker provides a much more generalized and cacheable substrate to run tasks. It also works well with DAG structure and make's semi-declarative nature.
• First-class support for configuration languages like JSON, maybe jq built-in? Much like pattern substitution and wildcards, a little bit of optimization here could go a long way.
• A dependency framework or flexible type system like Why TypeScript for Infrastructure? You can include Makefiles, but the behavior is not very intuitive and difficult to debug. Although this might be one of the strengths of a Makefile.
• File-watcher or live-reloading. You can create a build/deploy loop fairly easily, but having knowledge of the DAG simplifies this for developers. That's how skaffold works.

In negotiations, there's a distinction between distributive and integrative bargaining.

Distributive bargaining is a zero-sum negotiation where fixed resources are allocated between parties.

Integrative bargaining is where multiple interests are negotiated at the same time and deals are structured to create value through creative solutions.

Not every negotiation is open to integrative bargaining. For example, in car buying negotiations, the buyer wants to pay as little as possible, the seller wants to charge as much as possible, and it's often not a repeated transaction. But some are.

When Steve Jobs returned to Apple in 1996, he was tasked with convincing Bill Gates to continue to support the Macintosh with new versions of Microsoft Office for Mac. A struggling Apple needed assurance from Microsoft of continued application support (and cash), and Microsoft wanted to settle longstanding patent litigation.

Negotiations between Microsoft and Apple's previous CEO, Gil Amelio, had stalled. Jobs tried a different approach.

“It was classic,” remembers Gates. “I’d been negotiating this deal with Amelio, and Gil wanted six things, most of which were not important. Gil was complicated, and I’d be calling him on the phone, faxing him stuff over the holidays. And then when Steve comes in, he looks at the deal and says, ‘Here are the two things I want, and here’s what you clearly want from us.’ And we had that deal done very quickly.” – Becoming Steve Jobs

Microsoft agreed to a public display of partnership – Gates appeared on video at an Apple conference to announce a $150 million investment into Apple and a five-year commitment to Office for Mac.

This is the platonic ideal. We're not there yet, but the all signs point to this rather than specialization.

Applications and their infrastructure (functions, queues, permissions, runtime) have always been closely intertwined. Fewer handoffs mean quicker deployments and less context loss.

So – Why can't developers deploy their own code (yet)?

1. Provisioned infrastructure economy¹

Competing product teams must be allocated resources at companies with provisioned infrastructure. Finance departments must be able to track resource spend per project and per department.

Why it doesn't matter anymore: usage-based cloud infrastructure includes mechanisms to track spending (e.g., AWS resource tags, separate accounts, budget limits), and with the right tools, finance can get real-time breakdowns.

2. Lack of expertise

Many developers might not know how to deploy their services to production. Frontend engineers who don't know how to write a Dockerfile to backend engineers who don't know Terraform.

Why it doesn't matter anymore: Infrastructure-as-code is increasingly targeting developers rather than IT or DevOps personas. You can see this in the focus on Typescript for infrastructure rather than templating languages or configuration DSLs. The abstractions keep getting better. Cloud infrastructure APIs replace many DevOps functions – provisioning servers, monitoring, and observability.

3. Focus

Developers might be best at debugging their own applications in production but don't want to be on-call. Site reliability engineers might be better at fine-tuning infrastructure. It's often easier to centralize production access to a smaller group of dedicated engineers (rather than the entire development team).

Why it doesn't matter anymore: More small-ops (I won't say zero) deployment options. Things still go wrong but are a class of problems that can be solved more efficiently by developers directly. Different failure modes enabled by new technology (fault-tolerant design) mean that sometimes issues don't need to be resolved immediately – e.g. fallback to CDN, self-healing services, and multiple replicas.

4. Organizational (Authorization/Compliance)

Organizations need to enforce policies regarding who can access what. Who can access the production database? Who can spin up new infrastructure? The easiest solution was an IT/DevOps team that managed the permissions and elevated access on behalf of the developers. This centralized the responsibility.

Why it doesn't matter anymore: Cloud infrastructure also has a robust identity management solution. Users (and machines) can be authorized to specific actions with audit logs. This is far better than any off-the-shelf product or solution an IT department could develop.

5. Reusing workflows

A platform team can build abstractions that are used by multiple product teams. This also standardizes deployments and infrastructure, making it easier for downstream teams to manage.

Why it doesn't matter anymore: Platform development is undifferentiated work, and few (if any) teams can keep up with open source or cloud provider abstractions. Every platform expands until it exposes most of the underlying infrastructure.

¹My own story about getting around the IT department.

The SEC released a list of sanctioned Ethereum addresses and the smart contract Tornado Cash, a program that allows users to mix (i.e., launder) crypto. Blockchains make all transactions public (see tradeoffs), so mixers obfuscate the sender, recipient, and values of transactions.

There are legitimate users of these services that value privacy, but there are also bad actors – state-sponsored hackers like the Lazarus Group (North Korea) and other hackers.

A few questions:

What does it mean to sanction a smart contract? GitHub removed the developer's repository and account, but others already have copies of the code and can deploy it. You can identify direct copies of the program, but any small modification would result in a different checksum and therefore be harder to identify.

Will there be a premium for freshly minted tokens? Receiving tokens that can be traced back to some crime or illegal activity can create the risk of government forfeiture. There might soon be a distinction between "clean" tokens – tokens that can be traced back to their origin without being in the hands of bad actors – and "dirty" tokens.

Blockchains are permissionless. That means that, similar to email, anyone can send you tokens, NFTs, or anything else on the blockchain. What happens a bad actor sends you dirty tokens or data with illegal contents, and it's found in your wallet?

What happens to zero-knowledge rollups, which provide another privacy mechanism in public blockchains? They can be used for the same purpose.

Will this limit the blast radius of large hacks if hackers can't launder their stolen tokens? New mixers will emerge, but mixers work best when there's significant liquidity.

I tend to be an optimist. I don't think this is a widespread inditement against crypto. These problems are solvable but require different tradeoffs. This might mean that crypto will not be decentralized writ large. But the level of scrutiny the SEC is giving to the space should be a positive indication that they're taking it seriously.