Things will change. Things will have to change.
In March 2009 I wrote one of the most popular blogs I’d ever written for the Centiq website. In short, it was a description of how to configure IBM BladeCenter switches in conjunction with the Linux bonding driver so that together they could handle link errors in a consistent way. At the time, a colleague and I were locked in a silent battle for the most popular blog on the website, and this one ensured I was on top for a long time. Unfortunately, I no longer have a copy of the post and even https://web.archive.org/ hasn’t managed to preserve it. The loss of this blog is a disappointment as I was planning on reading it prior to writing this post as a reminder of just how much the business has changed over the years.
Back in 2009 most of my time was taken up with designing, building and implementing hardware-based solutions for SAP. Now, in 2020, on-prem hardware takes up a lot less of my time. Centiq’s focus is now squarely on deploying SAP on the Microsoft Azure platform.
It sounds like a straightforward transition, doesn’t it? Replace hardware with Infrastructure-as-a-Service. Indeed many system integrators and other SAP service providers are doing just that, bringing old ways of doing things to the public cloud. Many businesses have already found out that picking up an SAP landscape ‘as-is’ and dropping in into Azure doesn’t deliver the benefits of the cloud.
Cloud computing offers the impossible: infinite scalability and flexibility along with lower TCO. Is that impossible?
Yes, it is, if all you do is lift and shift what you already have. Migrating a SAP landscape to Azure should be a transformation. Things will change. Things will have to change. I encourage customers to embrace it. Change is actually good.
Centiq have developed an Operating Model that is aimed at providing customers with an SAP on Azure solution that delivers the best from Azure whilst controlling costs.
Our approach is based on four pillars:
In this blog, I want to explain a little about each of the pillars of our Operating Model, what they achieve and how they work together so our customers get the best possible experience running SAP in Azure.
Standardisation
Most SAP systems out in the wild have grown organically over many years. And while most people who work in IT love standards, we find that most SAP solutions out there are made up of lots of different bits of technology, sometimes with few standards in sight. Common problems are:
- Multiple OS versions and types
- Multiple database technologies
- Many types of backup and backup tools
- Multiple authentication processes for different types of activity
Systems that have grown this way are really hard to support. You need to have a lot of skills and knowledge in many different areas. Managing these systems is like spinning plates. Just keeping the thing running is taking all of your time. And when you’re in that position you’re not pursuing operational excellence, you’re just aiming to keep the lights on.
When planning to migrate a customer to Azure, we start with their current landscape. We want to simplify the new deployment as much as possible. For example, we’d deploy just one OS if possible. The same for databases. The fewer different bits of technology we deploy the faster and better it can be done.
It’s also beneficial to have clear design patterns across landscapes. For example, if you have a three-tier deployment in production, repeat that same pattern for the non-production environments. Then deploying, managing and upgrading each system is always the same. By reducing the number of processes, there are fewer processes to manage and continuously improve (and you should be continuously improving your processes).
By standardising the solution, it can be deployed faster and cheaper. However, the biggest benefit is the longer-term running of the landscape. With fewer technology types deployed the systems are far easier to maintain and therefore, better maintained.
Rationalisation
There often seems to be two different stories about the cost of running in public cloud. On one hand, we hear about customers making massive savings and on the other, we get horror stories about huge cost overruns. They can’t both be right, so which is it? It comes back to our earlier point, you won’t get the benefits of the cloud without making changes.
Rationalisation is about cost control. It’s about making changes to the SAP landscape in order to make it match-fit for Azure.
The first step in rationalisation is to decide how your systems will run when they move to Azure. With traditional on-prem hardware, all systems run all of the time with no regard to whether they are used or not. In public cloud systems, you pay for what you use, so running systems that are not in use can be wasteful. Therefore, in Azure, we categorise systems by their usage pattern and only run systems when they need to be run.
Production systems will, in almost all cases, run all of the time. To lower the cost of an “always-on” system they get deployed as “Reserved Instance”. Non-production systems are generally often only required in business hours, the cost of running these can be reduced by powering them down overnight and at weekends, this is called ‘snoozing’. Other parts of the landscape, such as sandboxes or training systems may only be accessed infrequently and in such cases, other techniques such as ‘on-demand provisioning’ could be used to vastly reduce the cost of their operation. This is a complex area and it’s also one of the most important to get right.
– I could probably write a series of blogs on this area alone, but in the interest of succinctness, I must leave it here for now.
Once we know what and how we’ll run, we turn to the second step of rationalisation, right-sizing. Sizing for Azure is completely different to sizing on-prem solutions. On-prem systems have a shelf life. Most customers will refresh the hardware their SAP solutions run on every three to five years. What size solution to purchase is a tough question. Buy too small and performance will suffer. If you go too big you’ll end up with an underutilised system and you’ll have spent more than you needed to.
To size an on-prem system you need to look at historical metrics. Using this data, you’ll try to predict the size of your SAP landscape maybe as far as five years in the future. It’s a very tricky procedure and the end result is rarely correct!
With Azure, we don’t need to do this. Instead, we right-size. Right-sizing is using the resources that are right for the system today. By right-sizing solutions we’re not paying for resources we are not using. If resources start to become constrained we can simply increase the size of the VM, a very easy task in Azure. If a solution is underutilised, we can reduce its resources and save money.
The mantra for right-sizing is “Increase if you must, decrease if you can”.
For budgeting purposes, it’s still a good idea to look at long term growth trends as this will help predict when resizing events need to occur as well as future costs.
By rationalising how systems are sized and run, you can lower the TCO of your SAP landscape in Azure. For many customers, this may be the single largest change to their SAP infrastructure they have ever undertaken, but it’s an essential step.
Modernisation
SAP has been around for a long time, the initial release was in 1972. A decade later in 1982, the second release (imaginatively named R2) was made available. The pace of change is somewhat quicker today. However, many long-term users, both businesses and individuals, use SAP’s heritage as a reason to keep things as they are. There is sometimes resistance to the simplest of changes. However, to make the most out of SAP on Azure, you must embrace the modernisation of the platform on which SAP runs. You need to start doing things differently.
Modernisation covers many topics and for this blog, I’ve chosen three of my favourites to summarize:
- Patching and updates
- Embracing Azure
- Enhancing Security
Patching and updates
The idea of finishing a large SAP project and then immediately tinkering with it is utter madness to some people, but not to me. After migrating to a new SAP platform, for many, the best thing to do is leave it. Sadly, that is not the correct approach. Any IT system over time becomes less secure and less supportable. Over time, security exploits are discovered and products gradually go out of support. Therefore, it’s not madness to start planning patches for a brand new solution. Patching and updating as a matter of course from day one is the only way your new system will stay new.
Ask yourself, “does this sound familiar?” A new solution is deployed. It took a long time to deploy so nobody wants to change anything, besides, we have enough work to do. A few years go by and the system has never been patched. You’re told by one of the vendors that you need to upgrade a key component, perhaps the OS needs to have a service pack installed or the database needs to be upgraded. If you don’t do this the solution will go out of support.
You dust off the manuals and start googling. You quickly realise that the number of changes required to get to where you now need to be is huge. There is a spider web of dependencies that need to be applied in the right order.
Your rollback plan is to restore from a backup (which you also haven’t tested since go-live!).
You present the plan at the CAB meeting and they are not happy. It’s been raised to senior management and they are worried, it’s a big risk and the downtime required is lengthy.
You have two shots to get it right before production as you also need to run the same updates on the development system and the test system. The development upgrade was awful, but you learned a few lessons and should be able to improve when you do the test system.
The test system upgrade goes OK, but it’s smaller than production and you’re worried you may not get the work completed in the downtime window. Finally, the big production upgrade is upon you. You do OK, you get it done with just minutes of the downtime left. Everyone is happy, everything goes back to normal and nobody ever wants to touch the system ever again, even though that’s how you got there in the first place.
The above is an example of paying technical debt and this was a big payment. Computer systems that are left alone are always accruing technical debt. All of the unapplied patches and updates, all of the service packs and hotfixes. The longer they are deferred the more difficult it is to implement them. Surely, there has to be another way!
Well, there is and it’s super simple. Patch and update frequently. With frequent maintenance, you get shorter downtime windows, lower risk changes and easier, quicker rollback plans. The people who conduct the regular maintenance get better skilled in doing it and also continuously improve the process. The business needs to understand the importance of regular patching and after the process has been proved with a few successful cycles it won’t be hard to get their full support.
When migrating to Azure, don’t leave your new shiny unpatched, start a modern patching policy straight away, or even better, become and Centiq managed service customer and we’ll do it for you.
Embracing Azure
As I’ve already mentioned, simply picking up what you have and placing it in Azure, isn’t going to get you very far. To make the most of Azure you must embrace it and by embracing it I mean looking at every native Azure offering that could be used to replace something in your SAP landscape.
First off, SAP doesn’t support any database-as-a-service offerings for the vast majority of their products, but there are still lots of offerings that make sense for SAP users and I’ve listed some below each with an example use case:
- Azure Backup – native backup of VMs, HANA and SQL database.
- Azure Site Recovery – automated storage replication and disaster recovery
- Azure Files / Azure NetApp files – exported filesystem-as-a-service, can be used to replace NFS and Windows File service (think /usr/sap/trans and /usr/sap/global)
- Azure Blob Storage – Store all of your installation images in blobs rather than file servers
- Azure Monitor / Azure Log Analytics – Single extensible tool for monitoring workloads and Azure.
By embracing Azure in the PaaS and SaaS space, customers continue to simplify and rationalise their landscapes. As an example, let’s look at Azure Backup.
By using Azure backup a customer using HANA or SQL databases can back up their entire estate without installing any additional infrastructure. For customers running other databases, it may be necessary to create some additional file shares to dump backup files into.
Azure Backup can be configured to store data in the local region or also replicate it to a DR region. All this is done on a consumption basis, so you only pay for what you use.
On the other hand, if you were to use a conventional backup tool you might need to perform the following steps:
- Acquire licence
- Design implementation
- Build VM/s
- Install 3rd party backup tool
- Configure 3rd Party backup tool
- Configure Clients
- Manage and monitor backup tool
- Periodically patch and update backup tool
Looking back to standardisation and rationalisation, we can see how adding VMs for all of the areas that can be handled by Azure services is not in our interest. Our landscape would become more diverse and we’d see increased complexity and cost. Embracing Azure’s services allows us to modernise the platform and keep within the principles of our four pillars.
Enhancing Security
The section is not about the pros and cons of public cloud security, that’s been done all too often by many other people and in far more detail than I could ever provide. This section will cover what you can do to enhance the security of your SAP infrastructure in Azure and help make security more visible in the business.
We’ve already covered a major topic, patching and upgrading. A large number of the patches you apply to systems during regular patching will be security fixes. By plugging security holes in this way you reduce the attack surface of your systems. Therefore, you’ll be keeping up to date and increase security at the same time.
Azure Log Analytics provides a fantastic opportunity to collect, audit and report on security events. Azure Log Analytics is another one of Azure’s native services and as its name suggests, it is capable of ingesting various logs, including Windows Server, Linux Syslog and many the logs of many applications.
When activated and configured, it is possible to detect security events such as outstanding patches, unauthorised log-in attempts, changes to configuration and privilege elevation events such as sudo or ‘run as administrator’. Azure Log Analytics makes it easy to report events using push alerts and dashboards.
Ensuring security events are made visible means that action can be taken when an event is detected. In addition, when no events are detected you know that it is because no events are happening and not because nothing is being checked.
Ultimately, modernisation helps you avoid the traps of the past. By embracing patching, no longer will your SAP systems fall behind and drop out of support. By embracing Azure, no longer will your SAP estate include countless supplementary non-SAP systems. And by enhancing your security, you’ll shine a light on to who is doing what on your SAP servers.
Automation
Finally, we’re here, the last pillar. Automation is a thread that silently runs through the previous pillars. Nearly everything discussed in this blog so far can in some way be automated. But, let’s start with the basics.
Building and maintaining an SAP landscape requires lots of interactions with computers. Thousands of steps are required to build infrastructure, configure OSe and install application and database servers. Each interaction, or step, is a chance to get something wrong, to enter the wrong value or choose the wrong option. As we probably all know, humans are bad at these types of repetitive tasks. Therefore, it would be insane to trust a human (or multiple humans) to build a large number of infrastructure assets on which to run an SAP solution, but it happens all the time.
A better approach (the Centiq approach) is to use automation. When building a system manually, you’d usually follow a set of instructions. The same principle applies to automation, however, the instructions are generally referred to as code. The code used for automation systems is generally high-level and reasonably easy for humans to read and write. When the automation tools run the code, unlike humans, they produce the same results each time.
Automation is used to build:
- Azure infrastructure assets (VNet, Subnets, VMs, Load Balancers, etc)
- Configure operating systems
- Install the software and configure software (Netweaver, Databases, etc)
- Configure native Azure services (Azure Backup, Azure Log Analytics, etc)
Using code to build your SAP landscape ensures that the landscape is built consistently. Another advantage of using automation is that the results are repeatable. You can successfully build and rebuild the same landscape many times safe in the knowledge the end result will always be the same. Finally, building from code, once the code is written, means that landscapes can be built very quickly and in parallel. For example, manually, it may take one consultant a day to build a HANA database server. If you need a cluster with two nodes, it would take two days to build both nodes and a third day to configure and test the cluster. With automation, both nodes could be built in parallel and the cluster could be automatically tested all within two hours.
As well as using automation for the build, Centiq also employs automation to increase speed and consistency during the run phase. Tasks mentioned in the previous pillars such as snoozing and patching both benefits from automation to make their execution simpler and less error-prone.
The best way to sum up automation is to say that it means our customers can deploy their SAP landscape in a consistent and repeatable way and do this quicker than the manual process which would be error-prone.
To conclude
When migrating SAP workloads to Azure, you have to think bigger than just moving what already you have. For the best results, aim high.
Steve Stringer, SAP Design Team
