--- title: "The Great Lie" id: "10648" type: "post" slug: "the-great-lie" published_at: "2021-07-21T14:30:00+00:00" modified_at: "2022-02-03T20:12:32+00:00" url: "https://www.lastweekinaws.com/blog/the-great-lie/" markdown_url: "https://www.lastweekinaws.com/blog/the-great-lie.md" excerpt: "There's a universal lie that technical people believe across the board. 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.\"" taxonomy_category: - "Uncategorized" taxonomy_post_tag: - "Industry" --- 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](https://martinfowler.com/bliki/TechnicalDebt.html) 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](https://aws.amazon.com/savingsplans/) 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](https://aws.amazon.com/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®](https://www.lastweekinaws.com/blog/machine-learning-is-a-marvelously-executed-scam/) , because this is AWS we’re talking about here. It launched [Amazon SageMaker Savings Plans](https://aws.amazon.com/savingsplans/ml-pricing/) , 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](https://www.lastweekinaws.com/blog/the-key-to-unlock-the-aws-billing-puzzle-is-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. by Corey Quinn Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure. ## More Posts from Corey [Back to the Blog](https://www.lastweekinaws.com/blog/) [https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) ### [Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […] [Read More about Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) ### [Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […] [Read More about Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ### [S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […] [Read More about S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ## Get the newsletter! Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark. "*" indicates required fields