I'm digging the feedback I've gotten so far. By and large you all like these deep dive posts, so I suspect they're here to stay. Today's topic is on competing with AWS; it's not the impossible task you might think it is.

Should you want to share this post you can find its permanent form here.

Mistakes happen in the cloud. Just ask anyone who's accidentally left expensive workloads running, put sensitive data in a public bucket, or agreed to deploy an Oracle product. The folks at cloudtamer.io believe that a well-governed cloud means never having to say you're sorry--and not because Finance doesn't know where to find you. cloudtamer.io unifies access and identity management, budget enforcement, and compliance automation into a single solution that works across both AWS and Azure. If your cloud ops team or developers apologized recently, check them out. If they refused to apologize, several notable tech companies are currently hiring. Sponsored

How to Compete with AWS

As a Cloud Economist, I spend most of my time helping companies fix their horrifying AWS bills. But it's something of an open secret that I periodically moonlight as an industry analyst.

An analysis client recently asked me about the threat of AWS moving into their market as a strategic concern, and couldn't understand at first why I scoffed at the idea. It turns out that my perspective isn't particularly widely shared, so it's probably time I wrote something down about it.

Put simply, competing with AWS isn't hard

Let me clarify first that I'm not talking about Amazon; I'm talking about AWS. How do you compete with Amazon? No clue. You can't outrun them, outfight them, or outthink them. That's your problem.

AWS doesn't eat markets, whereas Amazon retail does, then goes back for more. AWS operates on much straighter rails than Amazon.com does because its leadership fundamentally thinks differently. Every Amazonian is going to be indignantly reaching for their keyboard to tell me I'm wrong right about now. But hear me out: This is what I see from the outside.

All of the "we picked Azure/GCP because we didn't want to fund our competitor" stories that carry any weight whatsoever are never told by technology companies; they're told primarily by retailers who invariably have a suspiciously high number of current employees boasting AWS skills on LinkedIn. Amazon as a whole will, left unchecked, eventually grow to compete in all markets. (As a side effect, this leads to some onerous demands in their non-compete agreements.)

AWS is radically different; the list of what they'll do under the Web Services umbrella is relatively short, and is largely trouble only for companies who are trying to do a few particularly ill-advised things.

Dodge the train

Now, the internet is full of hand-wringing about competing with AWS. Some of the biggest offenders here are companies that whine and cry because they stopped innovating. AWS doesn't ever stop; you've gotta keep ahead of its bow wave of innovation if you want to last.

Or you do something unexpected.

Amazon is very hard to predict; AWS is surprisingly predictable. Companies get sherlocked by AWS largely because they're trying to build a better AWS, which is fundamentally a losing proposition unless you're basically Microsoft Azure and nobody else.

"Ah!" you cry, "AWS doesn't offer a managed Nagios service; I'm going to build one and sell it!"

You would be missing two big things here.

First, it doesn't matter if you're the folks who wrote Nagios; you're not going to do a better job of running it than AWS does. Their operational excellence is the secret sauce that makes AWS work.

Second, you've mistaken open source for a business model. It most assuredly is not; it's a tactic. There's a lot of value to having a community, but understand that relicensing your code after the fact makes people hate you.

This leads folks to get on one of those same rails that AWS is clearly on, and they're a year or more ahead of AWS! Things are great! They're winning customers everywhere, and VCs are showering them with praise and money. Then AWS catches up, and suddenly they're writing sulky blog posts. In this particular case, the vendor has nothing to fear; AWS has a lot of work to do before DocumentDB will be nearly as effective at losing data.

Don't try to outrun the train; dodge it. It's on rails. It can't follow you.

The key is, therefore, to build companies that specialize in things that AWS either can't do or completely sucks at.

What sort of things does AWS suck at? Aside from giving products sensible names, lots of things, which we’ll examine next.

1. Anything that's high touch

AWS flounders with anything that's super high touch. You need look no further than the current wave of companies trying to renegotiate their commitments with AWS. That group is SLAMMED right now because despite all of AWS's efforts, you can't scale people the way you can computers.

