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.
Confusion with HANA Cloud pricing I got quite confused.
Then the conversation moved to twitter and we started discussing not just the price of going to the cloud but 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. SCN still buggers up the formatting that I have done, so if you want to see a slightly better formatted version - check out my blog at www.wombling.com it manages the formatting a whole lot better.
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:
womblingChris PaineFeeling slightly confused by SAPStore pricing for #saphanacloud if you understand it pls help me scn.sap.com/thread/3350483
rhirschDick Hirsch@wombling compare price to other #saphanacloud packages in #sapstore - all have similar structure
womblingChris Paine@rhirsch I understand the free ones but still confused what calculation is for rest, why show pm price when only pa purchase possible?
rhirschDick Hirsch@wombling a good question for #sapstore and #saphanacloud team - another reason to always read the small print
vijayasankarvVijay Vijayasankar@rhirsch @wombling it will get rationalized soon . @aiazkazi has plans for it
rhirschDick Hirsch“@vijayasankarv: @rhirsch @wombling it will get rationalized soon . @aiazkazi has plans for it” >> hope you guys are working on cloning him
vijayasankarvVijay Vijayasankar@rhirsch @wombling hehehe @aiazkazi is one of a kind - but he has a team behind him too to help with scale :smile:
vlvlYariv Zur@vijayasankarv @rhirsch @wombling @aiazkazi Pricing is presented as PM because this is how it was defined in official price list (cont)
vlvlYariv Zur@vijayasankarv @rhirsch @wombling @aiazkazi (cont) however min. Contract length for all cloud subscriptions is 1 yr. hence the mess.
womblingChris Paine@vlvl @vijayasankarv @rhirsch @aiazkazi certainly not the clearest situation. But then again probably simple than onPrem pricing
esjewettEthan Jewett@wombling @vlvl @vijayasankarv @rhirsch @aiazkazi Minimum 1-year subscriptions are not very cloudy. Are add-on resources more flexible?
esjewettEthan Jewett@wombling @vlvl @vijayasankarv @rhirsch @aiazkazi Really, I’d argue that it’s not even cloud if it requires a 1-year commitment. Hosting.
esjewettEthan Jewett@wombling @vlvl @vijayasankarv @rhirsch @aiazkazi Indeed, but for IaaS and PaaS I’d argue “cloud” involves elasticity. The NIST agrees 🙂
vijayasankarvVijay Vijayasankar@esjewett @wombling @vlvl @rhirsch @aiazkazi other than on iaaS (rhymes with aiaz) , I doubt perfect elasticity will happen for any vendor
esjewettEthan Jewett@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Every PaaS I’m aware of provides it. Elastic Beanstalk, Heroku, CloudBees come to mind.
vijayasankarvVijay Vijayasankar@esjewett @wombling @vlvl @rhirsch @aiazkazi maybe PaaS will get there too at some point , but seriously doubt SaaS will
esjewettEthan Jewett@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Agree though that it’s not as key for applications. But we’re talking about PaaS, I think?
vijayasankarvVijay Vijayasankar@esjewett @wombling @vlvl @rhirsch @aiazkazi PaaS ideally should have no lock in - just a question of how much scale justifies it
vijayasankarvVijay Vijayasankar@wombling @esjewett @vlvl @rhirsch @aiazkazi elasticity is definitely something on top of the agenda . Question - is monthly good enough?
dahowlettDennis Howlett@wombling Isn't the fundamental qu something like: 'Why does #SAP find it necessary to invent new ways to confuse?
esjewettEthan Jewett@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Daily or hourly would be better, but one step at a time.
esjewettEthan Jewett@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Each decrease in granularity enables different scenarios. E.g. daily helps w/ month-end.
vijayasankarvVijay Vijayasankar@esjewett @wombling @vlvl @rhirsch @aiazkazi what is your absolute best case granularity ? And is monthly a good enough alternative ?
womblingChris 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
esjewettEthan Jewett@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi Hourly is kind of industry standard, though monthly is fairly common for PaaS.
esjewettEthan Jewett@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi With PaaS, the case could be made for value in even more granular metering than hr.
esjewettEthan Jewett@vijayasankarv @wombling @vlvl @rhirsch @aiazkazi But I'd say if you can get it to hourly that'd be great.
esjewettEthan Jewett@vlvl @vijayasankarv @wombling @rhirsch @aiazkazi Good point, and I think makes sense for apps but not for the PaaS itself.
esjewettEthan 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.
vijayasankarvVijay Vijayasankar@esjewett @vlvl @wombling @rhirsch @aiazkazi there are 2 broad uses - 1. custom development by a customer for their use and ..
vijayasankarvVijay Vijayasankar@esjewett @vlvl @wombling @rhirsch @aiazkazi ..and 2. An ISV or developer building something for selling to others. different needs for them
vijayasankarvVijay Vijayasankar@wombling @esjewett @vlvl @rhirsch @aiazkazi yes agreed - needs to be solved absolutely, either at IaaS level and/or at PaaS level
esjewettEthan Jewett@vijayasankarv @vlvl @wombling @rhirsch @aiazkazi Exactly. Much clearer than me :-). I hope SAP covers both. Right now, focus seems on #1.
vijayasankarvVijay Vijayasankar@esjewett @vlvl @wombling @rhirsch @aiazkazi which brings up multi tenancy topic . Do u expect it as platform feature or leave it to apps?
esjewettEthan Jewett@vijayasankarv @vlvl @wombling @rhirsch @aiazkazi Yeah, very good point. Too complicated for twitter, and I need to sleep 🙂
vijayasankarvVijay Vijayasankar@wombling that could be a solution. but fundamentally a principle need to be agreed whether platform needs to even support multitenancy
vijayasankarvVijay Vijayasankar@wombling it could also be that apps might want control of how to implement multitenancy without platform dictating it
womblingChris Paine@vijayasankarv The worry is leaving it to app developers means potential embarrassment < but at least app developers fault not SAP!
vijayasankarvVijay Vijayasankar@wombling it is like C++ and Java :smile: I didnt like java for a long time thinking it took away my ability to fully control what I am building
womblingChris Paine@vijayasankarv Be glad you never had to code Web Dynpro Java then :wink: Or if you did, then I can see yr point very well
vijayasankarvVijay 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
esjewettEthan 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.
vijayasankarvVijay Vijayasankar@esjewett @wombling rather left field question - do u think a model where apps are not certified by platform provider is feasible ?
esjewettEthan 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.
vijayasankarvVijay Vijayasankar@esjewett @wombling not a lot a platform provider can really certify beyond some minimum things like " won't crash, meets usability reqs" :smile:
womblingChris Paine@vijayasankarv partners will build multi-tenancy solutions (I'm trying now) but social login means can't leverage IDM solution anyway
vijayasankarvVijay Vijayasankar@wombling yes - but do you think a hybrid of social login and traditional MDM can solve it elegantly?
womblingChris Paine@vijayasankarv personally I find that too many frameworks complicate solutions rather than making them easier. Eg what happened to SOAP
vijayasankarvVijay Vijayasankar@wombling 100% agree - and that is at least partly because very few developers think highly of other developers IMO. Too quick to dismiss :smile:
womblingChris Paine@vijayasankarv still, would not be surprised if logic to allow multi-tenancy was delivered as is natural extension of current user mgt
esjewettEthan Jewett@vlvl @vijayasankarv @wombling @rhirsch @aiazkazi That's what I mean by different. Bot sure if it'll work, or the implications. Interesting.
esjewettEthan Jewett@vlvl @vijayasankarv @wombling @rhirsch @aiazkazi Though, SAP seems to take a diff approach to PaaS than other PaaSes. Need to think on it.
rhirschDick 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. :sad:
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.
This post was first posted at www.wombling.com where the formatting is a whole lot better and I have a stock disclaimer so I don't have to write a new one every time like this: These are my own thoughts, opinions, ideas and errors, they should not be taken to be representative of the company I work for, who are awesome and let me write things like this without trying to censor me. If you are offended, or otherwise wronged by what I have written, please know this was not my intent, and please let me know so I can try to fix it.
Cheers!
- SAP Managed Tags:
2 Comments
