A HANA Native meets a Cloud Native

By 
Frank Stienhans
Technology

Best Practice for running public SAP HANA XS applications on AWS

By 
Frank Stienhans
, posted on
, posted 
May 12, 2016

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

asdsadsadn sldjflsdjf

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

In this post I will describe a best practice for running Internet Facing SAP HANA Native Applications on AWS.

How to do this right?

Someone needs to consider:

  • Security
  • Compliance
  • Data Protection
  • Global Performance
  • High Availability
  • Scalability
  • Cost

SAP HANA is a high value asset which should not be used for commodity tasks; or to phrase it the other way around: A high value asset should be used for high value tasks.

We will therefore look into:

  • Offloading HANA Servers from malicious traffic
  • Offloading HANA Servers from dealing with cacheable data such as HTML, Stylesheets, Javascript, Images a.s.o.
  • Leaving it to the Cloud Platform to deal with questions such as SSL certificates, Load Balancing and DNS management.

AWS Platform Services

Now on AWS there are a number of platform services which can help.

Before we go into those services we need to understand that the 50+ AWS Platform services fall into the following 3 categories.

  • Regional Services
  • Global Services
  • Edge Services

This is not an official categorization, but I found it helpful for understanding.

Regional Services

AWS has at the moment 12 GEO regions. When using any of the services in this category, all data, compute and configuration stay in the selected region unless declared otherwise.

Those services include for example:

  • Amazon EC2 (Virtual Machines)
  • Amazon S3 (Object Storage)
  • Amazon VPC (Secure Networking)
  • Amazon Lambda (Cloud Functions)

Global Services

Some of the AWS services are inherently global, meaning data and configuration is available in all regions (with the exception of the US Gov Cloud and China Regions).

Services where declarations are "immediately" global are:

  • AWS Account (Not a service, but important to understand)
  • Amazon IAM (Identity and Access Management)
  • and I assume: Amazon Route53 - Private DNS (DNS Management for Private DNS records) 

Edge Services

These services live in 55 edge locations of AWS

  • Amazon WAF (Web Application Firewall)
  • Amazon Route 53 - Public DNS (DNS Management for Public DNS records)
  • Amazon Cloud Front (WAN Acceleration & Content Distribution)

Best Practice: HANA Native Application on AWS

In a future post I will describe on how to run HANA itself on AWS.

This section will describe which AWS services can be used surrounding the HANA servers.

An AWS Shell if you will.

[EDGE] Amazon Web Application Firewall

WAF enables filtering web traffic at the edge before the traffic even arrives in the AWS region where the HANA Servers are located.

The WAF policies can be very elaborate, including filtering traffic that does not impose a security risk, but where it is known at Design Time that the HANA application will respond with an error message. Why not serving the error from the edge? If the application has a comprehensive set of REST functions this set of WAF policies should be generated and automatically kept up to date.

[EDGE] Amazon CloudFront

To increase performance of the application and to reduce effective cost store all static web files in Amazon S3 and create a CloudFront Distribution on top of Amazon S3.

If required to enforce export control policies or to GEO restrict originating traffic, then Cloud Front is a good starting point as well.

In theory, CloudFront allows Dynamic Content acceleration (such as the HANA query result). In reality I struggled a bit here, if that capability is used together with HTTPS security best practices. That said the features of the Amazon Web Application Firewall, which can directly integrate with Amazon Cloud Front , might make it meaningful to activate a Cloud Front Distribution, even if CloudFront does not provide an acceleration effect for the retrieved HANA Data itself.

[EDGE] Amazon Route 53 - Public DNS

Route 53 has a "100% Uptime" SLA. OK, nothing is 100% up, but living at the edge, can provide a very long list of 9's - 91 of them to be precise. (This is my own calculation, not a statement by AWS)

The domain registrar can remain where it is, but DNS management should be performed by AWS. This will allow full control, deep AWS integration as well as health and performance monitoring of the HANA Application, validating access from multiple GEO regions at the same time.

[GLOBAL] Amazon Route 53 - Private DNS

Yes, a public HANA service should have a well defined Private DNS approach as well. There are several reasons.

  1. The default DNS records for EC2 instances do not fulfill SAP requirements. This is simple for a single Host - HANA system, but begins to be a bit more challenging in SAP HANA scale out and multi-tiered scenarios.
  2. For HANA High Availability, Scale Up, Hardware Refreshes, HANA Patches and Upgrades, a solid Private DNS strategy is critical as well.
  3. Last but not least for Disaster Recovery (across AWS regions), Route 53 Private DNS is a critical ingredient.

[REGION] Amazon Virtual Private Cloud (VPC)

The first element in an AWS region that the customer's HTTPS request will get in contact with are the VPC definitions.

They should be well defined, both for security and uptime considerations. As an example the subnets and routing should make full use of ALL availability zones in an AWS region. This will increase potential uptime and scale without increasing cost.

[REGION] Amazon Elastic Load Balancers (ELB)

Elastic Load Balancers, can and should terminate HTTPS traffic and offload HANA from HTTPS de/encryption, and to offload you from managing HTTPS certificates for every single HANA XS Server.

Elastic Load Balancers are a powerful and comfortable way to balance application traffic across HANA XS servers

[REGION] SAP HANA Servers (materialized in form of Amazon EC2 Instances)

For security reasons it is the best practice to run HANA Servers in a private Subnet, not directly reachable from the Internet.

The VPC network routes and the VPC security groups can be configured in a way that the web traffic has to go through an Elastic Load Balancer in order to reach the HANA XS processes. SSH and HANA Administration related ports can and should have a separate rule set.

Since SAP HANA SPS 11 it is possible to separate HANA XS and HANA DB into separate server tiers (separate set of EC2 Instances). As database- and application servers have very different best practices for HA and scaling User Load, it makes sense to separate SAP HANA XS, SAP HANA DB (and SAP HANA Dynamic Tiering) into separate tiers. This will improve Server Utilization and Scalability and therefore Cost and Uptime further.  

[ALL] Monitoring & Alerting

Each of the above services bring along very valuable monitoring and alerting options.

For instance VPC Flow Logs will provide raw Network monitoring and alerting.

[Partners] SIs and ISVs

Certainly not least, thousands of AWS partners provide very interesting options for you.

Solution Integrators bring you to your goal faster. Having come from AWS Professional Services, I have experienced the passion, dedication and competence AWS and Solution Integrators provide jointly to customers.

The ISV eco system is extensive. For instance, in matters of Security, Analytics and Data Integration there are a range of ISVs with very exciting choices for SAP HANA.

Summary & Ocean9

The 50++ AWS Platform Services can provide a lot of value for SAP HANA Native Applications.

Ocean9 is there to unlock this value without the effort that usually goes along with it.

If you are interested in exploring Ocean9, signup for our Beta Program - http://ocean9.io/saphana-aws.

In part 2, I will describe how to run SAP HANA itself in the best possible shape on AWS.

Back to top