This publication is a part of my final semester of Master of Business ERP – SAP University Alliance program at Victoria University and I will use this opportunity to provide a sound basis for considering the form in which Cloud computing can be used for SAP applications and some of the key things to look for on this journey.
Over last 40 years SAP has developed a large portfolio of business solutions deploying many different technologies with most of these developed before cloud and virtualisation concepts. In the world of information technology the term cloud has been treated as one of the most common buzz words and despite the fact that cloud computing has been around for many years. Confusion and misconceptions remain across organisations as to how private, public and hybrid clouds exactly work.
1. Cloud Distinctions
Cloud computing comes in many variations, however in the most general sense it means that an application, a service or a platform can be used via Internet where users subscribe to a set of services used within that structure. This implies continuous network access, location independent resources, quick scalability with a rapid release and measurable service levels.
This raises the question of what are cloud deployments and who is managing the different layers? According to cloud management types as illustrated in figure 1, we can clearly differentiate some of the models used, and the scale of personification to which cloud environments can be deployed.
Figure 1. Cloud Management Types (Inspired by David Chou,Microsoft)
Software as a Service (SaaS) is an application delivery model based on a standard, highly scalable software solution provided to multiple customers, with some basic configuration, with limited or no customisation. SAP’s SaaS deployed solutions like Business by Design, SuccesFactors, Ariba and Concur all share the common benefits of fast and effective deployment with accelerated return on investment, offering vast number of ‘out of the box’ capabilities with lower up-front costs. The analogy of a hand-tailored fully customised versus a generic made reflects not only the different price and the time, but also the degrees of fit to which SaaS is being deployed.
Platform as a Service (PaaS) is an abstraction of software frameworks used with the underlying operating system that allows application development without the knowledge of underlying layers. In simple terms, the cloud customers are managing their applications architecture layer without any need to manage their operating system admin tasks. Microsoft Azure offers a reliable PaaS model which has Web, Storage, Content Delivery, SQL Azure, access controls and the mass utilization of resources. This offers some phenomenal benefits with redundancy built in through the platform using vendor’s architecture scalability. As a result, applications that are scheduled to run in the PaaS model need to be adapted to this environment that may require a certain degree of technical skills required to design feature-rich applications. Important things to consider are the innovation concepts needed to maintain this model building add-ons when developing new solutions. This model contains some natural risks such as cross-platform integration points and ownership of updates. For example PaaS integration may require further tests to sustain business process related transformations, things like routing, application programming interface (API) calls and ongoing integration with other solutions. In simple terms, Microsoft’s approach might not be entirely synchronised with SAP’s and vice-versa.
Infrastructure as a Service (IaaS) can be defined as a model for enabling convenient, on-demand network access to a shared pool of configurable resources that can be rapidly provisioned and released with minimal management or service provider interaction (ODCA 2015). Amazon Web Services (AWS) is a typical example of IaaS, where AWS provide server, network, storage resources and gives the customer the choice of operating system. The virtual environments available through AWS behave exactly like local infrastructure enabling the customers to configure the infrastructure according to their demand.
SAP configuration access is done through SAP Cloud Appliance Library (CAL) which is an on-demand solution that allows you to quickly deploy SAP Systems in your cloud account of the supported cloud providers. In my personal experience this can be done rapidly and efficiently using SAP’s pre-configured solutions. Key factors to consider in this instance are security, scalability and availability.
Each deployment model contains characteristics suitable for specific solutions which can be summarised as follows:
Figure 2. Cloud Computing Definitions (Source: NIST Sept. 2011)
Reviewing the summarised characteristics, it is evident that the each deployment models has its advantages and disadvantages, with the most desirable model being dependent on the organisational requirements and budget.
2. Security Considerations
Cloud security is surely the most controversial topic in cloud computing technology and probably the most discussed subject. Confidentiality of data and availability of core applications are of utmost importance for any cloud environment. Data location, portability and business continuity of the vendor, are paramount factors for any organization moving to the cloud.
Data center location plays an important part in considering major U.S. cloud service providers and the USA Patriot Act (“Patriot Act”) which allows U.S. law enforcement and national security agencies unrestricted access to any data, anywhere in time. Privacy fallout from the recently exposed NSA (National Security Agency) surveillance program strongly indicates it is necessary for SAP customers to consider the location of their cloud data centers and their responsibilities within the operating jurisdictions.
Previously discussed concepts of cloud computing are implying that the cloud creates a shared responsibility model between the customer and cloud service provider combining an additional layer into a security framework. This implies that no matter which deployment model customer chose it is crucial to clearly define and understand the responsibilities of each vendor who is part of delivering the service (Missbach et al. 2013).
Cloud security policy considerations should also cover cloud provider’s internal risk framework and policies around intellectual property used in the enhancement of security for the provisioned service. One of the most important objectives is to do a risk assessment that drives the development and implementation of a cloud security policy. The risk assessment should cover an entire enterprise infrastructure containing from the physical access to the data center, through the whole stack up to the database and SAP application itself.
In comparison to traditional landscapes cloud environments are multi-tenancy which in simple terms refers to the concept in which a single instance of a software application serves multiple customers where each customer is called a tenant. A tenant can potentially be any application inside or outside the enterprise that needs its own secure and exclusive virtual computing environment. This environment can consist of all or selected layers of enterprise architecture, from storage to UI. This implies that cloud environments require additional security considerations to achieve acceptable security standards like conventional SAP landscapes. It is important to note that in private clouds the entire responsibility of designing a multi-tenant architecture resides with the organisation.
According to the table below we can clearly differentiate degrees of customer control, and the scale of security considerations for each layer of IaaS offerings:
Infrastructure layer | Public - IaaS | Private Cloud - Hosted | Private Cloud - On Premise |
Datacenter | No control | Limited control | Full control |
Network | Limited control | No control | Full control |
Storage | Limited control | Limited control | Full control |
Hyper-visor | No control | Limited control | Full control |
Operating System | Limited control | Full control | Full control |
Database | Full control | Full control | Full control |
Application | Full control | Full control | Full control |
Backup/Restore | Limited control | Limited control | Full control |
Table 1, Degree of Customer Control IaaS model (Source: SAP on Cloud)
Note the degree of control varies as some of the cloud providers may have different restrictions. In order to cover some of the ‘shared responsibility model’ concepts, we will briefly cover Amazon Web Services as the first public cloud supported for the classical business suite by SAP.
Security considerations of Amazon AWS are based on shared responsibility where in simple terms; Amazon takes the responsibility from the virtualization layer down to the physical security of the cloud datacenter facilities. This implies that SAP customer keeps responsibility for the guest operating system, the application software installed including updates and security patches as well as the configuration of the security group firewall provided by AWS. SAP customers can further enhance security by implementing host-based firewalls and intrusion prevention, encryption and ID key management.
3. Service Levels
The objective here is to provide some practical examples of a cloud journey, focusing on the question how to forecast the necessary resources required to fulfil the SLA and how to measure and bill their actual consumption in the cloud.
SAP systems are usually categorised as business critical systems for operational and financial statement purposes in every organisation. In theory cloud computing offers infinite resources; however the reality demonstrates that all the resources have their limitations.
One needs to consider how predictable the total demand is compared to the size of the available cloud environments, with the baseline being the worst case scenario. Considerations must be given to each entity engaged with the clear sets of expectations being defined around cloud provider, cloud user and in particular cloud auditor. The quality of the provided services must be defined in Service Level Agreements (SLA) using measurable criteria so that their adherence can be verified accordingly. A typical SLA will contain levels of service using various attributes such as: availability, performance, operations, billing, and penalties associated with violations of such attributes.
Availability is usually expressed as a percentage over a year period, and unfortunately does not cover the frequency of system downtimes - only the total downtime aggregated over the year (Missbach et al. 2013). In order to define more accurate definition of availability good SLAs should contain alternative measures of availability. In addition the maximum acceptable downtime has to be defined. Performance of an SAP system is defined as the ratio between the available resources and the current load.
This can further be assessed based on the type of the implementation. In case of new SAP implementations (Greenfield) estimating the maximum expected system load is part of the agreed SLA. For existing SAP systems moving to cloud infrastructures the necessary information can be derived from measurements using the most recent SAP Early Watch reports (Missbach et al. 2013). Using tools like SAPS-meter can be of great benefit in providing the necessary data before the migration to a cloud infrastructure, but also for the ongoing monitoring of the SLA and even the automatic generation of billing.
4. Summary
In concluding my first blog I would like to finish off with a summary of the key criteria that I would consider in an enterprise cloud deployment model:
Business Criticality plays the most important part purely because of the fact that most of the customers cannot afford to experiment with their very core business processes. This weighting of the costs against risks will play critical part in decision making process even in the case of the most comprehensive IaaS offerings (e.g. 99.95 %) where the availability is essential but not entirely sufficient component. IaaS recovery times and recovery times objectives will be a focus point in years to come.
Security has to be treated as a continuous process of engagement. Customers need to decide which type of data can reside in a public cloud and which data needs to reside internally for previously mentioned security reasons. This may not be the easiest task to separate due to potential support limitations (SAP might not support different data stores).
Provision for Performance in terms of SLAs which are measurable and to which control the customer will have the ability to regulate the resource utilisation. Keeping in mind newly encountered issues in cloud computing space, for example – single SAP software component does not scale out (e.g. the SAP database) exceeds the capacity of the maximum size of the cloud service providers virtual server capacity (e.g. virtual memory/CPU) the particular component can potentially have a negative impact on the business processes.
Integration is something that I haven’t touched upon in significant level of detail, but it definitely requires serious consideration. SAP’s enterprise reality consists of many customised environments which are heavily integrated with other non-SAP systems. Things to consider are the interface scenarios containing very large data volumes and real replication times which need to be transferred within a given period of time. A clear path converging to one platform which contains critical integration is something that we may expect in the near future.
The enterprise cloud adoption is an absolute game changer and by looking at the SAP hosting market in is rather unlikely that we will see an imminent large scale shift in production environments until some of the major concerns are addressed thoroughly.
References:
Missbach, M., Stelzel, J., Gardiner, C., Anderson, G., Tempes, M 2013, SAP on the Cloud, viewed 6/3/2015, <http://www.springer.com/us/book/9783642312106>
Donecken S 2013, ‘The 1-2-3 of Cloud Security at SAP’, SAP Community Network, weblog post, 08 August, viewed 21 May 2015 <http://scn.sap.com/community/cloud/blog/2013/08/07/the-1-2-3-of-cloud-security-at-sap>.
Mell P, Grance T. 800-145. National Institute of Standards and Technology (NIST), Gaithersburg, MD, (September 2011), viewed 21 May 2015 <http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf>.
Chou D, 2009, “Types of Clouds’, Windows Azure Platform, viewed 21 May 2015 <http://www.slideshare.net/davidcchou/windows-azure-platform>.
Implementing SAP Solutions on AWS 2013, Amazon Web Services, viewed 19 May 2015, <http://awsmedia.s3.amazonaws.com/SAP_on_AWS_Implementation_Guide_v3.pdf>.
Proof of Concept: Enterprise Cloud Service Quality. Web. viewed 19 May 2015 <http://www.opendatacenteralliance.org/docs/ODCA-PoC-Ent-Cloud-Service-Quality-Re>.
SAP Cloud – Missbach M. Web. viewed 19 May 2015 <http://www.slideshare.net/Pramilanagaraj/sap-cloud-michaelmissbach>.
Special Thanks to:
Tony De Thomasis, Alfonzo Venturi, Professor Paul Hawking and Professor Colin Clark.
- SAP Managed Tags:
5 Comments
