Skip to Content
Author's profile photo Richard Hirsch

NetWeaver Cloud Pricing: An analysis and a quick comparison with other vendors

Pricing for NetWeaver Cloud was recently announced and I wanted to take a closer look at the packages offered.

Here are the different offers.

/wp-content/uploads/2013/02/image001_182837.jpg

Footnotes:

*EURO pricing – local prices available from your SAP representative, price per month does not include tax

1: Virtual Machine configurations

Lite = 1 Core / 2GB RAM

Professional = 2 Cores / 4GB RAM

Premium = 4 Cores / 8 GB RAM

Premium Plus = 8 Cores / 16 GB RAM, available in “à la carte” configurations

2: Connection using the cloud connector for SAP NetWeaver Cloud


General analysis

Audience

Based on the characteristics of the different offers, it really isn’t clear to whom the offers are being directed.

The marketing fluff for the pricing doesn’t help:

A cloud platform for business of any size! Choose the configuration that best fits your business needs. You can start small – for instance with the developer package – and expand from there as you need. To add additional resources to your package or for an “à la carte” configuration, tailor-made for your needs, please contact an SAP sales representative.

Is it partners who want to use NetWeaver Cloud to sell the applications that they have developed?  Or is it existing customers – primarily the IT departments – who want to develop some of their internal applications in the Cloud?

This distinction is important in that the business requirements and technical needs (tools, etc) of each group may be quite different. 

If these offers were more associated with partners, I would assume that there would be some reference to the new NetWeaver Cloud Partner program on the page but I never found one there.

Perhaps the most telling indicator of the focus is included in the “Terms and Conditions” which is available in all offers in the SAP Store but which I doubt very many potential customers will read.

/wp-content/uploads/2013/02/image002_182839.jpg

  1. 2. USE OF THE CLOUD SERVICE
  2. a. The Service includes the platform hosted in the SAP Cloud (the “Platform”) on which the Customer Applications (as defined in Section 1.b below) can be uploaded and accessed by Customer and Customer’s authorized end users (“End Users”). End Users must be employees of Customer or Customer’s Affiliates, or business partners of Customer accessing the Customer Applications solely in support of Customer’s use of the Customer Applications for its internal business operations. Customer may not otherwise make Customer Applications available to third parties, including, without limitation, as part of a software-as-a-service, outsourcing or similar commercial arrangement with the End User. [My emphasis].

My reading of this legal clause suggests that the main focus is on existing and – to a lesser degree- new customers who use the platform to improve their own internal processes. Although not a lawyer, the legal restriction “Customer may not otherwise make Customer Applications available to third parties, including, without limitation, as part of a software-as-a-service” sounds very much to me like the typical activity that a partner might provide.

Recently, I read an interesting forum post that might explain this clause.

Note: As Kaloyan Raev states, his forum post is not an “official” SAP statement but I thought it was quite useful to better understand the relationship between partners and customers.

The Starter Package is the minimal (3 VMs, 10 GB storage, etc.) paid package of cloud resources that you can buy. If you are a partner, you get 1 Starter Package included in the annual fee. If you need more resources to develop your app then you must buy additional packages.

When a customer of you buys your application from SAP Store, he needs to also buy a package of cloud resources (like the Starter Package) in order to run your application. So, the customer pays twice – once to you for the application, and another time to SAP for the cloud resources.

Currently, this is the only legally approved selling process we have. We are working on the legal aspects of another model where the customer “subscribes” to the partner’s application. In this case the customers does not need to buy their own cloud resources, but the application they buy still runs in the partner’s account and the partner is billed for the cloud resources.

If the application is targeted for only one customer then there is no sense to publish it on SAP Store. In this case I believe the partner program doesnot apply. The customer should just buy a package of cloud resources to develop and productively run the application

After reading Kaloyan’s post, the legal clause mentioned above makes more sense.

Different storage types

There are three different types of storage that are mentioned: HANA Storage, unstructured data and relational DB storage. 

