Cloud Options
Last time we looked at the the options available for deploying SAP HANA On Prem. This time I’m going to focus on the IaaS cloud options. This clearly excludes the SAP Cloud Platform (which is Platform as a Service), but does include the HANA Enterprise Cloud (HEC).
Private Cloud
This is an odd one. The idea behind private cloud is to allow the advantages of public cloud such as scalability, unit based consumption and self service, within a private, dedicated environment. In that case a customer would need to own a large number of HANA systems (appliance or TDI) in advance in order for them to be deployed when needed. This would be very costly.
One of the advantages of moving to the cloud is the shifting of cost from capex to opex. Private Cloud for HANA would require a large investment in hardware and therefore seems unlikely to really take off as economies of scale cannot be achieved whilst dedicated to a customer. To date I have not seen a private cloud for HANA be used in production and believe that economically it would be an unattractive proposition offering few benefits over customer asset ownership.
Public Cloud
SAP have certified a number of public cloud containers for production HANA workloads. The details of the certified IaaS containers can be found here. Certified production systems permit scale up and scale out operation. The largest scale up model provides 2.7 TiB of memory whereas the largest scale out system provides 14TiB (2TiB x 7) of memory. 4TiB systems seem likely to become available towards the end of 2017. Larger containers are available, but are not production certified.
Public Cloud is an interesting proposition in many respects. For an always on service, such as powerful database server, it would often be cheaper to buy a dedicated server and host it privately than to run the same service in the cloud. This is based on operating a HANA appliance on a continual basis, always on. However, IT is rarely so simple. A production server rarely comes on its own. Production systems rely on a whole string of ancillary systems for testing, QA, development, training etc.
Non-production systems, are rarely required 24 x 7. In an On Prem environment you’d rarely power off non-production systems. But in a Public Cloud, this is exactly what you should do. A system that is off will cost you a lot less than one that is on. Therefore, with careful management, the overall environment of systems that support a production service can cost less to run in a Public Cloud with no contract and no loss of performance or functionality.
Other than cost, Public Cloud also offers other advantages. Tools used within the DevOps lifecycle to deploy, configure and re-deploy system work very well in the cloud (compared to Appliances). This helps to solve some of the typical SAP infrastructure issues. For example, the perennial problem of the SAP system refresh can be solved in the Public Cloud. A refresh, could be as simple as pushing a button (that runs a script that installs, configures and and applies the latest production database backup to a new test system), the old test system is just discarded. A further customer benefit is the speed to configure and make available HANA services from the Public Cloud which can be a matter of minutes enabling customers to realise benefits and commence development, testing or analytics within minutes.
Using public cloud not only shifts cost from capex to opex, which can be make it easier for projects to be approved, but in some consumption models has no contractual commitment. Customers can readily migrate between Public Cloud configurations aligned to changing business requirements. Integration to other services, including existing non SAP HANA and Non SAP services can be more readily achieved based on the availability of previous tested and published scripts and templates.
As well as its advantages, Public Cloud also has some issues. First off, Public Cloud is not magic, things still go wrong. Occasionally machines break and stop, sometimes data centres or network connection is interrupted. You still need to implement HA and DR strategies for mission critical applications. You have to make careful decisions about what systems you deploy in the cloud. You should always deploy database and applications in the same cloud to keep latency as low as possible. But you must also consider the flow of business processes. For example, BW systems ETL from transactional systems, often as overnight batch jobs. If BW were moved to the Public Cloud but its source systems remained On Prem, would there be sufficient bandwidth for the ETL jobs to complete in a timely manner? How do you modify existing watch and monitoring processes to include the attributes now added in terms of Public Cloud to provide an end to end view of transactional performance?
HANA Enterprise Cloud
HANA Enterprise Cloud is SAP’s Private Cloud offering. HEC provides both HANA Database and Application Server technologies based on SAP best practices and is aimed at customers running SAP Netweaver applications rather than native HANA apps. HEC is a fully managed service by SAP of both the database and application tiers. It is available as both a multi-tenant offering and dedicated instances. The HEC service includes backups, patching, provisioning, upgrades, restore and recovery, infrastructure monitoring and event detection. HEC also has options for high availability. Within the private cloud, a customer or partner would need to provide these services.
HEC seems largely based on HANA appliance technology. It is a more prescriptive format that Public Cloud so it is not clear if this would allow it to be as flexible as the Public Cloud. It’s also not clear whether systems could be created, provisioned and destroyed with ease, nor is it clear on exactly what it costs to run and store instances.It is not clear if the same Public Cloud flexible contractual commitments to capacity and service apply or whether this can be readily aligned to changing business requirements without penalty.
HEC seems largely focused taking all the pain away from running SAP on HANA to defined SAP best practice. It is an end to end service direct from the vendor so includes attributes that any customer using Public Cloud services would require partner support to deliver if they did not have the native skills and expertise. Unlike the public cloud, it is not 100% clear what it costs or indeed the on-boarding processes and flexibility. However, one can imagine that running on a vendor’s Private Cloud may not be the lowest cost option and may require intermediate steps to enable a migration to HEC from the existing SAP or SAP HANA customer landscape.
Conclusions
HANA, running productively within a Private Cloud, is not a low cost option. It still requires the customer to purchase hardware upfront in order to enjoy the benefits of cloud computing albeit other consumption models do exist. For non-HANA workloads, Private Clouds can be effective. But systems like HANA that require high performance or certified platforms are not well suited and offer limited opportunity for multi-tenant operations and governance.
The Public Cloud offers a variety of containers certified for SAP HANA. These containers cannot scale up or out as far as Appliances currently do. The Public Cloud, when utilised to do so, can easily take advantage of DevOps tools to make deploying and configuring HANA systems much easier. Costs move from capex to opex, often making projects easier to fund with no commitments. HANA Enterprise Cloud is SAP’s Managed Service for SAP Application and HANA servers. Based on Appliances, SAP provides an end-to-end Private Cloud offering to defined SAP standards. Integrating your HEC services to non HEC services remains a challenge whereas this is more straight-forward for Public Cloud and customer Private Cloud services which will have closer adjacency.
(Figures based on SAP certified production HANA workloads using the ‘Certified and Supported SAP HANA® Hardware Directory’. Figures accurate on the date of publication.)