AWS has been a leading innovator, offering flexible, scalable and affordable hosting for cloud workloads. However, a HANA production environment poses some special challenges. Here are a few factors to consider when running SAP HANA on AWS.
The State of the Public Cloud
The qualities that make SAP HANA innovative can made it challenging for the public cloud. HANA is an in-memory database, meaning your entire landscape is stored in RAM and only backed up on disk. This makes it very fast, but it also means that HANA requires more memory and throughput than a traditional landscape. Similarly, the customizability of HANA comes at the expense of careful management. The landscape requires daily maintenance, regular tuning and thorough testing for upgrades.
Factor in the relative newness of HANA, and it’s not surprising that SAP HANA on AWS was mostly confined to testing and development until fairly recently. Amazon was certified to run HANA One production 2012, but businesses were confined to small landscapes until X1 Instances were made available in 2016.
However, public cloud HANA adoption has been gaining momentum, in part due to SAP’s cloud-first strategy. The company has offered a fleet of new services, partnerships and integrations, giving customers more choices and better incentive to move to the cloud.
The public cloud has driven this growth with continual improvements: bigger instances, greater customizability and automation, improved stability and better third-party support. Tenants are also becoming more comfortable using cloud services for mission-critical applications they previously kept onsite. It’s getting harder to justify the cost of running your own data center, and many companies see SAP AWS as a compelling alternative.
That doesn’t mean moving to the cloud is a one-size-fits-all solution. Some organizations have gone all in on the public cloud, but others have decided to move testing and development, while keeping production on premise, or have chosen to harness SAP AWS as part of a multi-cloud strategy. With more choices, finding the right cloud strategy for your company can be a major challenge.
End of The Public Cloud vs. Private Cloud Wars
There have been two competing narratives about the cloud. One was that the public cloud was going to take over completely. Tech journalists loved this one — disruption is their bread and butter. The idea was simple enough: as the public cloud gets smarter, cheaper, safer and more automated, there’s eventually not going to be a case for using anything else. Private cloud was dying, on-premise was almost dead, and public cloud would reign supreme forever.
The opposing idea was that there were certain things you just couldn’t do on the public cloud. Sure, some highly-scalable applications and development workloads worked well, but you could never reliably move SAP HANA production to AWS. Either it didn’t have the throughput, it lacked reliability and configurability, or the support wasn’t there.
It turns out both stories were wrong. All those “death of the private cloud” stories that were everywhere in 2016 have since disappeared, and the private cloud has thrived. The next generation cloud has even brought traditional public cloud benefits like scalability and automation to the private landscape. But on the other hand, the public cloud has gotten better too. And traditional public cloud weaknesses like the lack of vendor support have been handled by the market, with application hosting providers, cloud integrators and others moving in with services that are a lot like the private cloud.
So if you can meet your affordability and scalability needs in the public cloud, and you can meet your configuration and managed services needs in an SAP AWS landscape, what’s the best option for your company? Well, there’s no single answer. The same factors that make it easier to run a usable cloud landscape make it harder to create an optimal cloud strategy.
SAP AWS — Signal and Noise
With SAP HANA on AWS (or any other public cloud) you’re essentially buying infrastructure. As AWS says in its SAP FAQ, “AWS manages the physical infrastructure up to the virtualization layer. The operating system and any SAP applications and databases running above the virtualization layer are managed by the customer.”
To facilitate this, AWS partners with a range of SAP consultants and managed services providers. The tenant needs to work with a partner who is SAP certified and part of the AWS Partner Network. That network includes a wide range of Consulting Partners with different skillsets in building and managing an SAP landscape. It also has Technology Partners selling a wide range of products, from security solutions to development platforms, to tools to monitor and manage your SAP landscape.
What that means is, even if you go in committed to managed SAP HANA on AWS, there are many different ways you could divide up the task. You could get a single managed services provider to implement and run your whole landscape, or hire one organization to build your SAP landscape, a different one to manage Basis, a third provider to implement and run a security service and a fourth to provide disaster recovery.
When you include the multi-cloud and hybrid cloud options, the picture gets even more complicated. Some AWS SAP partners have experience and certification in running onsite infrastructure and multi-cloud landscapes, while others don’t. And everyone is going to be selling you their way of doing things, which can make finding the right partner an even bigger challenge. Here are some considerations to help you separate the signal from the noise.
SAP HANA on AWS
- Break and Fix vs. Proactive Service: SAP HANA has become more commoditized than ever before. SAP has begun to offer a HANA-like SaaS with the S/4HANA Public Cloud, and both SAP and vendors have begun to market pre-installed SAP solutions and services with limited customizability and support. There are situations where companies can get good value out of this approach. Some SMEs need little customization, and can save cost by plugging into a stock version of SAP HANA on AWS.The problem starts when SAP managed services are commoditized — particularly production. Instead of paying for highly-skilled experts who can get it right the first time, some vendors outsource their work to whatever offshore provider can do it most cheaply. They end up doing break-fix IT. Instead of doing SAP performance tuning ahead of time, they wait for system performance to degrade. Rather than monitoring the SAP landscape to catch small glitches quickly, they wait until those problems start to impact end users.
This approach actually takes more work than proactive IT, but some vendors just don’t want to pay for SAP experts. Others simply don’t have a mature enough approach to managed services to understand how to do SAP right. For the tenant, however, it’s incredibly expensive. Gartner estimates the average cost of downtime is $5,400 per minute, or $324,000 per hour, and frequent slowdowns can be even more costly. When the TCO of private SAP HANA cloud runs around $290,000 for three years, a vendor who cuts corners isn’t worth it.
To choose the right partner for SAP HANA on AWS, you need to look at their client management model. Will they have a team dedicated to maintaining and tuning your landscape, or will they just queue up maintenance jobs for whoever happens to be around? If there’s a problem with HANA in the middle of the night, will you be able to reach someone who can help, or will you be routed through an escalation-based help desk while your business slows to a crawl?
- Vendor Portfolio: SAP HANA on AWS might be the end of your hosting search, but it’s not the end of your IT journey. You’ll need to do regular upgrades, add new applications and even reengineer your landscape from time to time. You’ll face new security challenge and compliance needs as your company grows.And for many companies, AWS SAP is just one component of a multi-cloud strategy. You may have low latency, data residency, performance or other needs that make a hybrid cloud a better choice, or need to adopt a hybrid strategy temporarily as you’re migrating offsite.
Choosing a managed services partner with broad technical competencies lets you adapt to changing needs more effectively and strategically than working with a large portfolio of specialized partners. This is especially true during SAP HANA cloud migration and other periods of digital transformation.
During a technical implementation, you’ll need to work with all stakeholders to develop a plan that meets the business needs of your workers, the strategic needs of management, and the technical needs of IT. There will be multiple stages of migrating SAP components, hooking them up to external systems, and testing and debugging them to prepare for the final migration and go-live. While you’re doing that, you’ll need to be running your onsite landscape, applying patches and fixing any problems it runs into.
All your different teams will need to stay in touch with each other so that changes made in the old landscape don’t cause unanticipated problems in the new one. You may also have to adopt new software, open new offices or have other unanticipated complications that need to be factored in. And all the time, your landscape will be growing.
Then, on go-live, you’ll have to rollover the old system to the new one, with everything timed out perfectly to minimize downtime and ensure a successful launch. You’ll need to ensure everyone has the proper access and knowledge to begin working as soon as the system goes live, which means training users beforehand. Your team will have to tweak and tune the system to make sure all the pieces work together flawlessly. And you’ll need to coordinate all those efforts with your security, SAP GRC, technical monitoring, support and disaster recovery teams.
Now, imagine doing that when you have separate vendors to:
- Service your onsite hardware
- Plan the migration
- Takeover Basis in the new landscape
- Plan test and deliver disaster recovery
- Handle security services
- Run GRC
- Infrastructure Competency: Even in a virtualized cloud like AWS, SAP HANA is sensitive to hardware and network performance and configuration, and you can’t fix problems by just spinning up more compute. This can pose challenges — particularly in a hybrid cloud environment, where the stability of your system depends on multiple, independent networks that don’t come with solution-wide monitoring capabilities. You need a partner with good application performance monitoring capabilities and the right tools for the job. Symmetry uses ScienceLogic to monitor SAP HANA, because it was designed around the challenging needs of hybrid landscapes. If a particular application slows down or a region is having connectivity issues, we don’t have to frantically flip through local monitoring tools to find the issue — we can see everything from a single pane of glass, which means we can quickly isolate and fix the problem.
Another asset we have is experience running our own private cloud. Like any platform, AWS is going to have hiccups from time to time. When it does, you need a managed services provider who truly understands what’s going on immediately, and can react before a local glitch balloons a major regional outage. Because we have experience running our own hardware and networking, we can see things that other providers would miss.
SAP HANA on AWS: Get It Right
Ultimately, SAP AWS is just a host. It can affect factors like performance and cost, but it doesn’t determine how successful your overall SAP solution is. Wherever you decide to host SAP, Symmetry can help you create the right SAP HANA landscape for your company, backed up by unparalleled experience and high touch customer service.