To be truthful, I’m surprised that the unstructured data storage is described separately. It appears that the reason is that CMIS is still using MongoDB. I’ve been waiting for CMIS to transition to HANA for a while now (since Sep 30, 2011!). If HANA can be used for unstructured data, it would appear to be a perfect fit.

The fact that there is also a transaction limit for unstructured data but not for other types of database usage is also a bit strange.

Tracking usage

Pricing in NetWeaver Cloud is based on certain metrics (such as transactions to unstructured data storage, etc). I have never seen any tools on the platform that allow developers / customers to know when they are approaching their limits. If I’m getting close to using up all my bandwidth from my application to the Internet, I’d like to know about it before-hand.

There are also no indications what happens if I go beyond the limits established by my package. Do I have to pay extra? Is my access restricted in some fashion following such “violations”?

Focus on interaction with SAP on-premise systems       

The fact that all three NetWeaver Cloud packages include unlimited connections to SAP on-premise systems shows that SAP has great interest in using the environment to integrate with SAP on-premise assets.  Connections to non-SAP OnPremise systems, on the other hand, are restricted. I assume that the Cloud Connector is the primary means with which these connections will be implemented.  I’ve never seen any tool that might administrative metrics of such connections and I have no idea how the different types of connections might be tracked. Connections to OnPremise assets that don’t use the Cloud Connector might be more difficult to track inasmuch as such connections might be indistinguishable from other connections (for example to cloud-based assets)

This metric is linked with SAP’s broader emphasis on hybrid (OnPremise / OnDemand) scenarios – especially regarding the LOB SaaS applications (Customer OnDemand, Travel OnDemand, etc).

Here is a simplified table with the different variations:

Focus

SAP

Restriction

OnPremise

Yes

Unlimited

OnPremise

No

Limited (Connection Count)

OnDemand

irrelevant

Limited (Bandwidth)

If I’m a developer, such restrictions make an application design even more complicated inasmuch as other competing PaaSs don’t have such limitations. 

Furthermore, if I’m a customer who has purchased the Premium package, supporting various applications and having all three levels (Dev, Stage and Prod) running on NetWeaver Cloud then the number of provided connections  is extremely limiting.

There is still another question associated with these connections:

  • Are the number of connections listed per CU or for all CUs in the package

Comparison with pricing of other Cloud PaaS vendors

I’ve just provided a quick analysis of NetWeaver Cloud pricing but what about other vendors? What sort of metrics do they use in their pricing?

There are a variety of cloud vendors with different types (IaaS, PaaS, etc) of offers. It is the most useful to compare the NetWeaver Cloud prices with other PaaS vendors – in particular those vendors which concentrate on Java-based applications. 

Note: My intention isn’t to suggest that one vendor is better, cheaper, etc than the others but rather to compare the pricing metrics that each vendor uses. I’m also not going to describe all the details from all pricing characteristics but rather just provide a rough outline of these elements.


Oracle

A direct comparison is a little difficult, because Oracle has different prices for its Cloud Database and its Java Cloud PaaS and every Java Cloud Service User requires a Database Cloud Service.

Database

S5

S20

S50

Cost ($) /Month

175

900

2000

Schema

1

1

1

Database Storage

5

20

50

Data Transfer

30

120

300

Java

S1

S2

S3

Cost ($) /Month

249

499

1499

Oracle Weblogic Server

1

2

4

RAM Java Heap (GB)

1,5

3

6

File Storage

5

10

25

Data Transfer

50

250

500

Analysis:

  • The Oracle Java PaaS offers are primarily associated with number of Weblogic servers used. In the SAP offers, more emphasis is provided on the underlying technical architecture (number of cores and number of compute units) rather than the underlying server count.
  • If we compare the maximum number of Weblogic servers vs the maximum number of compute units provided, then there are large differences between the two vendors.  The SAP offers (especially at the high end) have many more compute units than are offered by Oracle. The Premium package contains over 60 compute units compared to just 4 Weblogic servers in the largest Oracle offer. The prices for the respective offers are accordingly quite different as well. This difference means that the use cases customers can cover with each offer are different.  I also assume that the Premium offer from SAP would only be ordered by the largest customers. Oracle customers might be able to order multiple S3 packages but the fundamental difference still exists.

