The poor devils that know me understand that I tend to be an old-school, somewhat crotchety individual. Heck, I wish my laptop had the “Turbo” button on it so it could run like my 486 back in the day. I have several pre-formed opinions that are based on many years of experience, and in several cases those opinions are as unyielding as the pop-tart crumbs my kids leave in the back seat of the SUV (true story, those things are tough). It’s an extraordinary time when those opinions get challenged, and leave me somewhat reeling.
One such case happened to me recently, when tasked with migrating a customer’s complete SAP landscape into the cloud (in this case, we partnered with Amazon Web Services (AWS), and it was beautiful, like the first dance at my senior prom, although not as clumsy). Admittedly, when I began said project I was fraught with anticipation of what could happen.
Dear reader… I was wrong.
In this insight, I will do my best to document what I’ve seen from this project, what potential roadblocks you’ll likely see, and how you can consider your potential journey to the cloud for your SAP environment.
If you’ve done a typical SAP HANA Migration (or any other migration utilizing physical, on premise infrastructure), you understand that the sizing, layout, and planning of such architecture tends to be a somewhat arduous undertaking. The effort spent to size, resize, and layout the hardware, as well as the toil spent considering high availability, disaster recovery, and the like, tend to be a herculean project in itself. Not only that, but with SAP (and most other applications) you must size for peak, meaning often a much larger set of hardware than you might otherwise consider.
Cloud offerings tend to combat this by fully virtualizing the infrastructure, depending on the provider. For instance, the larger instances in the Azure platform tend to be singular, purpose-built servers. This allows the “real-time” ability to change your hardware profiles, and significantly reduces the time from procurement to “lights on”. Did you get clobbered by unusual growth this month? Fine, let’s ratchet the server up a notch (within reason). That, my fine feathered friend, is flexibility.
This type of flexibility lends itself well to the project where you’re somewhat unsure exactly where you’ll land in the hardware spectrum. You can move your systems over into a right sized environment, with a little less planning than you would require in a purely physical (or even hybrid physical / virtual) datacenter.
Make no mistake, this is huge. I’ve often been a part of projects where a customer would quite literally spend hundreds of thousands of dollars for a project, but the project went off the rails because the hardware spend increased dramatically (usually because the planning was somewhat lacklustre).
We get how the flexibility of the platforms can adjust how we plan, but what about the day-to-day operations of your SAP environment? Within the last project (mentioned above, customer redacted because I don’t feel like being sued), we literally had to change direction on one of our systems. In this case, we had to move from a traditional database, to a fresh implementation with SAP HANA as the backend. Obviously, this changed our design, requiring a beefier server from a CPU and RAM perspective. In a physical environment, a directional change such as this would’ve cost us not only dollars, but potentially weeks in timeframe (thus even more in dollars) in acquiring and configuring the new hardware to match the specs. Within the cloud based system architecture, we literally had this system configured in one day. In these times, agility matters, folks. Your business tends to be finicky and impatient, and keeping up with them should be much easier. This can, and often does, help.
It’s not all biscuits and gravy
All this said, with the extremely convenient infrastructure that is both flexible and agile, it’s not necessarily the magic bullet for all SAP woes. Some of these challenges are as follows.
You’ll notice that this challenge gets listed first, which is exactly where it should be. When considering cloud based solutions, realize that often, you are setting up a direct connection to the hosted environment. At the risk of sounding too blunt, this should scare the hell out of you. Before you even consider or go shopping for a cloud solution, work very closely with your Enterprise Security team. Ensuring that the network is integrated enough for your SAP environment to be transparent enough, yet isolated enough to ensure security, is critical to implementing the solution correctly. Questions here abound like how the traffic can be encrypted in transit, where the data will reside, who will have access, and things like that. Protection of this should be first and foremost in your mind, lest you become yet another enterprise that was too “free” with folks’ data.
Also, think about how the cloud environment will integrate into your current on premise environment. Authentication and authorization, for instance. How will my environment know you are who you say you are? Do you require integration to an identity provider (such as LDAP or Active Directory), and how does that work? Where does the SAML authority reside? Some of these can even become showstoppers for a cloud migration, and it’s much better that you get these questions out of the way ahead of time.
Backup, High Availability, and Disaster Recovery
With cloud provider offerings, you’re generally receiving the nuts and bolts of your infrastructure. How you use these is entirely up to you. In most environments, there is a nominal amount of hardware redundancy built into the platform itself (i.e. the ability to move the virtual environment to other pieces of physical hardware). Consider that you may have to buy extra space in an alternate datacenter (major cloud providers can generally provide this) for disaster recovery. Also, consider that the hardware redundancy that they are providing might not actually protect you in the case of an operating system mishap, and these happen. Consider offerings, and see if there’s the ability for offsite retention of, say, tape media, or some other media for redundancy. If the cloud provider offers tape backup services, determine how they will guarantee that your data isn’t sharing locations with someone else. Essentially, be acutely aware of the environment where your critical data and systems are going. Do the research, you’ll be glad you did.
One of the big sales pitches for the cloud, is that it’s based on hardware that you’re using and NOT dormant, or unused CPU cycles. Essentially, the argument becomes that you don’t have to size for peak in a cloud environment. This is only somewhat true, so be careful. No matter the provider, they must maintain hardware for your (and everyone else’s) peak. Hopefully these don’t happen at the same time (the cloud provider is counting on it), and the flexibility provided can do its magic, but the provider must still have enough hardware to fit that demand.
You might wonder why that paragraph falls under cost. Well, dear reader, someone is paying for that extra capacity, and it’s you. The benefit here, is that the capacity over and above standard runtime gets shared, so one person doesn’t have to pony up for all of it (like you would in a hardware environment). But don’t make a mistake on that saving. That said, for all its magic, I have seen distinct cases where cloud offerings were considerably higher priced than an on-premise hardware solution.
The moral of the story, dear reader, is be careful and be deliberate. Perhaps if you can avoid being stubborn and set in your ways, who knows - maybe the cloud is for you too!