or 
or 
(Hooke’s Law for expressing elasticity of an object in various degrees of complexity)
The equations above get pretty complex pretty quickly! And that’s when we deal with equations that have been known about for hundreds of years. When we start using elasticity to describe cloud computing, it gets even worse.
The topic was brought up the other day when I was looking at purchasing some space on the SAP HANA Cloud to run an application that we’re developing in-house. I was checking the price for this.
http://scn.sap.com/thread/3350483
I got quite confused.
Then the conversation moved to twitter and we started discussing not just the price of going to the cloud but also how it should be priced. And then even onto how it could be made multi-tenant (which is a bit beyond the scope of this post, but it was interesting nevertheless.
I think the conversation is worth preserving so I’ve made a copy of it with a little help from Aaron’s Twitter Viewer and a lot of cutting and pasting so I could do without the CSS (if anyone knows how to add custom CSS to a single WordPress post, I’d be interested.)
Have a read, it’s not a bad collection of thoughts, and interjections (by the one and only Dennis H) and I’ll recap on my thoughts at the end:
Chris Paine
Feeling slightly confused by SAPStore pricing for #saphanacloud if you understand it pls help me scn.sap.com/thread/3350483
Dick Hirsch
@wombling compare price to other #saphanacloud packages in #sapstore – all have similar structure
Chris Paine
@rhirsch I understand the free ones but still confused what calculation is for rest, why show pm price when only pa purchase possible?
Dick Hirsch
@wombling a good question for #sapstore and #saphanacloud team – another reason to always read the small print
Vijay Vijayasankar
@rhirsch @wombling it will get rationalized soon . @aiazkazi has plans for it
Dick Hirsch
“@vijayasankarv: @rhirsch @wombling it will get rationalized soon . @aiazkazi has plans for it” >> hope you guys are working on cloning him
Vijay Vijayasankar
@rhirsch @wombling hehehe @aiazkazi is one of a kind – but he has a team behind him too to help with scale 🙂
Yariv Zur
@vijayasankarv @rhirsch @wombling @aiazkazi Pricing is presented as PM because this is how it was defined in official price list (cont)
Yariv Zur
@vijayasankarv @rhirsch @wombling @aiazkazi (cont) however min. Contract length for all cloud subscriptions is 1 yr. hence the mess.
Chris Paine
@vlvl @vijayasankarv @rhirsch @aiazkazi certainly not the clearest situation. But then again probably simple than onPrem pricing
Ethan Jewett
@wombling @vlvl @vijayasankarv @rhirsch @aiazkazi Minimum 1-year subscriptions are not very cloudy. Are add-on resources more flexible?
Chris Paine
@esjewett @vlvl @vijayasankarv @rhirsch @aiazkazi had one potential customer only needed 3-4 months every yr. They didn’t sign up 🙁
Chris Paine
@esjewett @vlvl @vijayasankarv @rhirsch @aiazkazi cloud ideal for flexibility, but not so much in this case
Ethan Jewett
@wombling @vlvl @vijayasankarv @rhirsch @aiazkazi Really, I’d argue that it’s not even cloud if it requires a 1-year commitment. Hosting.
Chris Paine
@esjewett @vlvl @vijayasankarv @rhirsch @aiazkazi different times for use-cases SuccessFactors 3yr contract. But wld like more flexible PaaS
Ethan Jewett
@wombling @vlvl @vijayasankarv @rhirsch @aiazkazi Indeed, but for IaaS and PaaS I’d argue “cloud” involves elasticity. The NIST agrees 🙂
Vijay Vijayasankar
@esjewett @wombling @vlvl @rhirsch @aiazkazi other than on iaaS (rhymes with aiaz) , I doubt perfect elasticity will happen for any vendor
Ethan Jewett
@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Every PaaS I’m aware of provides it. Elastic Beanstalk, Heroku, CloudBees come to mind.
Vijay Vijayasankar
@esjewett @wombling @vlvl @rhirsch @aiazkazi maybe PaaS will get there too at some point , but seriously doubt SaaS will
Ethan Jewett
@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Agree though that it’s not as key for applications. But we’re talking about PaaS, I think?
Vijay Vijayasankar
@esjewett @wombling @vlvl @rhirsch @aiazkazi PaaS ideally should have no lock in – just a question of how much scale justifies it
Chris Paine
@vijayasankarv @esjewett @vlvl @rhirsch @aiazkazi GApps, Azure, CloudBees PaaS are monthly, why not #saphanacloud?
Vijay Vijayasankar
@wombling @esjewett @vlvl @rhirsch @aiazkazi elasticity is definitely something on top of the agenda . Question – is monthly good enough?
Chris Paine
@vijayasankarv @esjewett @vlvl @rhirsch @aiazkazi Simple fixed CPU/data monthly makes sense, more elastic, then GApps style usage payment
Dennis Howlett
@wombling Isn’t the fundamental qu something like: ‘Why does #SAP find it necessary to invent new ways to confuse?
Ethan Jewett
@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Daily or hourly would be better, but one step at a time.
Ethan Jewett
@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Each decrease in granularity enables different scenarios. E.g. daily helps w/ month-end.
Vijay Vijayasankar
@esjewett @wombling @vlvl @rhirsch @aiazkazi what is your absolute best case granularity ? And is monthly a good enough alternative ?
Chris Paine
@vijayasankarv @esjewett best case is on demand pay as you use eg cloud.google.com/pricing/ low base price (monthly) then as needed – elastic
Ethan Jewett
@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Hourly is kind of industry standard, though monthly is fairly common for PaaS.
Ethan Jewett
@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi With PaaS, the case could be made for value in even more granular metering than hr.
Ethan Jewett
@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi But I’d say if you can get it to hourly that’d be great.
Yariv Zur
@esjewett @vijayasankarv @wombling @rhirsch @aiazkazi one more point – full elasticity is good for techies but hard on the CFO. (Cont)
Yariv Zur
@esjewett @vijayasankarv @wombling @rhirsch @aiazkazi they need the ability to forecast expenses. So for DEV we have full elasticity (free!)
Yariv Zur
@esjewett @vijayasankarv @wombling @rhirsch @aiazkazi for PROD you pay in advance for 1 yr, becoming acceptable for CFO #hanacloudportal
Ethan Jewett
@vlvl @vijayasankarv @wombling @rhirsch @aiazkazi Good point, and I think makes sense for apps but not for the PaaS itself.
Yariv Zur
@esjewett @vijayasankarv @wombling @rhirsch @aiazkazi PaaS is for running apps. “How much is the new supplier portal gonna cost me?”
Ethan Jewett
@vlvl @vijayasankarv @wombling @rhirsch @aiazkazi But usually PaaS is for dev to run apps. SAP’s take seems to be that cust manages PaaS.
Yariv Zur
@esjewett @vijayasankarv @wombling @rhirsch @aiazkazi IT manages PaaS, but the app is for the cust. Not for the DEV guy 🙂
Vijay Vijayasankar
@esjewett @vlvl @wombling @rhirsch @aiazkazi there are 2 broad uses – 1. custom development by a customer for their use and ..
Vijay Vijayasankar
@esjewett @vlvl @wombling @rhirsch @aiazkazi ..and 2. An ISV or developer building something for selling to others. different needs for them
Chris Paine
@vijayasankarv @esjewett @vlvl @rhirsch @aiazkazi and don’t forget customers with seasonal/fluctuating demand. (Repeating myself, sorry)
Vijay Vijayasankar
@wombling @esjewett @vlvl @rhirsch @aiazkazi yes agreed – needs to be solved absolutely, either at IaaS level and/or at PaaS level
Dick Hirsch
@vijayasankarv @wombling @esjewett @vlvl @aiazkazi 2 sides to consider — shop & platform – both need to support diff models
Ethan Jewett
@vijayasankarv @vlvl @wombling @rhirsch @aiazkazi Exactly. Much clearer than me :-). I hope SAP covers both. Right now, focus seems on #1.
Vijay Vijayasankar
@esjewett @vlvl @wombling @rhirsch @aiazkazi which brings up multi tenancy topic . Do u expect it as platform feature or leave it to apps?
Ethan Jewett
@vijayasankarv @vlvl @wombling @rhirsch @aiazkazi Yeah, very good point. Too complicated for twitter, and I need to sleep 🙂
Chris Paine
@vijayasankarv whilst @esjewett is sleeping 😉 how do you think from a PaaS viewpoint multi-tenancy could be delivered as a feature? (cont)
Chris Paine
@vijayasankarv @esjewett (cont) by building into the security/roles/authorisations of standard IDM solution? Extend to social login?
Vijay Vijayasankar
@wombling that could be a solution. but fundamentally a principle need to be agreed whether platform needs to even support multitenancy
Vijay Vijayasankar
@wombling it could also be that apps might want control of how to implement multitenancy without platform dictating it
Chris Paine
@vijayasankarv The worry is leaving it to app developers means potential embarrassment < but at least app developers fault not SAP!
Vijay Vijayasankar
@wombling it is like C++ and Java 🙂 I didnt like java for a long time thinking it took away my ability to fully control what I am building
Chris Paine
@vijayasankarv Be glad you never had to code Web Dynpro Java then 😉 Or if you did, then I can see yr point very well
Vijay Vijayasankar
@wombling I was already out of full time dev role by the time WD was widely used – but yes, did a little bit when it came out
Ethan Jewett
@wombling @vijayasankarv If SAP is going to certify apps as multi-tenant, it’s going to require a manual audit. No pure tech solution.
Vijay Vijayasankar
@esjewett @wombling rather left field question – do u think a model where apps are not certified by platform provider is feasible ?
Chris Paine
@vijayasankarv @esjewett feasible yes, q: is the value to partner to have SAP logo stamped onto app worth the investment? probably yes
Ethan Jewett
@vijayasankarv @wombling Sure, but then customer has to trust app dev. You can provide tools, but no way to guarantee data isn’t mixed.
Vijay Vijayasankar
@esjewett @wombling not a lot a platform provider can really certify beyond some minimum things like ” won’t crash, meets usability reqs” 🙂
Chris Paine
@vijayasankarv partners will build multi-tenancy solutions (I’m trying now) but social login means can’t leverage IDM solution anyway
Vijay Vijayasankar
@wombling yes – but do you think a hybrid of social login and traditional MDM can solve it elegantly?
Chris Paine
@vijayasankarv personally I find that too many frameworks complicate solutions rather than making them easier. Eg what happened to SOAP
Vijay Vijayasankar
@wombling 100% agree – and that is at least partly because very few developers think highly of other developers IMO. Too quick to dismiss 🙂
Chris Paine
@vijayasankarv still, would not be surprised if logic to allow multi-tenancy was delivered as is natural extension of current user mgt
Ethan Jewett
@vlvl @vijayasankarv @wombling @rhirsch @aiazkazi That’s what I mean by different. Bot sure if it’ll work, or the implications. Interesting.
Ethan Jewett
@vlvl @vijayasankarv @wombling @rhirsch @aiazkazi Though, SAP seems to take a diff approach to PaaS than other PaaSes. Need to think on it.
Dick Hirsch
@wombling related question would be if whether all the plumbing is there to deal with subscriptions #saphanacloud
My thoughts
A couple of days later and my question has be answered on SCN, but I’ve also had a few moments to think about this.
Drinking your own Champagne
Firstly, to my own need for a productive license to some very minimal use of the SAP HANA Cloud.
With the reasonably low price point that SAP is putting on Cloud Partner status, it certainly seems that they are trying to attract small companies to develop content for them. If you add to this, the “we drink our own champagne” marketing message that has been broadcast very well by the ex-CIO there is a obvious marketing proposition.
If companies that signed on as partners for SAP then submitted an application to the SAP Store for resale, they could be allowed to use it productively themselves, they would have an excellent sales pitch “we drink our own champagne”. A limit on the sizing of the used solution might be in order (but probably wouldn’t be an issue with small companies), but it would be very cool for small companies to do this. It would certainly encourage companies like the one I work for to go the extra step of putting the application into the SAP Store. A win for both the developers and SAP.
Annual fixed storage/cpu isn’t elastic, isn’t cloudy for a PaaS
Probably the clearest idea in the thread above is that PaaS shouldn’t be billed annually. Where we are talking SaaS (like Yariv Zur’s SAP HANA Cloud Portal (which is kinda SaaS and PaaS, but I’d argue definitely both)) then there is a different view, but for a PaaS, the beauty of the solution is in its ability to scale up as demand dictates.
I was talking to BCO6181 – Tony de Thomasis’ uni course this evening about the use case where you have a wonderfully capable server that has 10 CPUs running at 1-2% utilisation all year. And you have a policy that no-one gets a pay rise unless they complete their annual performance review. Guess what, on the afternoon before the cut-off, the system is running at 100% capacity and people are complaining about how slow and poor performing it is. In the cloud you shouldn’t have to deal with that. But if you have to buy your cloud compute units annually, you are going to be in exactly the same space.
On the plus side, it looks as if this might be addressed soon. I really hope so, as I see a big potential for SAP HANA Cloud to be the next big thing in enhancing SAP’s cloud SaaS solutions, but if it’s just a glorified hosting arrangement, then it starts to loose some of that PaaS shine.
Thanks to all those who posted their thoughts publicly for me to capture in this blog. I hope you don’t mind me reposting, let me know if you’d like anything redacted.