#128 - 40%, 50%, 60% – The True Cost-Saving Potential in the Cloud

Great to have you back for a new episode of insights! My name is Joubin Rahimi and joining me today is Marc Achsnich, one of our Fellows at TIMETOACT GROUP, also seen here and responsible for synaigy's Managed Service and for synaigy's customers. Hi Marc. Hi Joubin.

We picked a topic that isn't the classic hype topic. No? Well, I'd say cloud, sovereignty, AI is such a hype topic, but cost isn't a hype topic, it's a perennial favourite. And with the current economic situation in some sectors, that's only going up further. How can I cut costs? On one hand, and on the other, actually deliver more too. Digitalisation is the topic. And then I might have lower budgets. I've got SaaS providers raising their prices. That's incredibly difficult for IT directors, CIOs, to move the right steps forward. But I know, word on the grapevine tells me you're doing a lot on this front, and we have customer cases that are exactly in that spot and have found ways out, done something there. Is that an anchor point for you to dive in?

We can do that. Ball's on the penalty spot. Exactly. So ultimately, it's simply that there are infrastructure costs that at some point become extremely expensive. And that means we're talking, to put it visually, at some point in the realm of the cost of block-of-flats, which is what infrastructure can cost per month or per year. And then the question is: is it really necessary to keep carrying that huge cost block?

Or can other solutions be found to simply get a nicer

Margin? That keeps rising too. So I have the feeling infrastructure, a bit more added every year, and compound interest makes it expensive if you keep raising it a little every year for six, seven years, after six, seven years that might well be 50% more. Yes, actually the picture is a bit deceptive there. That's also something I'd assumed, but when you look at the statistics, it's actually not the case that, say, AWS and co. keep raising instance costs every single year.

That's actually not the case. They do put a lot of effort into keeping them stable, but there are still nuances where this happens. For example, this year it came out with AWS's Lambda Services, it's called Cold Start. That used to be free. That's no longer the case. AWS itself advertises that most people don't even notice, i.e. of 1%. I've read studies that talk about 20% higher costs. But it's also the case that alongside this you also have vendor lock-in specific costs. One of the nice examples is simply the acquisition of VMware by Broadcom. For instance, there's Syspe, which complained that they were charged around a 1,500% price increase, because they simply introduced a different pricing model from one day to the next. And that can quickly lead to you suddenly facing extremely big problems.

And what's the way out of that? How do I proceed then?

It depends on how far you've already manoeuvred yourself into a vendor lock-in. We actually have use cases with clients too. There you're talking about a high six-figure sum just to buy your way back out. And on that basis, the question is: if you buy yourself out like that, does it then become cheap enough on the other side to still be worthwhile? So what does "vendor lock-in" mean in this case? Vendor lock-in means that when you use services from providers that seem very convenient at first glance, but on closer inspection have restricted you so much on that basis that you can no longer get out. So, for instance, if I use the Lambda Services.

Exactly. Lambda is one of the examples. Right, so Lambda is a classic example. On the other hand, to stay with AWS, there are databases that are simply AWS-specific databases. In this case, that's Aurora. It can have very, very good advantages, and there are also points where you'd say that accounts for the extra percentage points that are actually worth it, but you could just as easily do it on AWS with MySQL as RDS instead. Then you'd have less of that migration part, perhaps. And how can a company now bring its costs down? What options are there for that?

On the one hand, it's a question of which strategy I have. If I have a pure single-cloud strategy, then I can look at, for example, if I'm on Azure, there are different ways I can improve my infrastructure on Azure. That means you get nuances that can be achieved differently. For example, you can also take Azure Functions, assess whether that's a cost driver, and then replace it with Kubernetes, for instance. That's how you achieve results. You can move towards savings plans to bring prices down. That means there are a lot of percentage points there. You can reduce your costs from that hyperscaler by up to 40, 50%. And then it's the case that from that 40, 50% you could actually save a further 60% on top, if you move from a single strategy to a multi-cloud strategy, or simply switch hyperscalers entirely.

How much effort is involved in switching hyperscalers?

Well, that goes... It depends. So ultimately the question is: how much infrastructure do you have there? We have use cases where a transition takes the next three years. That's millions in costs, which then in turn pay for themselves again over further years. Is there a rule of thumb for how much cheaper it can be if you move to a different platform? For example, we calculated this with OVH. There are different types of cloud, be it a bare-metal cloud, a public cloud, a private cloud. And there we built a use case for ourselves, a genuinely virtual shopping basket, a fictional environment that isn't small either. That means we assumed 100 applications and arrived at the point where, with a complete migration from a hyperscaler to OVH, we can save 60% of the costs.

At list price level, then, is that right?

Exactly, at list price level, or indeed even against the planned savings prices. That means, ultimately, when you have very, very large infrastructure costs, at some point an individual price book opens up with the hyperscalers too. But you'd first have to get to that level. So on that basis, we first compared the standard publicly available prices.

And what would be the next sensible step that listeners and viewers could take now if they say: "I want to take a closer look at this"?

We've written a whitepaper for that. Exactly. What's in it, then? The whitepaper first shows why it's important to give this some thought. It shows what OVH does differently, because ultimately OVH is one option for how this can work. We show the portfolio that's possible, how it's possible, and then at the end we show a sneak peek at what other options exist too, because it doesn't always have to be full-power OVH. For example, it could also be a first attempt at multi-cloud. That means you don't have to go all in straight away, but perhaps just move the expensive storage, the database, or something else.

Knowing our whitepapers, they're all totally valuable. And knowing our sales team, you do enter your details, and yes, we will call. But we're always happy to do that, and do give us feedback: did you read it? What do you still feel is missing? What other helpful additions could we make to expand it? Because ultimately we're not writing this for ourselves, but for those who'll use it later, so for you. So, thanks for the insights and for the refreshing chat. And thank you for watching, and download the whitepaper.