CloudBees

CloudBees pricing is largely split between a free version and an enterprise version.

/wp-content/uploads/2013/02/image003_182840.jpg

/wp-content/uploads/2013/02/image004_182841.jpg

Analysis:

  • Although I’ve just included screenshots from the multi-tenant offer, there is also an  offer for dedicated servers (a model that is similar to that provided by Oracle)
  • Compare the most expensive offer from CloudBees to this SAP’s Premium and becomes clear that SAP is focusing on a difference audience than that of CloudBees.  This isn’t a bad thing – the cloud market is large and growing rapidly – but it is critical to understand that NetWeaver Cloud is focusing on a different market than many other vendors.


Conclusion

When choosing a PaaS, there are various criterion that influence such decisions. Pricing is just one factor among many.  Indeed, the relative importance of pricing may be different based on the use case involved. A developer looking at an option to rapidly create a few POCs will look at pricing differently that a member of the IT team looking to outsource multiple apps to the cloud.

Pricing metrics between PaaS vendors are actually quite similar to one another – the main factors usually involve various configurations based different amounts of memory and storage. If SAP is indeed focusing on its customer base as the primary users for the platform, then I think it has the right pricing strategy. I’d be curious, however, to see if users progress through the various packages. Ideally, a customer would start with a developer package and then move on to other packages – perhaps as they purchased other partner apps.   As only the first NetWeaver Cloud partner app has just been certified and, besides two NetWeaver Cloud Portal offerings, there are currently no NetWeaver Cloud applications in the SAP Store, I think the motivation of customers to move to platform to use externally produced apps is still limited.  As the number of such applications increase, then I expect more customers to look at the platform.