A services business is also incredibly nimble with respect to AWS. I chose billing when I started mine, but there's a lot of opportunity out there.

I'd argue that AWS could put me out of business tomorrow with the right feature release—but they won't. They can't; their constraints won't allow it.

Take security as another example. They could make IAM understandable to basically everyone, but they haven't. There's no indication that they're going to, either.

If anything, they're instead rolling out things like tag- and attribute-based controls, which make this area even MORE complex. Making that approachable to humans in a well-executed way is a very successful business waiting to happen.

2. Things they've screwed up already

AWS also doesn't usually take a second bite at the same apple. This gives you room to go after things they've already done, but poorly.

CloudFormation is a great example of this. It's not a great user experience, but because of its gravity they can't fix it. The closest they got was introducing YAML support.

Of course, they have the technical ability to fix it. But AWS treats APIs as a promise. They can't just pull a Google and deprecate seven years of CloudFormation.

That API-as-promise is part of what makes AWS awesome. But it also provides an axis along which you can compete. They might go ahead and try to put a layer on top of it that makes it more approachable—such as with the CDK—but the CDK's primary function right now appears to be "breaking during demos."

3. Talking to anyone who isn't an infrastructure engineer

If you're trying to build a product whose primary market is those lucky souls who've never heard of Linux, AWS will either not compete with you or else compete so ineffectively that it becomes laughable.

Even within engineering, AWS sucks at communicating with customers outside of roughly four personas: backend engineering, data engineers, executives, and infrastructure engineers. If your target market isn't one of those four personas, AWS isn't so much a competitor as it is a convenient excuse not to try.

If you're an accountant, a front-end developer, a lawyer, a corporate IT manager, or basically anything that isn't one of the four personas that AWS knows how to talk to, you have something special going on. Not only do you basically not understand what AWS is talking about when they release something aimed at your market, but their message is so off-putting that you walk away absolutely convinced that whatever the hell it is that they've built clearly isn't for you.

If you're building a desktop management application, you'll do well regardless of what AWS does.

If you're trying to build a better database, I'm predicting some pain in your future.

One of the things that has me so concerned about their rumored AWS for Everyone service is that it’s incredibly likely that they’re going to mess this up completely and set the entire no-code movement back a decade in the process just by their own way of speaking to their audience.

4. Serving a specific industry

AWS is terrible at industry-specific offerings. Azure's announcement of Azure for Healthcare is an example of this; it's a good idea. (Note: If AWS had tried this it would be a terrible idea. They struggle mightily when targeting industry verticals in a way that Microsoft has absolutely mastered.)

They tried recently with Oil and Gas at re:Invent, and I'm told it went so badly that freaking oil companies were falling all over themselves to say "I'm not with them."

Whatever you do, don’t build a way to interact with AWS services

If you fall into the trap of building a PaaS, you're effectively trying to build a better AWS. They will use their operational efficiency to kick you into the dirt.

This is what happened to RightScale, which started off as a sensible way for humans to interact with the EC2 service. Then the native EC2 console improved, and now there are more people who haven't heard of RightScale than those who have.

Bottom line? Do what AWS is bad at

If you’re trying to build a better AWS, you’ll fail. If you’re attempting to run some software under the thesis “we built it so we’re better at running it,” watch out.

If you’re offering something that aligns with competencies AWS is bad at, you’re probably onto something.

And if you’re looking to make fun of AWS every week, you can always start a newsletter.

But be forewarned: They’re getting increasingly good at this by launching products that are most likely jokes to begin with.

Do you ever find yourself wondering “what the hell is happening with the Internet?” The folks at ThousandEyes recently launched a new weekly show answering exactly that. Co-hosts Angelique and Archana deconstruct the week's most disruptive outages, interview industry thought leaders to discuss the headlines, and share data quantifying just how bad things got across ISPs, cloud provider networks and collaboration app networks. Check out this week’s episode of The Internet Report, featuring Alan Mauldin from TeleGeography, and don’t forget to subscribe to get new episodes in your inbox every Monday at 6pm PT. Sponsored