Listen to post:
David Heinemeier Hansson lays out the economic case for why application providers should leave the cloud in a recently published blog post. It’s a powerful argument that needs to be heard by IT vendors and IT buyers, whether they are purchasing cloud applications or SASE services.
Hansson is the co-owner and CTO of 37Signals, which makes Basecamp, the project management software platform, and Hey, an email service. His “back of the napkin” analysis shows how 37Signals will save $1.5 million per year by moving from running its large-scale cloud software in the public cloud to running its cloud software on bare-metal hardware. If you haven’t done so, I encourage you to read the analysis yourself.
Those numbers might seem incredible for those who’ve bought into the cloud hype. After all, the cloud was supposed to make things easier and save money. How’s it possible that it would do just the opposite?
The cloud doesn’t so much as reduce vendor costs as it allows vendors to get to market faster. They avoid the planning, deployment time, and investment associated with purchasing, shipping, and installing the hardware components, creating the redundancy plans, and the rest of what goes into building data centers worldwide. The cloud gives vendors the infrastructure from day one. Its elasticity relaxes rigorous compute planning, letting vendors overcome demand surges by spinning up more compute as necessary.
All of which, though, comes at a cost — a rather large cost. Hansson realized that with planning, an experienced team could overcome the time to market and elements and elasticity requirements without the expenditures necessary for the cloud:
“…The main difference here is the lag time between needing new servers and seeing them online. It truly is incredible that you can spin up 100 powerful machines in the cloud in just a few minutes, but you also pay dearly for the privilege. And we just don’t have such an unpredictable business as to warrant this premium. Given how much money we’re saving owning our own hardware, we can afford to dramatically over-provision our server needs, and then when we need more, it still only takes a couple of weeks to show up.
The result: enormous capital savings (and other benefits).
From Productivity Software to Productive SASE Services
What Hansson says about application software holds for SASE platforms. A SASE platform requires PoPs worldwide. Those PoPs need servers with enough compute to work 24×7 under ordinary occasions and additional compute needed to accommodate spikes, failover, and other conditions.
It’s a massive undertaking that takes time and planning. In the rush to meet the demand for SASE, though, many SASE players haven’t had that time. They had no choice but to build out their SASE PoPs on public cloud infrastructure precisely because they were responding to the SASE market. Palo Alto Networks, for example, publicly announced their partnership with Google Cloud in 2022 for their ZTNA offering. Cisco announced its partnership with Google for global SD-WAN service. And they’re not alone. With the purchasing of cloud infrastructure, those companies incur all the costs Hansson details.Inside Cato Networks Advanced Security Services | Download the White Paper
Which brings us to Cato. Our founders started Cato in 2015, four years before SASE was even defined. We didn’t respond to the SASE market; we invented it.
At the time, the leadership team, which I was fortunate enough to be part of, evaluated and deliberately avoided public cloud infrastructure as the basis for the Cato SASE Cloud. We understood the long-term economic problem of building our PoP infrastructure in the cloud. The team also realized that owning our infrastructure would bring other benefits, such as delivering Cato SASE Cloud into regions unserved by the public cloud providers.
Instead, we invested in building our PoPs on Cato-owned and operated infrastructure in tier-4 data centers across 80+ countries. Today, we continue with that philosophy and rely on our experienced operations team to ensure server supply to overcome supply chain problems.
High Costs Mean a Choice of Three Rotten Outcomes for Customers
Now, customers don’t usually care about their vendors’ cost structures. Well, at least not initially. But when a service isn’t profitable because the COGS (cost of goods sold) is too high, there’s only one of three outcomes, and none are particularly well-liked by customers. A company will go bankrupt, prices will grow to compensate for the loss, or service quality will drop.
Those outcomes are improbable if a vendor sells a service or product at a profit. The vendor may adjust prices to align with macroeconomics and inflation rates or decrease prices over time, sharing the economic benefit of large-scale operations with your customers. Or the vendor may evolve service capabilities and quality to meet customer needs better. Regardless, the vendor will likely be the long-term solution enterprise IT requires for networking or security solutions.
The Bottom Line Should Be Your Red Line
Using public clouds for large-scale cloud services allowed legacy vendors to jump into the then new SASE market and seemingly offer what any enterprise IT buyer wants – the established reputation of a large company with innovation that is SASE. It’s a nice comforting story. It’s also not true.
Building a SASE or application service on a cloud platform brings an excessively high COGS, as Hansson has pointed out. Eventually, that sort of deficit comes back to bite the company. Sure, a company may be able to hide its losses for a while. And, yes, if the company is large enough, like a Palo Alto Networks or Cisco, it’s not likely to go out of business any time soon.
But if the service is too expensive to deliver, any vendor will try to make the service profitable – whether by increasing prices or decreasing service quality – and always at the customer’s expense. Ignoring such a glaring risk when buying infrastructure and purchasing from a large vendor isn’t “playing it safe.” It’s more like sticking your head in the lion’s mouth. And we know how well that goes.