Cloud Legos, Not Cloud Jack-of-all-Trades-in-the-Box

This week Corey Quinn wrote about what the “next million cloud customers” will need from Amazon. In the post, he warns Amazon that if they don’t provide a higher level abstraction of all of their cloud services, essentially pre-architecting industry vertical appropriate cloud architectures that will help get the many yet-to-covert companies onto the cloud, then someone will eventually show up and meet this market opportunity, eventually relegating AWS to the domain of NTT and CenturyLink; vital, yet unknown. It’s a compelling argument. But what if AWS doesn’t build this abstraction, and what if nobody else does either?

In 2003, while helping my CTO decide between buy vs build for a CRM to service our VOIP-startup, I experienced my first real appreciation for just how difficult it is to create a service you can sell broadly to many enterprises to fit their needs. Nothing among the ocean of CRMs we could find matched our VOIP-startup needs in a way that wouldn’t create so many new headaches for us as to be worth the cost or implementation. We ended up building a solution ourselves. The CRM we needed had to fit our particular way of doing business. And our particular way of doing business was our secret sauce – our differentiator.

In 2006, I helped rescue a massive project to modernize a major insurance company’s quoting software from COBOL and mainframes to Java and the Web. Many of the problems they’d run into during the move were the result of one assumption: That the way this massive insurance company did business was somehow separate from the encoding of their processes and policies within that old COBOL code. The result: 100s if not 1000s of bugs where the web-based Java software ran exactly as designed, but not in a way that the company needed it to run. And it’s not like the architects were idiots. Things just got lost in translation. Ultimately, that company had to change the code and itself in order to make it all work together.

In the 2010s, Marc Andreesen pointed out that “software is eating the world.” SaaS finally had an acronym people recognized and understood. And ever since, 100s of disruptive new companies have sprung forth, eating the worlds of many older enterprises who can’t just start anew. There are at least 534 billion dollar “technology” companies. In today’s parlance, a “technology company” is often any company that realized you could do something established companies had done for a long time, but with a lot of software to do it, and find margins the established companies could not. You either are a SaaS, or you’ll be eaten by one.

Corey suggests that AWS could possibly understand verticals in which they do not operate at all well enough to pre-architect these cloud implementations. I’m skeptical, even if it is Amazon. No non-trivial business software today is able to execute at a generalized enough level to be applicable to a broad enough market that it would move the needle for a trillion dollar business. And no software that was so broadly attractive to a large enough market would function specifically well enough to meet any one customer’s real needs. Adoption of cloud abstractions overly generalized by industry non-experts would be corporate suicide.

I actually like Corey’s idea. It’s a multi-trillion dollar idea if you can do it right. Which means that there’s an opportunity to become one of many, many multi-billion dollar companies if you can do some piece of it right. And that’s what I think will happen. Hell, that may actually be what Corey meant all along. If nobody shows up to build the uber-abstraction-layer for all things cloud for all industries, then we’ll get dozens if not 100s of industry-specific, cloud-category specializing players.

A market may well demand a singular uber-abstraction, but there’s such a thing as unmet demand. One of my favorite econ profs in college would jokingly call that an “unyet supply.” (Always love a dad-joke.) And in that vacuum of unmet demand we can build an ecosystem of integrable abstractions. But the enterprises still waiting on the sidelines will need to identify and utilize these abstractions quickly, because the domain of benefits will not only belong to them. 100s of other startups will be able to benefit too.

So… a funny thing happened:

I started writing this post on Wednesday of this week, and as I usually do, slept on it to see if I still agreed with myself the next day. And wouldn’t you know it, something did happen: Smart minds, including Cory’s, got their heads around Cloudflare’s new R2 product.

Here’s smart-minded Ben Thompson to explain part of what this means:

That is one way this could play out: R2 is a compelling choice for a certain class of applications that could be built to serve a lot of data without much compute. Moreover, by virtue of using the S3 API, R2 can also be dropped into existing projects; developers can place R2 in front of S3, pulling out data as needed, once, and getting free egress forever-after.

So R2 proves Cory right, but in a funny way. Someone is showing up to take advantage of AWS’s margins, and provide a kind of modular replacement of S3 by supplying a compatible front-end that enables developers to build much lower cost interop between cloud service providers. Do you have any idea how many times in the last several years I wished I could affordably move a ton of data across CSPs without incurring huge costs so I could take advantage of the relative strengths of each? Anyone want to write a quick ETL that takes advantage of Route 53, Lambda, S3, and Google BigQuery? Now you might be able to without upsetting your CFO.

But this is still not quite what Cory had in mind, at least in his stated thesis. This is no abstraction. Indeed, R2’s API is a copy of S3’s API. You still have to have a good bit of actual knowledge – now about 2 cloud providers! – to get lower cost multi-cloud interop working together in a way that suits you. But it’s still a major step forward for those of us with the know-how. And maybe it’s a small step forward to a future of companies that can provide industry-specific abstractions that cross clouds.

What Automattic Should Do With Pocket Casts

Last week, I…

It got me thinking about what I’d recommend to Matt Mullenweg, CEO of Automattic, if I were running the Pocket Casts product strategy.

What helped the Web grow so massively was the users’ ability to follow links from sites that already interested them to discover other sites relevant to their interests (Curation). Further helping the web’s popularity explode was the ability to search for something that interested a user and usually discover at least one resource relevant to their interest (Discovery). What made people love Google Reader was the ability to “subscribe” to those resources they found useful in case the same site published more they found interesting.

