FinOps and SAP: Part 3. Main cost drivers.

After explaining what FinOps is and why it is valid from SAP perspective, I gave you some tips on how to include SAP SMEs into your company FinOps practice. Today, let’s see what are the main cost drivers that contribute to SAP being such a pleasant workload to optimise.

SAP is IaaS. Nothing less, sometimes more 😉. Regardless of the hyperscaler we choose, we end up with a bunch of VMs and storage underneath, on top of which the application layer is built (sometimes covered by another layer, such as SAP RISE).

Knowing that we’re dealing with the most basic cloud resources, let’s define the main cost drives for every SAP system. In other words: let’s see what do we really care about when thinking about FinOps for a SAP system deployed in the public cloud (GCP in specific).

• Virtual Machines: Which are really nothing more than a specific amount of vCPUs and memory.
• Block Storage: Persistent Disks attached to the VMs. A small percentage of those will serve as boot disks (used by Operating Systems), while the majority of disks will be used to store SAP-related files (database & application related).
• Object Storage: Google Cloud Storage, used mostly for backup&recovery purposes.
• NFS: Used for SAP technical purposes such as providing transport filesystem, shared /sapmnt and others. Optionally, used for other reasons, such as file-based interfaces.
• Network related: mostly egress traffic, which starts to play a role as soon as any traffic flows between the systems.
• Licensing: premium operating systems (for SAP Netweaver or SAP HANA) and SAP licenses.
• Currency exchange rates, if applicable. It’s definitely not a technical resource 😉, but if we operate using non-USD currencies, fluctuations of local-to-USD exchange rates can impact our cloud computing bill significantly. Sure, in most cases you’ll be billed in your local currency, but the under the hood, the prices will be charged in USD and only converted to your local currency based on the rates published by leading financial institutions. There are means to secure a fixed exchange rate if desirable (such as foreign currency accounts, forward exchange contracts etc), but since they’re strictly related to finance, they will not be explained further here.

That’s not a lot, isn’t it? Might even sound too simple… but it starts to get a bit more complex when we dive deeper into details.

First and foremost, each of the resources have few dimensions to look at. For example, Virtual Machines are about machine family, CPU generation, size, location and a discount plan. Typical enterprise might have 100+ VMs for SAP workloads, each with unique requirements and settings. Every VM will have multiple Persistent Disks attached, potentially differing in type and size. Three or four Persistent Disks per VM on average… 100 VMs in total… that’s 300-400 unique combinations, just for Persistent Disks, which are definitely not the last aspect we need to care about… Hopefully, you now see there needs to be some kind of framework and governance over this whole process (I did mention it’s all not static, but rather slowly evolving, didn’t I? 😉).

Object Storage, NFS and network are much simpler, although some planning is required there as well. When High Availability and/or Disaster Recovery is also considered for selected systems, the complexity is elevated to a higher level.

But overall, that sounds manageable… and it is, so why am I suggesting to include SAP into a long-term FinOps practise, rather than setting up everything once, in advance, even before the migration from on-premises happen? This way, we would have a clean start and a good baseline for any adjustments needed in the future. Well, the thing is that I’ve never seen it all done perfectly from the very beginning. Despite all the sizing guidelines and best practices, systems are often migrated 1:1 in order not to introduce additional risks to the migration process. If a Partner company is responsible for a technical migration part, they don’t really have any incentives to optimise the architecture too much. It’s quite the opposite: Parters tend to play it safely (and they have good reasons to do so), so in the end it’s the Customer that is left with a bunch of SAP systems that are functioning just fine after the migration, but they’re far from being deployed in an optimal manner. That’s when an iterative process of adjusting it all bit by bit, starting from nonproductive systems and slowly implementing the adjustments further starts. This is when new requirements start to pop up and previous assumptions slowly change. This is when FinOps get really handy. Especially that it’s not about spending less; it’s about spending wise and bringing down the Unit Cost of providing services, while still growing resources as needed from business demand perspective.

I think I did not surprise anyone with the main cloud cost drivers for SAP systems. It all looks easy (one might even think it’s too easy), but as usual – it get’s a bit more complex when decisions need to be made and actual implementations are executed.

In the next article, my aim is to guide you through the possibilities to cost-optimise SAP systems running in Google Cloud Platform.