Assigned Tags

      31 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Tammy Powlas
      Tammy Powlas

      Interesting analysis - did you see they just published the NW Cloud / Portal Roadmap today too https://websmp106.sap-ag.de/~sapidb/011000358700000139812013E.pdf (SMP logon required)

      Author's profile photo Jason Scott
      Jason Scott

      Thanks for that link Tammy. Looks like its just Portal (onpremise and ondemand), with the NWCloud one on its way soon...

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Thanks for the link - it sounds interesting but I don't have a SMP login any more. I'll have to wait until the info percolates into the public space.

      D.

      Author's profile photo Jason Scott
      Jason Scott

      Sure is pricey!!!

      What about using another PaaS (any) and connecting into SAP using gateway - no restrictions then.

      Can't see why they would restrict the connections to non-sap systems though. Sure, SAP may want to market NWCloud more as an extension for their existing customer base, but why would the existing customers look at NWCloud when they already have all the servers and such on-premise. Maybe the pricing is more level in that scenario...

      Thanks for the blog, Richard.

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Good point about using gateway with another PaaS. I also found the restrictions to non-SAP solutions a little counterproductive.

      However, there might be another reason for this restriction. If you look at the ToC for NetWeaver Cloud, there is a passage that I think is referring to the upcoming IntAaaS offering or OnPremise PI:

      d. For access to on-premise enterprise systems through mediated middleware solutions:

      (I) If an SAP mediated solution, Customer does not pay for connections irrespective of SAP or non-SAP on-premise enterprise systems connected to this mediated solution.

      (ii) If a non-SAP mediated solution, Customer must purchase a connection only for the connection to each non-SAP mediated solution.

      What is curious is that if you use the "SAP mediated solution" the connections to non-SAP on-premise systems do not need to purchased separately. Of course, there are probably other costs involved with this option. Customers would probably have to look at the use case in detail to see which solution would be better in terms of TCO.

      D.

      Author's profile photo Jason Scott
      Jason Scott

      Well thats an interesting find... I'm looking forward to learning more about this integration as a service (potential) offering.

      Author's profile photo Former Member
      Former Member

      I would not say there are "restrictions" for the connections to non-SAP on-premise systems. On-Demand-to-On-Premise connections are part of the pricing model and the billing is per connection. You just get the ones to SAP on-premise systems for free. For the others you need to pay. You are not really restricted in the number of connections - you can buy as many as you need. The packages in SAP Store are just a convenient way to buy a set of cloud resource units as a self-service.

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      OK - that seems a lot more realistic. Unfortunately, this pricing element isn't really described any where. Is this the "à la carte" variation that I read about. Is there a description about how much the additional connections cost per connection. This would be more similar to the pricing model for Google Cloud dealing with quotas.

      Author's profile photo Former Member
      Former Member

      You can order "à la carte" by going to a sales person - you say what you exactly want to buy and she will offer you a price for your exact combination.

      Pricing on low-level cloud resources is not disclosed yet. I am not sure if this will be done in future. In the end, SAP NetWeaver Cloud is not just IaaS, but PaaS providing more than just low-level cloud resources.

      Author's profile photo Former Member
      Former Member

      That would be nice to see Google Cloud also.

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      But Google Cloud really isn't Java-related so it might not fit. I had included Force.com but then I deleted it, because there were just so many fundamental differences with NW Cloud.

      Author's profile photo Former Member
      Former Member

      No Google Cloud is totally Java related. Plus it is Phyton related too. May be we can narrow Google Cloud to Google App Engine. But if you want to use also database things you have to use Google Cloud SQL. There isn't only one product at Google.

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      OK - I'm not really the Google Cloud expert. What is their pricing like?

      D.

      Author's profile photo Former Member
      Former Member

      I am not also Google Cloud Expert. I just used it to make sample applications to compare with SAP. You can get information here: https://cloud.google.com/

      Author's profile photo Former Member
      Former Member

      Nice blog!

      Many questions are asked. I just want to comment on few of them.

      Regarding the storage. Yes, there are three types of storage: unstructured (cheap), traditional relational DB and HANA storage (expensive). The unstructured storage is ~100 times cheaper than the HANA storage. Therefore, it definitely makes sense to bill it differently. And it is intended for keeping files and documents (this is the NW Cloud Document Service accessible via the standard CMIS protocol). Of course, if you need to do high-performance analysis on these documents you can still store them in HANA. But just dumping everything to the HANA storage is a quite an expensive luxury.

      Regarding the pricing comparison. Please, note that the Professional and Premium package contain HANA storage, which has the greatest stake in their price. Compare them to the Starter package, which has no HANA and is significantly cheaper. So, when comparing with other platform, there should be something comparable to HANA in their offerings, otherwise the comparison is irrelevant.

      Regarding quotas and metering. We definitely don't want to stop your business, because you consumed more DB storage than you have purchased, or for similar reasons. The only quota enforced is the number of VMs started. If you hit any other quota you will be alerted to buy additional resources, but your app will continue working. When we introduce pay-per-use pricing model, quotas will become irrelevant.

      The metering is still under development - currently it is available only for the cloud operators. UI for end users is in progress.

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Thanks for the very relevant comments.

      My goal behind the blog was to demonstrate where I thought things were unclear.  Your comments really help clarify these points.  For example, the role of HANA in pricing hasn't been given enough emphasis.

      The details about quotas and metering are also interesting.

      Author's profile photo Former Member
      Former Member

      I can try to shed some lights to the connectivity pricing and the questions raised in the blog:

      The fact that all three NetWeaver Cloud packages include unlimited connections to SAP on-premise systems shows that SAP has great interest in using the environment to integrate with SAP on-premise assets.

      Yes, that's the case. SAP aims to provide excellent integration capabilities between its cloud offering and on-premise to allow customers gradually extend their business into the cloud without invalidating their made on-premise investments.

      I assume that the Cloud Connector is the primary means with which these connections will be implemented.  I’ve never seen any tool that might administrative metrics of such connections and I have no idea how the different types of connections might be tracked.

      You are right, the Cloud Connector is the on-premise agent by which secure technical connectivity between the cloud and on-premise systems is enabled. Of course, a customer has the choice to make backend services accessible also through other means, e.g. by opening his/her firewall and making the service accessible from the Internet. The connection pricing of SAP NetWeaver Cloud refers only to those connections managed by the Cloud Connector, other outbound traffic of the cloud is covered by the bandwidth traffic pricing.

      For metering, the configured backend systems in the Cloud Connector are counted and reported back to the cloud. Since version 1.2.0 of the Cloud Connector, a new mandatory field has been added to the backend configuration which classifies a configured backend as SAP or non-SAP. Only non-SAP backends are separately charged, and the pre-bundled licensing packages include already a set of non-SAP connections.

      You are also right that technically there is no way to differentiate between SAP and non-SAP backend, so the metric is  relying on the user configuration made in the Cloud Connector. We'll see how this works out...

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Thanks for providing all those details about connections.

      The information about how connections are metered was also new for me. I've always wondered how that works.

      D.

      Author's profile photo Former Member
      Former Member

      Great work to combine the pieces of information.

      I have a few questions -hopefully not answered already, if yes please ignore my ignorance 🙂

      For demo/experimentation purposes would it be possible to connect NWCloud with a HANA instance on AWS?

      How could you handle a offering that would support SAP backends from multiple customers that is hosted on NWCloud? In other word we have a offering that would be multi-premise. Can you configure connections to multiple customers separately or is it limited to a single installation (customer/installation id)? This naturally requires that we can keep the data and connections safely separated from each other on the system and our application layer.

      Any feedback would be appreciated.

      Albrecht

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Albrecht Gass wrote:                    

      For demo/experimentation purposes would it be possible to connect NWCloud with a HANA instance on AWS?

      Why would you want to do this when you could use the HANA data that is stored in NW Cloud?

      Albrecht Gass wrote:

      How could you handle a offering that would support SAP backends from multiple customers that is hosted on NWCloud? In other word we have a offering that would be multi-premise. Can you configure connections to multiple customers separately or is it limited to a single installation (customer/installation id)? This naturally requires that we can keep the data and connections safely separated from each other on the system and our application layer.

                         

      That is a probably a question that Timo could answer best.

      D.

      Author's profile photo Former Member
      Former Member

      Richard,

      when I look at the first table in your presentation and some of the posts it says it was my understanding that there is no HANA storage included in the free option. Did I get this wrong?

      Albrecht

      Author's profile photo Former Member
      Former Member

      Since January 17th (look at release notes) HANA is also available on the newly created free developer accounts (a.k.a. trial accounts). You can select between MaxDB and HANA during the creation of the account.

      Author's profile photo Andreas Buchen
      Andreas Buchen

      Right now this is only an option for new accounts. Existing accounts stay with MaxDB. We'll enable more choices in the upcoming months. Contact us directly via the support channel if you want me to change your account.

      Author's profile photo Former Member
      Former Member

      Andreas Buchen wrote:

                             

      Right now this is only an option for new accounts. Existing accounts stay with MaxDB. We'll enable more choices in the upcoming months. Contact us directly via the support channel if you want me to change your account.

                         

      Andreas,

      how much data can be held in HANA memory in the free edition? If I recall properly HANA is licensed based on RAM, how does this apply to all NWCloud editions?

      Thanks for any additional information.

      Albrecht

      Author's profile photo Andreas Buchen
      Andreas Buchen

      On trial it is a generous 1GB. Doc needs updating.

      Author's profile photo Former Member
      Former Member

      Thanks, that makes a difference.

      Author's profile photo Former Member
      Former Member

      Albrecht Gass wrote:

                             

      For demo/experimentation purposes would it be possible to connect NWCloud with a HANA instance on AWS?

                         

      It should be possible. It would be the same as connecting the NW Cloud app to an On-Premise HANA instance. In this case you should implement some HTTP access (like Web Service or RESTful Service) on the HANA@AWS instance, so the NW Cloud app can access it.

      Albrecht Gass wrote:

                             

      How could you handle a offering that would support SAP backends from multiple customers that is hosted on NWCloud? In other word we have a offering that would be multi-premise. Can you configure connections to multiple customers separately or is it limited to a single installation (customer/installation id)? This naturally requires that we can keep the data and connections safely separated from each other on the system and our application layer.

                         

      Yes, the Connectivity Service can be configured with multiple connections. Each connection can point to a different On-Premise site.

      However, this "multi-premise" offering sounds interesting. Do you mean a single instance of cloud app that connects to multiple customers and works with their On-Premise data without any isolation? This would require quite some trust from these customers to the provider of the cloud app. Each customer must setup a tunnel (via SAP Cloud Connector) the cloud account of the provider and give him credentials to the On-Premise systems.

      Author's profile photo Former Member
      Former Member

      Kaloyan,

      to give you some background: we have a tool that does extensive ABAP custom code analysis and automated code fixes for violations we detect. We do the heavy lifting in Java, so it would be interesting for us to find a solution that scales well when we add new customers and we don't have to have a cloud instance for each customer.

      We keep the customer data separate in our database and software but having multiple tunnels terminate in a single box might not be advisable.

      Do you see any elegant solution to our problem?

      Albrecht

      Author's profile photo Former Member
      Former Member

      Albrecht,

      As far as I understand, your application won't execute a single operation on the ABAP code of multiple customers. Just every customer will be able to use your solution for his own ABAP code.

      If this is the case, then this sounds like an usual use case for a "partner application" that can be sold on SAP Store.

      I recommend you get familiar with the SAP NetWeaver Cloud Partner Program: https://www.sapcloudappspartnercenter.com/.

      You can also take a look at this discussion: I have to become a SAP Cloud partner? and this blog post: SAP NetWeaver Cloud Licensing Options explained - What you can get and what you can do

      After reading the above resources you will find out that currently the only legally approved selling model is that your customers must consume your partner application in their own cloud account, i.e. on an isolated segment of cloud resources that are billed to the customer. I guess this does not really fit to your scalability requirements.

      In future (I cannot say when) there should be another selling model - you as a partner host the application on your account and sell your customers the access to your application. So the cloud resources are billed to you as an application provider, instead of to the customers as consumers. This way you will be able to optimize the resource consumption among your customers. But we are not there yet.

      I recommend you contact our Partner Center and discuss your project in terms of requirements and timeline: https://www.sapcloudappspartnercenter.com/

      Greetings,

      Kaloyan

      Author's profile photo Former Member
      Former Member

      Thanks Kaloyan,

      this might be an alternative for us using AWS or other cloud providers.

      Albrecht

      Author's profile photo Former Member
      Former Member

      Hi Richard, thanks for the blog. Was looking for this information for some time but local SAP Sales Market units seems to have problems to provide it since they focus more on selling SaaS instead of PaaS.

      Two remarks i have:

      1. I miss the SAP Business By Design Studio as a platform to develop PaaS. During last teched and FKOM this was clearly positioned by SAP as One of their targeted platforms. (I try to summarise this in my blog). Do you have pricing information on ByDesign?
      2. I miss Force.com as one of the leading PaaS platform. I'm realy impressed with the capabilities of this platform. It has set the bar for both functionality and pricing model. Basicly the have two option: Light application for 8 Euro per user/per month or Enterprise Application for 20 Euro per user/per month. No talks about CPU, Diskspace and all that stuff like in the SAP pricing. Sure the devil may be in the details but i can explain this model in 1 sentence towards a customer. As is SAP's case is need 15 min and still have questions.

      We're talking PaaS here and pricing models should be pay per use instead of al this traditional Infrastructure insight. SAP has cleary missed the whole idee of PaaS pricing here.