Over the course of last year, I saw a number of SAP initiatives running within the Amazon Web Services (AWS) cloud as the test and demo system. Having had a lot of experience of running SAP landscapes in AWS, I know that there are great opportunities to be had in terms of flexibility and cost reduction -- although I had never done a full breakdown of the figures. I wanted to see if SAP was on the right track in putting these environments in AWS cloud rather than running them out of their own data centers and what SAP customers might need to know or consider about this strategy.
To find out more about the various costs associated with running software landscapes, I broke down the actual economics of running a project in the AWS cloud against some example costs of more traditional ways of running projects.
The AWS Elastic Compute (EC2) cloud is an Infrastructure as a Service (IaaS) model. This enables consumers to directly provision virtual servers and run anything they like on them -- ranging from simple Web applications to full blown Web-scale enterprises, and anything in between. The critical piece of this is that AWS EC2 is completely self-service. Everything from the guest OS upwards belongs to you, the customer. For many, this is a fundamental characteristic of cloud, if self-service or utility billing is not present, then you are using a highly scalable virtual managed environment -- and not a cloud.
For the purpose of this article, I make several assumptions about how the SAP project landscapes are run in order to create an apples to apples comparison. They include:
- All requisite actions regarding data security have been taken.
- Technical resources are provided at a flat separate and additional cost regardless of the location of the system being supported.
- Creating a VPN connection between AWS EC2 and core customer applications is already established.
- All resources from all providers/teams are available and scheduled to create the SAP landscapes at the required times.
For this project, I am going to mirror a previous project timescale and requirements for implementation of additional functionality in SAP HR employee self-service and manager self-service and reporting to exemplify the infrastructure costs against other hosting providers. This was a 16-week project that had a high-level blueprint already accepted by the client. The project had entered into detailed workshops and realization phases, as shown below in the project plan screenshot (Figure 1).
I compared three other providers against Amazon as an SAP-supported IaaS provider, including a tier 1 enterprise services company, a tier 2 services company and a second public cloud provider. Using the same requirements and publically available costing data, I calculated the direct costs of running a 16-week project in both an SAP-supported hosted environment and an SAP-supported IaaS environment. The project entails using SUSE Linux server specifications for an SAP ECC, SAP CRM and SAP Business Warehouse (BW) instance, as shown in Table 1.
It is possible to compare the direct infrastructure costs of cloud and hosting environments. The tables below show the project duration in weeks and the landscape requirements for each week.
When running projects in a cloud environment, a major advantage is the ability to reduce the available hours and even stop or park environments to reduce the cost to the project. This is demonstrated in the difference in run costs between week seven and week eight with the project moving into the quality landscape. Because the development landscape is not needed as much, costs are reduced by nearly $200 per week. It should be noted that this behavior needs additional services to automate it, or it needs to be manually executed by the project team.
For AWS, the breakdown is shown below. The total cost of the project Infrastructure is $14,152.56 for 4,548 compute hours. In order to arrive at this figure, I have taken the hourly cost of an instance and multiplied it by the number of hours required in a week. The number of hours required in a week can change depending on the project phase. So taking the number of hours required in each week and multiplying it by the hourly cost of the compute and storage, I arrived at a weekly cost for the project instances, which was totaled to give the final cost for the project infrastructure.
The decommissioned servers, marked in navy on the Figure 2: Cost of running projects in AWS PDF, show they are no longer needed within the scope of the project. User Acceptance Testing (UAT) servers are only needed for a short length of time.
Unfortunately hosting providers do not provide the same kind of flexibility and utility billing as cloud providers. Typically, hosting providers charge a flat rate for all the servers to be used throughout projects as they cannot easily resell unused capacity.. Typically, the hosting provider charges a flat rate for all the servers to be used throughout the project. This means that there is no benefit in flexing the infrastructure according to its use in the environment, which allows a compromise between the customer and the provider over longer-term hosting deals, but it penalizes the customers when they want to move with any agility because as the amount of deliverables increases, so typically does the cost.
For a tier 1 hosting provider, the breakdown is shown in the Figure 3 PDF. The total cost of the project infrastructure is $22,710.02 across 7,224 compute hours, and using the same method I used for the AWS infrastructure costs, I derived the weekly cost of the project instances as well as the total infrastructure cost.
As with Amazon, the second cloud provider is able to control the operational hours of the landscape, which helps with costs without affecting the project capability.
For a public cloud provider, the breakdown in the Figure 4 PDF shows the total cost of the project infrastructure is $15,610.4 across 4,548 compute hours, which is more than AWS because the price of storage is higher at this provider.
Although the tier 2 hosting provider is the most expensive of all the options compared here, it also usually provides the highest degree of value-added services. Tier 2 providers tend to be smaller and therefore can provide a level of responsiveness that a tier 1 provider just cannot match without costing the earth. You can see this in its ability to move from charging for UAT to Mock Cutover in week 16. It may also be possible to reduce the resources used by environments when they are at reduced project utilization in order to bring down costs, like in the period when the projects leave development.
The breakdown for the tier 2 hosting provider is illustrated in the Figure 5 PDF. The total cost of the project infrastructure is $28,665.2 across 6,720 compute hours, using the same method that was used for the AWS infrastructure costs, and I derived the weekly cost of the project instances as well as the total infrastructure cost.
Conclusions and findings
This comparison for me drives out some interesting points, and if you couple these with some industry knowledge of hosting, here are the key takeaways:
1. Public cloud is the cheapest. Although I already knew that, what I had not quantified was the amount of savings derived from a little more effort around the number of hours systems are available. It is also the most austere in terms of services and tools available. You need to have the skills to provide your services and support throughout your project.
2. Hosting providers are considerably more expensive, although often it is the little things that provide the greatest benefits. For example, proactive management can be worth its weight in gold during a project. If you have to go with a hosting provider, do not bargain on price -- often that is a fool's errand and reduces the host's responsiveness. Tie down your hosting provider in services, benefits and service credits -- things that matter to you and make your life better. For many providers, reducing cost is easy. They reduce head count allocated to you, and, as a result, you lose service.
3. As with a lot of technical aspects of projects, the nonfunctional requirements (NFRs) drive a lot of the constraints and the complexity of solutions. Complex NFRs favor hosting providers because of their ability to customize solutions. But you should ask yourself how much you really need these NFRs -- and be bold. Do not be afraid to challenge your NFRs in order to ensure you pick the right option, not just the safest option.
I am a fan of cloud, but running landscapes in an IaaS platform medium to long term is difficult.. It requires that the vendor dedicate a skilled team to running it, unlike hosting companies who pool shared resources across clients to reduce costs. These companies use process, documentation and micro-management to protect customers from their own staff making mistakes because they work on multiple accounts. I believe there is room for both models in various ratios for customers, a dedicated team of high-skilled people supporting a small to medium sized high-value environment for projects and innovation. Pair this with a mutualized team for low- to medium-skilled jobs in a larger environment, you can have innovation with low-cost support. The trick is getting things to move seamlessly from one side to the other.
In conclusion, the figures and attached spreadsheet show that there can be significant benefits to running projects in a public cloud in terms of direct costs for infrastructure; and, of course, there are indirect costs you need to take into account. These have been left out simply because they are not easily applied across the selected vendors in a way that is easily demonstrated here. Also I have not named the individual companies used for comparison because pricing models change regularly and the point of the article is to illustrate the economics of using AWS cloud for projects, not to provide valid costing for a provider.
About the author:
Chris Kernaghan is a senior SAP technical architect at CapGemini, the global consulting, technology and outsourcing firm.