Docker appeared in 2013 and popularised containers, a lightweight way to package an application with its dependencies. Orchestration tools such as Kubernetes followed. For ordinary website owners, the more visible change was the arrival of Let's Encrypt, which went into public beta at the end of 2015 and offered free, automated certificates. Within a few years, the share of web traffic using HTTPS passed the majority mark, helped along by browsers that began flagging plain HTTP pages as not secure.
HTTP/2 was standardised in 2015, bringing multiplexing and header compression, and it effectively required HTTPS in browsers, giving site owners another reason to switch.
These threads look unrelated, but they pulled in the same direction: less hand-built infrastructure, more automation, and an assumption that every site speaks encrypted HTTP. By 2019 a new site on a decent host got a working padlock without its owner doing anything, which would have sounded unlikely in 2012.
Containers in one picture
A virtual machine carries a whole operating system with it. A container does not: it is a process, or a group of processes, that the host kernel isolates using namespaces and control groups, with its own view of the filesystem and network. Several containers share one kernel, so they start in a second or two and use far less memory than a full guest.
Docker did not invent any of those kernel features. What it added in 2013 was a pleasant way to use them: a file describing how to build an image, a registry for sharing images, and commands short enough to remember. Once an application and its libraries were in one image, "it works on my machine" mostly stopped being an excuse, because the machine came with it.
Orchestration, and what it meant for small sites
Running one container is easy. Running hundreds across many machines, restarting the ones that fail and rolling out updates without downtime, is a scheduling problem. Kubernetes, released as open source in 2014 and reaching version 1.0 in 2015, grew out of that need and became the common answer, with alternatives from Docker and others alongside it.
Most small site owners never touched any of this. The effect reached them through their host, which could now build shared and managed plans on containers for tighter isolation between accounts. For anyone running a personal blog the advice stayed the same: do not adopt an orchestrator for one WordPress site. It adds moving parts that you then have to understand during an outage.
Free certificates, and why they mattered
Before Let's Encrypt, a certificate was something you bought, usually for a year or more, after generating a request by hand and answering an email or uploading a file to prove control of the domain. Plenty of owners skipped it because of the cost, or did it once and forgot the expiry date, which is how sites ended up with a browser warning on a Monday morning.
Let's Encrypt, run by the non-profit ISRG, removed both problems. It entered public beta in December 2015 and was open to everyone in 2016. The certificates were free, and the whole process was driven by a protocol, ACME, so software could request and renew them without a person. Certificates were issued for ninety days on purpose: short enough that renewal had to be automatic.
certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com
certbot renew --dry-runHosts then built it into their panels, so that for most customers the padlock appeared. You can still see what you were issued with curl -vI https://example.com or check the date with the SSL expiry tool.
HTTP/2 and the push to HTTPS
HTTP/2 was published in 2015. Instead of opening several connections and queueing requests on each, it multiplexes many requests over one connection and compresses the repeated headers. The specification allowed plain-text use, but the major browsers implemented it only over TLS, so a site wanting the speed-up needed a certificate. Free certificates arrived at exactly the right moment.
Browsers added pressure of their own. From early 2017, Chrome warned on HTTP pages that asked for passwords or card numbers, and from mid-2018 it labelled all plain HTTP pages as not secure. After that, the question for most owners changed from "should we?" to "why haven't we?".