Cloud computing offers scalability, flexibility, and resiliency to support for mission-critical workloads. But is it the right choice for you? Learn the most relevant factors to consider.
Cloud computing is now ubiquitous and fully comprehensive.
Today, all major cloud providers like AWS, Azure, and GCP offer scalable and reliable solutions that can run most business applications, including critical ones and even those that require specific infrastructure certifications such as SAP HANA.
Moreover, many leading software providers are favoring public cloud deployments over more traditional on premises or even private cloud deployments, advocating the flexibility and efficiencies that come with them. A prominent example is SAP with their RISE initiative for S/4HANA. No wonder it’s easy to get lost in the cloud buzz and think that public cloud is the best and only option for any application.
However...
"Just because you can do it doesn't mean you should." ― Hanya Yangihara, A Little Life
Moving to the cloud can lead to a variety of potential benefits, and that’s why companies do it. Increased agility, shorter time to value, flexible scalability, better resource allocation, pay-per-use or existing data center real estate business are some of the well-known drivers for moving workloads to the public cloud.
Initially, reduced TCO was also among the expected outcomes. But now, many customers have come to realize that this may not always be the case; and in fact, a public cloud deployment can prove more expensive in the long run.
The financial benefits of the cloud are usually a result of switching to OPEX/pay per use from a traditional CAPEX model, and the positive impact that this can have on the balance sheet. But I’m not a finance specialist so let’s go back to the technical discussion.
In order to make an informed decision, the tradeoffs and potential drawbacks of moving to the public cloud should be an integral part of your decision process too. In my opinion, these are the most relevant ones when it comes to business-critical applications:
1. System entanglement (i.e., integrations)
Mission critical applications are neither standalone nor monolithic. They are deployed in a multi-tier fashion (database – application – presentation) and exchange information with many other systems. Therefore, before moving just one of the 1,000 pieces of the puzzle to the cloud, the implications need to be evaluated.
How are the interfaces going to work if I have one system in the public cloud and another one on premises? For example, the ERP system in the cloud and the data warehouse on premise? The database tier in the cloud and the application tier on premise?
That’s probably not going to work optimally, as all the interfaces may need to be identified and adapted, tuned for the cloud, and even additional network infrastructure provisioned to minimize any undesired latency. Service response times may be impacted if a query needs to go from an on-prem app server to a cloud SAP HANA database, and back on premises to show the result in the presentation layer, even worse if some other satellite systems need to be accessed besides the main database, for example a CRM system.
This is what we call RFCs or Remote Function Calls in SAP architectures and their individual response time is a critical contributor to the overall response time.
2. Increased scope
Because of this entanglement, customers may find that if they want to move a key application to the cloud, like their ERP system, they actually need to move the full environment as a whole, with all the tiers and integrations.
This is not going to be simple or cheap, so even if savings are expected as a result of a cloud adoption, these savings could be offset by the wider project scope: more systems to migrate equals more complexity and higher spend. I have personally seen situations like this where customers initially considered migrating their SAP ERP database from Oracle on premises to SAP HANA in the public cloud, and systems integrators wisely recommending to migrate the full landscape (involving tens of SAP instances instead of just one, along with hundreds of VMs) in order to keep the coherence and performance of the environment. A smaller project can quickly become a large, expensive undertaking.
3. Customization
Functional alignment with the business requirements is also a sticky point.
Most clients use customizations that need to be kept as they serve the business perfectly. In the public cloud, those customizations may not even be possible, and the deployments may need to start from scratch instead of migrating the work and maturity achieved throughout the years.
In some situations, starting from scratch can be a desired outcome in order to simplify, standardize, and clean up old code. However, customers may lose some vital functionality, or may need to learn new ways to customize the application using cloud APIs and services.
When it comes to SAP, if customers decide to move their ERP to the public cloud under the RISE umbrella, they will no longer be able to modify the code the old way, they will have to use SAP BTP (Business Technology Platform). That’s a major change that needs to be evaluated in detail before moving to the public cloud. Also, SAP public cloud deployments are typically for brand new, Greenfield implementations only. Brownfield migrations that include customizations are not possible.
4. Service availability
When it comes to mission-critical applications, SLAs are crucial.
Most cloud providers offer less than three-nines availability by default, which is rarely enough for essential applications. Therefore, customers need to implement a high availability (HA) and disaster recovery (DR) setup in the cloud, and request shorter RTO/RPO options, to reach at the very least three, if not four or more nines of availability.
HA/DR in the cloud is not different from on premises in the sense that redundant zones, hardware, and clustering are needed and will be reflected in the total solution price. There are no savings by implementing HA/DR in the cloud versus on premises. HA/DR is going to add to the cost, which can break the cloud TCO.
5. Your business in someone else’s hands
Last but not least, control should be another major consideration.
By moving mission-critical applications to the cloud, you are basically handing your business and data to someone else, and even if there is a contract between both entities, well… you never know.
The hyperscaler may be hacked and lose your information. They may have a major outage and shut down your business for hours. They may need to prioritize what services to restore when resources come back online, and if they come back in a degraded state and cannot serve every customer, you may not be on their priority list. And yes, they may pay you penalties in form of credits if they break the SLA, but that’s not going to help to recover your business, including lost reputation and even legal consequences as a result of service unavailability or data loss. The chances for these situations may be slim, but public cloud outages have already made headlines several times.
Security is also another concern, especially as data is going to be outside your organization and in some cases shared with other customer’s data in a typical multi-tenant public cloud deployment.
Hyperscalers implement high levels of security so protection is going to be high, however, exposure is going to be high as well and as a result, the overall risk of leaks or attacks may be increased in the public cloud versus keeping your data on premises or in a private cloud within your company boundaries.
Risk is a factor of exposure and not only protection (did you ever wonder why UNIX systems are rarely hacked, if ever? Among other reasons, because they are less exposed than Linux and Windows ones).
To cloud or not to cloud?
If after evaluating all of the above, an informed decision is made and a public cloud deployment for mission critical is deemed to be advantageous for your business… by all means, go for it! The cloud is ready and can support you.
Now, if you still have doubts, you like the cloud but are unsure if you can accept the tradeoffs, you should consider a private or hybrid cloud deployment.
Going back to the SAP RISE example, they do offer two other alternatives as well:
- RISE Private Edition (hyperscaler private cloud)
- RISE Private Edition—Customer Datacenter Option (with a customer-owned datacenter or co-location). SAP doesn’t promote these two options as much as the public cloud so make sure you ask SAP about them.
Alternatively, and for any mission critical workload including SAP and others (Epic, Oracle, SQL Server etc.), HPE Greenlake is an excellent solution for customers that love the cloud concept but are not ready for the tradeoffs.
HPE Greenlake brings the cloud to you, either in your own datacenter or a co-location if you plan to exit the datacenter. Furthermore, for hybrid deployments, the co-located datacenter can be adjacent to a public cloud datacenter, therefore minimizing latencies and other potential issues.
It’s great to have options.
Remember that even if you can do something, it doesn’t mean that you necessarily have to do it.
To learn more, visit our SAP HANA solutions page.
Isabel is a multicultural SAP solutions architect with over 20 years of experience in mission critical and SAP architectures in Europe and North America. A native of Spain, Isabel joined HPE in her home country before moving to the United States a decade ago. Isabel has performed multiple roles in mission critical, ranging from support engineer to field presales and her current position as SAP Competence Center solutions architect. Isabel has a bachelor’s degree in electronic physics. Connect with Isabel on LinkedIn!
Compute Experts
Hewlett Packard Enterprise
twitter.com/hpe_compute
linkedin.com/showcase/hpe-servers-and-systems/
hpe.com/servers
ComputeExperts
Our team of Hewlett Packard Enterprise server experts helps you to dive deep into relevant infrastructure topics.