I found it odd that every piece I read about Pocket Casts last week mentioned that it was a well-liked app partly due to its discoverability and curation features. It’s odd b/c I’m a very frequent user of Pocket Casts, and I was under the impression that Pocket Casts makes absolutely no effort toward curation and discoverability. If what Pocket Casts offers for curation and discoverability is in the upper echelons of the podcast world, then the podcast world is in a dire state. Podcasting has dozens if not hundreds of “Readers.” It’s easy to subscribe to any podcast about which you already know. It’s the finding of podcasts that’s hard. It’s a problem that’s basically the inverse of the one web pages had.

WordPress, a platform that already runs 40% of all webpages in the world, should leverage its power to build a discoverability and curation service for Pocket Casts to consume to help people interested in a given subject find new, relevant podcasts. Automattic should aim to make that service so good and Pocket Cast’s discoverabilty and curation UX so delightful as a result that other podcast players seek to use the service as well. And Automattic should let them. Use the service to force other podcast players to adhere to the use of web protocols.

Most every podcast has an associated website of some kind. WordPress should build tools to help with managing a podcast’s RSS feed, tagging episodes, transcribing episodes, and even scanning both the content on the WordPress site and any sites linked on an episode’s correlated “blog post” to better identify context of an episode. Imagine if WordPress could then use a highly-invested user-base to create a way for one podcast producer to notify another podcast producer that their most recent episode actually discusses things from the receiver’s podcast. How great would it be, as a podcast listener, to be able to follow a “conversation” from one specific episode of a podcast to another specific episode of an entirely different podcast even if you didn’t follow the 2nd podcast?

The platforms that are putting “podcasts” (note: if you can’t use RSS to subscribe, it’s not a podcast) behind walled gardens can’t do this. And while those companies may attract huge numbers to their listening platforms, they’re stuck with strategies catering to quarterly reports. Automattic is uniquely positioned to play a much longer game, continuing to help the open Web grow, adding features atop protocols, and eventually, possibly, helping a much larger, true network solve the second problem for podcasts: monetization.

There’s No “AI” In “Software Engineer”

The last couple of weeks, I…

  • Listened to the always excellent Postlight Podcast, in which Rich and Paul talked about Code and, specifically, Python. That lead me to…
  • Re-read Paul’s “Ode to Code,” better known as: What is Code?
  • And then I shared a tertiary, virtual chuckle with Rich, Paul, and Bill Gates as Bill reminded us all that when it comes to code, nothing much has changed since Bill’s coding days.
  • Then I read this bit by Ben Thompson over at Stratechery on, essentially, how code kinda helped save the world a lot of the economy.

That alone had me thinking a bunch about the nature of code and what it means for an organization. But then came…

  • Github Copilot: An “AI” Pair Programmer. A service that promises to help make coding more efficient by providing a very advanced form of auto-complete or type-ahead for programmers. It won’t just suggest terms or variable names. It’ll suggest entire algorithms.

It’s caused quite a stir in the world of code. A lot of digital ink has already been spilled on this topic.

But one thing I haven’t seen discussed yet is any concerns about what such a tool will do to creativity in code.

Software engineering isn’t “just programming.” Many people who can write code are not strong software engineers. Some folks who can write particularly good code – even genius algorithms – may not be particularly great engineers. As a manager of software engineers, I’ve found that sometimes “great coders” can be a tricky fit for a team. Software Engineers have an ability to build software products that solve problems in a given domain in a manner that makes some facet of life better. There’s a “zoom in, zoom out” nature to software engineering; A need to keep many of the details and the big picture in your head at once. The more zoomed in aspect of a software engineer’s work often involves code. And creativity springs up in both the zoomed out and zoomed in modes of a software engineer’s work.

This “AI” that Copilot represents is not clever. It’s simply not creative. It will often just repeat what it’s already “seen.” It’s really just a regression to a mean based on a massive body of historic coding records. It may never be creative. And while a lot of code writing can get repetitive or rote, occasionally someone finds a creative approach to the most mundane code and eeks out another competitive advantage. I’m not sure it’s particularly wise to forfeit those small moments of “ah ha!” that only ever seem to happen at the crossroads of domain specific knowledge and boredom.

A long time ago I worked for a CEO who would always say, “sales is the lifeblood of a company.” That may well be true. It’s certainly vital. But in the age when software is eating the world, every company is either already a software company, soon to be one, or soon to be killed off by at least one. Software may not be the lifeblood of a company, but it’s almost certainly the nervous system. The software a company runs defines how a company “thinks” and how it executes. Code in that software can define advantages. The advantages may be revolutionary or they may be on the margins. There are many opportunities to find advantages in code. So if software engineers begin adopting “AI” tools that “write code” for them, then those engineers are forfeiting an opportunity for creativity. Any forfeit of creativity is a forfeit of competitive advantage.

There’s sure to be a use for Copilot and its inevitable successors. I don’t really want to write any more code than is necessary myself. But we should tread carefully as we adopt these sorts of tools. We should think carefully about the strategic and competitive costs we may subject ourselves to while adopting tools that promise more efficiency.

UPDATE: This is a nice post showing where/when a “happy medium” between efficiency and lossless creativity might be found. It’s much more “you don’t need to remember this arcane API” and less, “here’s an algorithm.”