About Me

My photo
Rohit is an investor, startup advisor and an Application Modernization Scale Specialist working at Google.

Thursday, November 2, 2017

A View on Chargeback and Billing with Pivotal Cloud Foundry

We see that when enterprises install a Platform like Pivotal Cloud Foundry one of the primary motivations is to reduce the time to market. Enterprises want to fulfill their customer needs and leverage the platform and app dial tone provided by Pivotal Cloud Foundry to enable developers to push apps faster than before and rapidly experiment. There is however a real temptation to institute the same practices of yore to manage and onboard apps to the platform. Establish fine grained chargeback models that penalize innovation and count every nickel and dime when it comes to memory or network traffic or app or service instances on the PaaS. This defeats the purpose of PCF to encourage creativity and rapid genesis of ideas to production.

# So how does one think of chargeback in a new world. How do we get the profusion of apps on the platform and gain optics into cost and charge reasonably ?

Keep it simple. Observe, orient and act.

First and foremost remember PCF is a  PRODUCT and when you’re launching a new product whether it’s ice cream cones or a PaaS, if you don’t price it right based upon the market conditions, then no customers will come and you’ll be left with a bunch of melted ice cream or an empty PaaS. If  the market is undefined i.e. the platform engineers are not already doing chargeback for other infrastructure, any attempt to price PCF now would be a shot in the dark and more likely to over/under estimate the value of the product than to be hit the mark. And over/under pricing it both come with big risks in the both the short and long term. Put in place all the facility you need to understand consumption, do market research on what people are willing to pay.  Customers don’t even know the value yet until they start using it!.



Promote usage internally first, by observing usage amount/usage patterns/costs with earlier adopters before start charging other teams, otherwise adoption rate by dev teams may be low if the platform costs too much.

Build a model based on quotas as a starting point.  Show what the costs are for their entitlement NOT what they are actually using i.e. similar to the AWS model. Organization Quotas force accountability and make it way easier to do capacity planning. Pretty easy to get started.  There’s a cost to buying a lot and the Platform Engineers should not care what the app teams do with that lot.  If the app teams decide to deploy nothing platform engineers have still reserved whatever is in your quota.  Doesn’t mean that platform team can’t over subscribe resources.

# Resources


# Credits

PCFs Team - Caleb, Parker, Luciano, Zac, Clayton, David, Ian and Eamon