I reactivated my twitter account last week. I don't really enjoy using Twitter, but I'll cheerfully acknowledge the place it occupies in public discourse. For many communities in which I want to participate, Twitter has justifiably outcompeted email and the phone system as the venue where it's acceptable to start a conversation with someone you don't already know^[1]. But just because it's obviously the best place to start a conversation doesn't mean it's the best place to have a conversation^[2]. The message-length limits and the futility of trying to create a shared context--replicating the kind of smalltalk and emotional cues that keep IRL conversations from turning ugly--limit my use of Twitter beyond the role of a kind of phone book for conversations and participants.

I'd like to use this post to describe one conversation I've seen and add to it a little context. The conversation is about How Best To Build A Website. It's perfect Twitter fodder, because the correct answer depends entirely on context that can't be expressed within the limits of a tweet. So, when the conversation happens on Twitter, everyone chooses a side based on their assumptions about the relevant context, and, from that position, lobs arguments in the general direction of the other trenches. This dynamic has all the fun and excitement of a good snowball fight, and the same probability of advancing reasoned arguments.

Even in this kind of conversation, however, there are things to learn. I'd like to focus on one snowball^[3] I recently saw whizzing above my particular trench. It's a video/gif using Seinfeld to illustrate the complexity and uncertainty of trying to set up a website using cloud services. Jerry wants to set up a simple blogging site for himself. Elaine has a static site made with hugo^[4]; that's what Jerry wants. The customer service rep smiles--of course! Nothing simpler!--and starts typing. Jerry chats with Elaine--he wants something simple, cheap to maintain. He wants to publish from simple text files on Github^[5]. He wants his site to stand up if his "500 followers on Twitter" all decide to visit at once^[6]. At last, the customer service rep has found an option. It's got all the latest cloud technology, and it's going to cost $7,590 per month. It runs on a container cluster^[7]. Jerry balks--a container cluster? No! Just^[8] a place to store files where you can see them on a browser! Jerry doesn't need any of an exhaustive list of buzzwords, and he knows--correctly--that his dream of publishing recipes for sourdough bread on a blog shouldn't cost more than the price of a cup of coffee per month. He says as much. The customer service rep looks at him pityingly, and delivers the punch line: "You should just use Github Pages."

Let's focus on the real, true and indisputable message of this exchange: cloud services are currently too complicated for an outsider in Jerry's position to use wisely and effectively. I feel very confident in that statement since no one who knows enough to contradict it is in Jerry's position. The video gets that exactly right.

But it also conveys a skepticism about cloud services that's increasingly unwarranted. Let's imagine an informed answer to Jerry's question. How do you set up a static site in the cloud? The Amazon Web Services cloud offers exactly this service. Google's cloud does as well. So does Azure, Microsoft's cloud. These services are precisely comparable to the difficulty of putting a directory of static files behind an Apache or Nginx server. And they are cheap af (If you want to dispute this, as people sometimes do, be ready to cite real-world use cases and do some math with very small numbers). The type of person who finds Github Pages simple but an AWS bucket complex is a software writer who's already familiar with git, but isn't familiar with cloud orchestration tools. That's kind of a niche use-case--a non-software-writer would instead be drawn to a service like Medium, which provides similar capabilities with a less wonky experience.

I see in cloud-skepticism a very similar pattern to computer-skepticism from before the 1990s, and internet-skepticism from around 1993-2010. That is, the skeptics would say--accurately--that first computers, and then the internet, would not be capable of removing the complexity from areas of human experience. The proponents of those technologies--at least, the ones who weren't trying to sell you something--would acknowledge complexity as a fact of life, but would argue that computers and the internet should be evaluated carefully and fairly as tools that provided previously-unavailable capabilities to their users. So it is with cloud technologies in 2020--they are not simple (and it's on people like me to fix that) but they represent--in availability, reliability, safety, control, and cost--tools that have never before been practically available to small publishers. We--people like me, who see a kind of Unix-y elegance in these tools--need to do a better job of making their good parts widely available and stringing caution tape around some of the pointier hazards. But there's a lot of potential, and it would be a mistake to discount it.