Platforms are often represented in enterprise architectures, “marchitectures,” or as I like to call them, “burgers.” Today, I walk through some past, great burgers, from CORBA, to J2EE, to Cloud Foundry, and more. In doing so, I over some advice about how to find and care for your burger, especially when it comes to keeping your burger fresh.
Planned on topics
All the great burgers.
We’re talking about distributed applications – an application and the services (“backend,” “middleware,” database, ERP-system, etc.) run as their own application, accessed over an API (usually over a network, but could be on the same box, too).
What is it in service of? Software for large organizations: enterprise architectures.
Chargebacks! People love asking about chargebacks – “recouping” costs, metering usage. How should you think about these in cloud native land? There’s plenty of unintended side effects that can harm your overall strategy and business, so make sure to put a lot of thought into how you’re doing it, if at all! That’s today’s topic.
What goals do you have? This will determine what, when, and by how much you charge.
The idea of “recouping” cost can be crude. What if costs are high for one thing, but that brings down overall cost/raises overall value and price-premium, competative advantage.
I know this all naive and wishful thinking…
Like pretty much all of my work, it’s like flossing: we all smile and knod that we should do it, and then get on with managing the slow rot of our teeth instead of changing out mindset and behavior.
Onto the slow rot strategies!
Often, early on, you don’t charge. You want to drive adoption to deliver value (ironically). You might be doing your whole formula wrong. Should you measure per BU, per app, or per overall company revenue? See TDAmeritrade case of tracking ROI.
Also, consider the benefits – retire tech debt to get more agility; removing wait time/waste; being secure and compliant (how do you chargeback for “airgaped”).
Finding the unit to charge for.
These are all fun, technical details of curl’ing APIs, using fancier tools (like VMware CloudHealth and others)…
“The value of PCF is much higher than passing along the cost of power, compute, storage, networking, and operational overhead. How do you put a price on the value of increasing speed to market? On optimizing the value stream? On improving application resiliency? These benefits are meaningful to the business. This value is baked into the cost of the PCF product. But until application teams—and platform operators—fully experience these benefits, it’s counterproductive to assign a value to the platform.”
Plenty of APIs you can curl (see also VMware CloudHeath, etc.)
Decide on goals – adoption, “recouping,” etc.
Find the unit to meter, paper recommends memory, but your unit price can vary. Networking can be a huge part of costs, but difficult to measure.
The unit to meter can get sliced by org/cluster, pod/namespace, node/container…but also service…etc.
Beware of scaring people off and killing adoption, e.g., THD, MasterCard, many others.
Wikipedia, “The purpose of chargeback includes: (1)Making departments responsible in their usage, e.g., refrain from asking for resources they are not going to use; (2) Providing visibility to the head of IT and to senior management on the reasons behind the costs of IT; (3) Allowing the IT department to respond to unexpected customer demand by saying “yes, we can do it, but you will have to pay for it” instead of saying “no, we cannot do this because it’s not in the budget.”
Listen, I know all of this is “that’s fine for a FANG,” but a least aspire to not be lame and work towards this kind of thinking.
Rohit, 2017: “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!”
Coté discusses three ways he thinks about what “digital transformation” means, and then focuses on the software related one. That whole “BE LIKE A TECH COMPANY” thing people are always PowerPointing about. Also: technology actually is hard, and pre-dread.
Planned on topics
What exactly does “digital transformation mean.”
The Orange small shop owner example (from this talk, I think).
Revision of my standard speech: gettting better at software. To include new stuff from SpringOne and whatnot.
Fried Rice Transformation – cooked flat, with a ton of garlic. This is sort of a (pained, forced) metaphor for mind-shift. I was taught to make it in a wok. Look, even cracking the egg on-top is new. I’d never thing to make it in a flat pan, with that much garlic!
Often times, the way we talk about the benefits of cloud native can kick-up fear for operations people. Coté explains how the automation and standardization that comes with kubernetes, PaaS, and other such changes can actually be very god for ops people.