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.
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!
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:
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:
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.
This is not an official categorization, but I found it helpful for understanding.
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:
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:
These services live in 55 edge locations of 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.
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.
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.
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.
Yes, a public HANA service should have a well defined Private DNS approach as well. There are several reasons.
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.
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
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.
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.
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.
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.