Put on your tinfoil hats, we’re going for a ride.
I think James Bridle said it best:
What concerns me is that this is just one aspect of a kind of infrastructural violence being done to all of us, all of the time, and we’re still struggling to find a way to even talk about it, to describe its mechanisms and its actions and its effects.James Bridle, Something is wrong on the internet
There’s a good few posts I can write about social media and hyper-connectedness, and how it’s having an erosive effect on our collective identities and well-being, but right now I specifically want to talk about serverless architecture.
I’m an active participant on the Indie Hackers forums, and the recent conversation about serverless websites was one I pretty much had to get involved in.
It’s a problem I keep running into – a dynamic that makes me uneasy, in a way that’s hard to pin down. That’s what I’m trying to do in this post right now: give an outline of a problem that I’m sure most people aren’t yet aware of as a problem. With the possible exception of Cory Doctorow and everyone in his orbit, and I’d hate to end up in a world where he was right all along.
Serverless architecture is the hot new thing, haven’t you heard? Absolute magic: You only need to write the bare minimum code to make your business logic work, then upload it into a magic cloud that takes care of putting it on the internet for you. And you don’t even have to pay for the server!
I have the feeling that a lot of relative newcomers to web development over the last few years are excited about this, mostly because it lets you build APIs without actually having to know anything about how APIs work. So long as you can define a NodeJS HTTP Response, you’re good to go – and that’s the sort of stuff that can be taught inside of a day, assuming you never explain the OSI Model, TCP/IP, how browsers actually connect to servers, what a network stack is, what ports are, what networks even are, and so on.
In short, what serverless encourages is bare minimum ability. Only having to learn enough to make a vendor’s specific implementation work, instead of learning any of the principles that underpin it, or whether or not they’re even good designs.
Personally, I’m in favor of learning as much as I can about any given system. I like being able to do new things, and understanding how and why things work, and trying to discern the governing principles beneath them. That’s why I’ve read most of Paul Graham’s essays, I know what a Twelve Factor App is, I understand MVPs in relation to a sales cycle, and I understand the difference between programming and engineering (among other things)
Then the conversation turns into a semantic nightmare where the saner voices might suggest that a person’s value as an individual is not tied to their skill in any given field, which then generally collapses into a bunch of name-calling.
The sanest people don’t engage in these conversations in the first place.
As far as I’m concerned, the people who have spent literal decades in the trenches: writing code, making mistakes, and designing the systems that underpin everything else we do (things like the Linux kernel, or the HTML spec, or TCP/IP, or software team principles) generally do have more valuable things to say about how software should be built, vs someone who just got hired at their first frontend job.
That’s generally the point where I get booted out of the conversation for being antagonistic. Try as I might, I cannot fairly equate the skills and experience of a first-timer to someone who literally helped define the field they’re working in.
I’m learning to move on from these situations though.
My approach of late is to try looking at the bigger picture, which right now is best summed up like this:
Microsoft, Google, Facebook and Amazon own and manage a substantial portion of the information that flows through internet, and by extension, the foundations of communication, productivity and trade in the 21st century.
Note: For the purposes of this article I’m ignoring Apple – while they have an enormous market cap and built genre-defining hardware, their walled-garden approach to developing software for those devices might be the thing that ultimately exonerates them.
Each of them has built up an enormous, complicated set of technologies that makes their core businesses work – all of which has been exported to the public market:
- Microsoft: .NET and Azure
- Google: Angular and the Google Cloud Platform
- Facebook: ReactJS and the social graph
- Amazon: Amazon Web Services
Each tech giant, being American, also exports a particular set of cultural norms. Being a high-performance culture that worships productivity above all else, everything done in service to greater productivity should pass without question, including:
- Keeping people connected and online all the time
- Encouraging people to form family bonds in the workplace
- Defining and projecting values (not just mission or vision) – Google in particular has explicit “Googley Values”
- Constantly aligning, encouraging and nudging people in their employ to live up to a vision that is ultimately exploitative in the wider market (with the likely exception of Microsoft), and
- Acting with the default assumption that they’re entitled to do whatever they like with the data entrusted to them by billions of people. Move fast, break things – right, Facebook?
Then there’s the happy tech-skill halo effect, first unearthed by Microsoft. If you export the tools you use within your business and make them available on the open market, anyone who learns how to use them would make excellent technical recruits – without having to significantly invest in training or upskilling anyone to use your systems.
They would also use your tools and products in their own work, further embedding the reach of your paradigms well beyond your own company. Individual open-source developers understand the pull of this all too well (it’s a sure route to power).
Microsoft built .NET to have a framework for Microsoft to build Microsoft products, but by making it available to businesses and developers in general, they got to look like visionaries for making a big set of free tools available – in return for the near-invisible effect of re-shaping developers into capable Microsoft candidates.
Note: Gamers will recognize this. It’s the plot of Mass Effect: An ancient civilization left behind “mass relays“, devices that enable interstellar transport so long as you build your ships to interface with them. And by doing so, it made it much easier to round everyone up during the harvest time, since all technology had been shaped in the image of that prior race.
That’s been amplified (almost inadvertently) over the last 10 years, with people shifting more of their social interactions online. They’re not just tools anymore – they’re communities, with a set of shared personal values that dictate whether or not your conduct is acceptable.
If that sounds crazy, consider that the Contributor Covenant has been imported to over 100’000 open source projects and has been publicly endorsed by major organizations. While the content of the covenant itself is progressive and relatively harmless, the mechanism of establishing a centralized monoculture across the internet is not.
So as of 2018, if you’re a “React Developer”, that’s not really a job title. It’s also not just an expression of which languages or tools you use. It potentially signals membership in, and acceptance of, a certain way of doing things – almost certainly underpinned by the value systems and worldview of a corporation that’s absolutely not acting in your best interests.
If that sounds a bit tinfoil-hatty to you, don’t worry, I hear you. It sounds that way to me too, believe me. Thing is, I’ve been building websites since before Facebook, and something has just started feeling wrong over the last few years.
And I suspect it’s got something to do with the unexpected impact of having the world’s largest technology companies also
- establish and enforce behavior and personal values among employees and community members while also
- owning the technical direction of the tools we use to make and share things while also
- having enormous financial and political power in the largest market on Earth while also
- not acknowledging any of this impact, instead stating all of the metrics in universally-friendly terms while also
- making decisions that have widespread negative impacts on people that we’re only now just beginning to understand.
And these are all the companies selling you serverless technology today: A paradigm that further divorces the developer from the computer, abstracting away all the vital parts that, if understood, could be improved on for everyone’s benefit – like how the web has been built up until this point.
Instead, by coercing new generations of developers into paradigms that divorce them from the (relatively) simple act of bringing a basic website online, these companies are pushing us into a future where software development is not a thing you do on your computer in your home: It’s a thing you do on their services, in their languages, with their tools.
At this point I sound exactly like Cory Doctorow and wish this nightmare to end.
This exact paradigm has already proven problematic, with the Electronic Frontier Foundation taking manufacturers to task over things like not being able to update the firmware on your own car. That’s a domain that’s foreign to me, but web development is not, and I’m already dreading the day we wake up to realize that the internet itself exists in the hands of a few large companies.
Maybe we’re already there, I don’t know. I just like to think there’s still enough variety in hosting, languages, tools and approaches, that there will continue to be individual innovation that advances things for all of us.
The title is a reference to the work of Douglas Engelbart. The 9th of December this year marked the 50-year anniversary of The Mother of All Demos – a 1h40m collaborative presentation in which him and a team of engineers built hardware and software that effectively showcased the future.
The video is long and somewhat boring, so it’s more interesting to list out the sort of stuff they covered:
The live demonstration featured the introduction of the computer mouse, video conferencing, teleconferencing, hypertext, word processing, hypermedia, object addressing and dynamic file linking, bootstrapping, and a collaborative real-time editor.
Fifty years ago, a bunch of engineers had thought through the problems that we’re still dealing with in modern-day computing. Even if they had not managed to solve those problems as effectively as we’ve done today, they were at least able to articulate and navigate them.
It’s the example I keep coming back to in conversations about “new problems” in computing: There barely are any, at least not in the domains of communication or productivity. It really helps knowing the history of this stuff, too – you might save yourself a lot of trouble if you learn from the people that tried solving these problems before you.
But then that’s “old”, so it’s automatically discarded as irrelevant, and people move on to the next new shiny thing. A perpetual disregard for history and obsession over disrupting the status quo – an impulse firmly embedded in tech culture by two decades of reckless Silicon Valley gospel.