Stop Confusing Cloud Materials With Business Solutions

In reference to the David Linthicum article on Cloud Broker nirvana & the follow up from Gravitant/Zachary Perl, the desire and goal is solid that they bring up, "These cloud service broker solutions enable your business to govern and manage your cloud services more efficiently, saving you time and money on planning and provisioning." I have seen a lot of big IT budgets and trust me, the largest pieces of waste are not in the planning, provisioning steps, the main one is the skip over of hard enterprise architecture work upfront to engineer a whole goal supported business solution, then implement. See why below in the simple shed example comparison story.

Along with every great technology innovation or thing in last 40 years, the technology being used does not equal value inherently. The IaaS services, orchestration, unit metering, unit costing, aws sizing tools, virtualization, containers, AWS lambda, .... They are all just materials. The cloud broker can just get the materials faster and from many suppliers easier than you alone. Like having a fleet of trucks and drivers ready to run to home depot to get the lumber, nails, glue, piping or ready to assemble materials.

If you look at the recent and near term future of some key enabling technologies, you will see that we are progressing towards this desired state that David L mentions as a larger % of workloads will be candidates than today. Look at things like Openstack Heat, Hotlink, Scalr, Servicemesh/CSC Agility platform, vcloudAIR, the IEEE p2302 intercloud std, the intercloudtestbeddotorg, vmturbo(robotic control of federated containers,vm's), ucxchange. All of these are the technical materials plumbing, unit costing, IaaS attribute aggregation, and brokering market mechanism foundations. However, the piece that I feel is, and will always be the missing link in any technology is how to determine the effectiveness of the technology, to each and every workload's unique dynamics and requirements back to the business? 8,000 combinations exist today of selecting and deploying an AWS instance. How do you choose the right shape instance, the right way to pay, the right support level, the right integrated AWS services(Lambda, Redshift, VPC, Autoscale, AWS Portal for vCenter...) that is the best fit of that workloads unique quality requirements, code contextually aware, business purpose, security, sla, resiliency, economic decision tradeoffs? How do you do that continuously for every workload every day?

Here is a graphic with story example of what is happening today. (saved a ton $ doing the awful graphics myself :).

"Three years ago, it took us 6 weeks at home to provision the existing shed, and cost exactly $185,000 a month, and we are now needing to buy another one for expansion. We analyzed the materials and It has gold flake lumber, bronze nails, gorilla glue, and nanotech piping and 10 of the best craftsmen installed it for us."

"Tomorrow we are getting a cloud broker and used cloud compare to get the similar expansion shed we need on cloud. It will only take 2 hours before it's ready, and it only cost $100,000 this month, but next month they said between $85,000 and $165,000 because it can copy itself if needed, so still better than the one we have today! And, it will be on someone elses property, but they won't let us talk to their craftsmen who will be building it for us, so I don't know what materials they used, and I don't have any guys on staff that know how to maintain these materials expertly yet, but we'll figure that out."

Meanwhile, the enterprise architect obtained the business goals, processes, materials, locations, and roles from research questioning. Then the EA mapped those processes to goals, materials to the processes, created affinity values of what the business needs, the applications need, and aligned a business initiative grouping the 3 goals together and created a blueprint of what the new "Ideal Desired Shed" needs to look like. It took 4 weeks to architect and should only take 4 hours to deploy and should only cost $28,000 a month with Aluminum, rivets, rubber cement, and plastic tubing that has shape -shifting, auto-sizing, and can move itself to the best property based on the application owner's & IT's decision policy material properties built into it already. Tying back to the opening paragraph, the EA did use many new cloud materials and processes, but those alone don't equal maximum delivered business value unless applied correctly.

Notice how both the traditional and the new cloud brokered/cloud compared sheds still have about 50-70% excess wasted materials? That is because the shapes of apps being too wide, tall, or deep had to fit into a general shape that IT thought was best. The net cost of compute did drop down from old shed to cloud shed, it did get implemented faster with new risks to live with, but the EA shed achieves 4X more work over the life of the apps, near zero waste, known materials and staff skills to maintain, predictable small budget variance, and total effective cost per unit of compute consumption ended up being dramatically less again. So the cost per unit of the material is only a single data point result to watch, same with SLA terms of cloud, but do not make purchasing decisions on this alone! How many of you have tuned your AWS hypervisor and linux kernel settings expertly today, or implemented Java JVM virtualization, or re-architected to use spot instances,.....?Architecture trumps unit costs and material metrics comparisons every time.

The last example of what is happening occurs when you have these new processes and materials but every workload is unique with business objectives, application attributes, quality definitions, and potential computing resource pools to place it on. Just because you can now get the materials cheaper, better, faster does not deliver the required n-shaped shed needed by the business. One workload and tier class of workload(Cognos - Demo Environment) may need the standard shaped shed, but Cognos -Production Never Go Down workloads need a legit computer room pair in diverse locations with many dependencies. So although we can build the shed, computer rooms, warehouse, skyscraper, boat, airplane, village, city, stadium all using the similar materials mix a little faster, you are wasting the materials and missing the value of the materials potential value supporting the goal of the business unique dynamic requirements. The intercloudtestbed and OASIS/TOSCA is the tractor and cranes that will move the workloads from the shed to a computer room pair, orchestration(manual, semi-robotic, fully robotic) will make sure to shut down the shed when no longer needed. We'll be able to simplify and hedge our buying power using work contracts through ucxchange.

You have to be able to somehow get the application owner's decision making "gut feel" thoughts/logic into the workload management policy along with business ojectives, then all the infrastructure/application attributes, then prioritize architecture using experts, then implement. This is why so many on-premise and hosted/cloud deployments I have seen in last 17 years have so much room for improvement today, they did minimal or no architecture, just implemented and then morphed/maintained. You can't re-engineer what has not been engineered in the first place. Even if you got it right once, what happens when AWS drops pricing or service disruption tomorrow?

Lastly, prove explicitly with applied cloudonomics, data science, data visualization and data exploration tools to establish faith/trust by everyone that ties a map to goals.

Anyone got one of these yet? Or should I continue the adventure to build one myself?