Some quarrels:
Into that world drops Docker: a new way of doing almost everything. It throws away old rules about operating systems, and deployment, and ops, and packaging, and firewalls, and PaaSes, and everything else.
That's a dramatic overstatement if I ever saw one. The rules haven't been thrown away. They're there, just the subsystems partitioned into multiple namespaces under a single host.
But then something interesting happened. Web applications got large enough that they started to need to scale.
The whole portion of the essay about web applications and distributed systems operates under a broken causal chain and continuity. That assumptions break down and new use cases arise with scale is obvious, though here it's presented like some recently attained enlightenment, and moreover that every J. Random Hacker should be thinking about distribution and high scalability right from the conception of their CRUD app. Not the case. Dumb setups work for the commons.
Instead of dealing with simple things like web frameworks, databases, and operating systems, we are now presented with tools like Swarm and Weave and Kubernetes and etcd, tools that don’t pretend that everything is simple, and that actually require us to step up our game to not only solve problems, but to understand deeply the problems that we are solving.
This paragraph makes no sense. The author is listing completely orthogonal tools.
------
On to the allegedly solved problems:
Which is ludicrous because the application relies on the machine and the OS as well as the code, and thinking of them separately makes no sense. Containers unify the OS and the app within the developer’s toolkit.
Depends on your domain. Plenty of applications are built to be self-contained. The unikernel/libOS approach is one that treats the OS as an implementation detail, ironically taking us straight back to the 1950s where all code had to independently initialize the machine, though in a good and reusable way.
Up until now, we’ve been running our service-oriented architectures on AWS and Heroku and other IaaSes and PaaSes that lack any real tools for managing service-oriented architectures. Kubernetes and Swarm manage and orchestrate these services.
Those are all different deployment strategies and application environments you're mixing up here. It may not be that you've lacked tools so much as you've had no need for them in your use case.
Up until now, we have used entire operating systems to deploy our applications, with all of the security footprint that they entail, rather than the absolute minimal thing which we could deploy. Containers allow you to expose a very minimal application, with only the ports you need, which can even be as small as a single static binary.
And it does so by cloning the various subsystems of the host OS into their own namespaces. You don't get around using the whole OS, you just work around it because your host OS can't handle multi-tenant properly and the dynamic linking quagmire has become a maintenance burden.
Up until now, we have been using languages and frameworks that are largely designed for single applications on a single machine. The equivalent of Rails’ routes for service-oriented architectures hasn’t really existed before. Now Kubernetes and Compose allow you to specify topologies that cross services.
This hasn't changed. You still need to bolt on lots of heterogenous components. Seamless multi-node distribution is beyond the scope of nearly all language runtimes, or frameworks, though then again nor is there any obligation to support this. At sufficient scale, you will be doing lots of homegrown integration work.
We couldn’t say “I want 0.1 of a CPU and 200MB of RAM”.
Pretty sure you could. I'm assume you're referring to the likes of Mesos, in which case I can name at least HTCondor, which is a cluster manager and scheduler not unlike Mesos, intended for HPC. It's been around since 1989. Then there's the much smaller scale things you could always do to limit resource utilization. It's not like this was discovered yesterday.
Up until now, we’ve been deploying applications and services using multi-tenant operating systems. Unix was built to have dozens of users running on it simultaneously, sharing binaries and databases and filesystems and services.
Author confuses multi-user with multi-tenant. Unix is the former.
As an example, how many protocols had to die before we got REST? ... Yet, we still haven’t got the same level of tooling for REST-based APIs that we had for SOAP a decade ago, and SOAP in particular has yet to fully die.
REST isn't even a clear protocol suite like SOAP or CORBA. It's more of a design philosophy than a formal definition.
And the same thing has been going on with programming languages since we escaped Java a decade ago.
We did?
If you’re looking for me, I’ll be in the future.
Damn, it looks an awful lot like the past.