tl;dr - I gave a short talk on the history of web servers. Check it out in my ’talks’ repository on GitLab or view/download the PDF directly.

I recently gave a talk at the Mercari Meetup on a subject I’ve always been kicking about in my head – how “backend” web servers have changed over time. While I wasn’t programming during the dot-com boom or earlier, I’ve had a chance to work with a fair bit of the web backend landscape as it’s evolved and it’s always interested me on a sociological and technological level. We’ve developed new langauges, techniques, stacks, and products to make developing websites easier, but they’re almost never laid out next to each other or viewed through a historical lens. I am undoubtedly not the most qualified person to give such a talk, but I was happy to take a stab at it.

Clarifications

After posting to reddit some users (like /u/nutrecht) were kind enough to point out weird incongruent/weird/wrong areas of the post, and while I don’t think I should change the talk (since I’ve given it already), I think it makes sense to address the points here:

I just did a quick scan through the presentation and I think you’re making a really weird switch from programming languages in the ‘past’ to VM’s / containers in the ‘present’. A lot of the stuff that you are talking about, like C, Java and PHP, are still used extensively. The way you present this implies that they’re outdated. You also quite freely mix programming languages, ‘stacks’, and web frameworks.

- /u/nutrecht on reddit

In response to this, I’d like to emphasize that the presentation was meant to be mostly historical – I make no value judgements on what technology you should use outside of some pathological cases (you probably don’t need to write your web server in C in 2019). Any emphasis on the “improvements” afforded by a change in technology are more to explain why the methodology change might have been warranted. For example, talking about the industry moving from CGI to reverse-proxied Rails servers in droves does not imply that CGI is bad and should never be used. It is always prudent to use what works for your team and allows you to deliver correct, robust, and well considered software on time.

There’s also some other stuff that is a bit of a head-scratcher. Like calling microservices ‘simpler’ for example. Microservice architectures are not simple, far from. They are a pattern that mimics the organisation and more complex organisations need more complex architectures.

- /u/nutrecht on reddit

My biggest mistake was forgetting to include the “Why not?” section on the microservices slide – I meant that microservices are simpler by definition than a monolith (which is just a bigger service). While a single microservice is simpler than a monolith (just by virtue of doing less), the complexity when trying to perform system level tasks is both redistributed and in most cases increased due to the needing to deal with the distribution of services and coordinate/orchestrate them. Microservices are simpler in the sense that they have reduced responsibilty but I do not mean to imply that they are easier to deploy, manage, or orchestrate than a monolith.

Slides

View the full slides below:

NOTE: if <embed> tags don’t work in your browser of choice, you may need to download the talk instead.

There is also a condensed version of the slides which is the version I actually gave, due to time constraints.