There’s a universal lie that technical people believe across the board. I’m certainly not immune to it — I spread the lie myself multiple times a week. If you’re reading this, there’s a great chance that you have too.
It goes something like this: “After this next sprint ends, then we’re going to pay off all of our technical debt and start doing everything the right way.”
It doesn’t matter where the company is in its technical journey. Perhaps it can’t keep its first computer online because the power to the building keeps flickering, or maybe it has to support customers using an older technology that they wish they could deprecate. It’s almost irrelevant! The company aspires to its idealized technology stack and is convinced that it’s a technical form of Godot. If the team just waits a little bit longer, surely that promised land will arrive.
If you sit down and chat with people about it, they talk sense. Of course they don’t really believe they’re going to convert the mainframe to serverless by the end of the year. Of course they aren’t going to upgrade their framework through six full versions in one fell swoop. Of course they understand that these cloud migrations take time.
But despite what they say, they absolutely buy like this.
Trying to save on AWS while believing the lie
In the days before AWS Savings Plans were announced, convincing The Duckbill Group’s customers to buy Reserved Instances was a colossal chore. “We can’t — we’re on c4 instances but we’re going to upgrade to c5 in a few months.” A quick check showed that the c5 migration had been “a quarter away” for a year or better.
We had to convince people that unless there was a concrete migration plan in place that was going to take effect within the next six months, it made sense to buy one-year reservations. At the time, it was something like eight months to break even. And as we all know, projects always slip.
How AWS still makes customers feel like they lose out
AWS could serve customers better by applying Savings Plans to Amazon RDS and other managed database services far too numerous to list. A lot of customers remember the bad old days of RDS unreliability, so they run their own databases on top of EC2 instances. Some of them would absolutely migrate those workloads to a managed offering now that their reputation has improved, except — you guessed it — they’d be leaving money on the table if they did. They’d be happier customers on RDS, AWS would be able to say nice things about the growth of its RDS services (particularly Aurora), and yet… here we are.
An incredibly foolish thing AWS did was centered in the scam world of Machine Learning®, because this is AWS we’re talking about here. It launched Amazon SageMaker Savings Plans, which are not part of the other Savings Plans offering.
As a result, once again we’re back in the Reserved Instance wild times: Folks doing machine learning on either SageMaker or EC2 aren’t going to be able to migrate to the other due to the economic constraint of abandoning a gargantuan amount of money if they go through with it, because AWS service teams are ineffective at talking to one another. Customers are left with a suboptimal architecture that doesn’t quite do what they want it to, and both customers and AWS remain dissatisfied with the result.
How AWS has made it easier to buy for the current and ideal states
One of the smartest things AWS has done is apply Savings Plans to all instances running in the customer’s environment. Suddenly, customers are able to migrate between instance families without feeling like they’re leaving large piles of money on the table, on a timetable that isn’t beholden to a reservation expiry period.
Another good move by AWS is extending Savings Plans still further to encompass both Fargate and Lambda compute options. If you migrate an EC2 workload to Lambda, you’re going to spend a lot less in virtually every scenario.
The actual economic impact of applying a Savings Plan to Lambda isn’t enough money to move the architectural decision needle. That’s OK, because saving money is (gasp!) not the point. Rather, the point is to ensure that your customer’s evolution isn’t being constrained by artificial payment constructs. As I’ve said before, cost and architecture are the same thing in cloud.
Solutions must work for customers’ current and aspirational tech
For those of us who aren’t AWS, there’s a valuable lesson in here. If you’re selling to companies who are on a technical journey of any kind, you need to tell two stories at once. You have to simultaneously pitch to both where they are today and the aspirational version of themselves they have in their head — which they may never get to. If your pitch only speaks to one of those stories, then you’re in trouble.
Customers who believe they’re on a path out of a data center and into rapidly becoming Netfix-only-better aren’t going to buy a product that only tells a story about their data center environment. Why would they? They’re going to be leaving Real Soon Now, so whatever they buy would go unused.
Conversely, if you sell something that only works in the aspirational version that is years-to-never away, then they’re not going to buy it “until next quarter.”
Anything you sell to technical buyers has to speak to both sides of their story. If it doesn’t, you’re going to struggle in the market — either with a product that’s perceived as having merely a long-tail offering for companies in decline or a product that’s ahead of its time.
The upshot
Regardless of whether you’re attempting to improve customers’ architecture or simply save them money, whatever you sell them absolutely can’t leave them feeling either ashamed for what they’re running today or thinking that they’re just that “one sprint away” from being beyond your ability to help them. Successful companies are increasingly the ones who can tell a story that speaks to both sides of the divide.
