Cloud – The Hidden Costs of Saying No

In the mid 1970s one of Britain’s most eminent theoretical physicists, pioneer quantum physicist, pure mathematician, metaphysicist (now residing in New Jersey aged 89) wrote an article called “The Hidden Costs of Saying No”. That man was Freeman Dyson who to this day is one of the most forward thinking scientific engineers to have ever walked this earth. His work in nuclear physics and quantum computing all led to major advances in things that we take for granted today.

The paper he penned in 1974 first crept across my desk as a student in the early 1990s and it’s as probably completely relevant today as it was the day it left his typewriter on that spring day in the mid 1970s. At the time I remember reading it as part of work I was doing around environmental technologies and investment in technology. Didn’t think I’d ever be pulling it out again but it’s pertinence to where we are today in Cloud is enormous.

The argument made in the paper essentially argues eloquently that the price we pay for not doing something should be considered carefully during the decision process, I can pull some key phrases out the paper here – and thirty eight years on they still resonate and are applicable to technology processes today.

Freeman writes “it is not enough to count the hidden costs of saying yes to new enterprises. We must also learn to count the hidden costs of saying no. The costs of saying no may be high, although they are often uncertain and intangible. Our existing political processes introduce a strong bias into the consideration of new enterprises”

“We need to know more accurately the costs of saying no, and we need procedures that allow a more realistic weighing of uncertainties when knowledge is lacking.”

In a nutshell Freeman described a lot of the things we take for granted working using Open Source methodologies and technologies. Daily development routines and complex decision making that is sped up by the adoption of combined global sharing of ever changing but singularly stable code trees. That code polished and brought to an enterprise market by Red Hat. Saying no to established costly proprietary ways of working that tie us into vendor lock in but also slow down the establishment and the stabilisation of future technology advancement.

In Cloud we have tangible decisions to take and those decisions impact on our core existing infrastructures as much as they do on our future road maps both for technology advancement and technology adoption. This also often the shapes of our businesses as we grow them either by harnessing more intelligent open ways of working. I am fortunate in working with some of the best and brightest from MIT and Dartmouth. I can count in my Rolodex (ok so artistic licence my email address book) some of the most capable technologists on the planet. We all, to a man (or woman) have grown careers and fostered approaches to our working days by sharing. We are daily creating pathways openly and in a community that stands up to be counted. In Cloud it’s no different.

The practical advancements in everything from storage to provisioning, from application deployment to lifecycle management rely on constant re-evaluation of process and often political dogma. We challenge regularly the recognised established old school ways of working in software environments to both satisfy the ever growing needs of our customerbase but also because as fast as we release stable supported code, the underlying network and physical hardware we rely on to pump those ones and zeroes changes. This then affords us new highways to motor down to deliver our cargoes certifying RHEL / RHEV / JBoss / Gluster in a supported release on these latest greatest technology environments. Honing, performance testing, securing and documenting to provide stable and polished deployable environments.

If we look at Platform as a Service, PaaS, a decade ago the decisions needed to get an application into a live environment to be consumed both internally and externally. This would have gone through a whole selection of change controls and also interpersonal relationships and decision making circuits within an organisation. All time consuming.

So we’re talking 2000-2, web based application development wasn’t in it’s infancy but the role of DevOps vs ITOps was a lot less equal than it was now. Silo’d mentality meant disproportionate decision making was often weighed to the advantage of the greater good rather than advancement. Open Cloud affords us now in 2012 the ability to utilise the best our developers can deliver and get that out in a safe and supportable manner and to do it using a range of tools, languages and libraries like never before – and to share this globally.

I truly believe the last proprietary technologies we will see in the datacentre are VMWare and to a lesser much smaller extent (because of current adoption levels) Microsoft’s HyperV cloud technology. While you could see that as a contentious statement the law of diminishing returns dictates that there is less available funding for IT projects globally, that our masters and our consumers are more savvy and expect more for their pound, euro, dollar, rupee, yen etc. To critically be able to do more with less headcount to be able to maintain what we have but to get to the next level with regards to being able to harness and deliver against business need.

The only way you can do that is openly.

The only way you can do that if you understand real world sane economics at a processor core level or at the application development and management level is openly. To therefore sink your investment into a proprietary core product and try and then stretch your IT architectures around something that makes you fit around it not you work to best advantage holds no credible place in the long term procurement strategy of the savvy CIO.

I was at VMWorld in 2012 in Barcelona. I probably will be blackballed for writing this and not get invited back but it reminded me of the same sort of protective over arching ethos of the Windows shows circa 2000-2001. When BackOffice was most at its hyped. BackOffice was great for those who needed a GUI to provision a file and print environment – to stand up a SQL database, to provision a mail system. It was the defacto go to environment of choice for those that counted their technical staff’s prowess by the number of trained staff who could click a mouse and read event viewer without falling into a coma. It was point and click enterprise computing at it’s most basic supplemented by “developers” who using Visual Basic and Visual Studio took runtimes and libraries of precompiled and often MSDN sourced libraries in order to get applications and databases to work. It wasn’t cutting edge. It wasn’t innovative and it’s a reason many of these organisations and system integrators got left behind both in growth and revenue by the more savvy tech startups who went Open and used code from Red Hat and the Open Source community.

For the companies that adopted an open strategy (the companies that have become the dot.com darlings and you rely on daily) they used Linux. They used Samba, they used Apache, they used Exim/Sendmail/Postfix for their mail as they spent money on people and research rather than on per seat licence or per mailbox licencing. They didn’t use Microsoft SQL or Oracle they just used MySQL or Postgres. The very rate they needed to develop using a paid for access model would have broken them but also the technology sucked (a lot) both from a performance perspective but also because you couldn’t get under the hood and tinker. They also contributed back – sharing information and sharing modifications for the common good. They challenged the hidden costs of saying no by embracing opportunity cost and common technical challenges rather than signing a EULA and waiting for the next MSDN CD box to arrive in the post.

The forward thinking companies who became the backbone of the internet relied on Linux. Not Solaris, not SCO, not Microsoft Windows NT or BackOffice. They deployed at speed and they were able to ride on the back of the speed of advancement of development environments such as PHP, Perl, Python, Java etc to get things done and to get things done stably and openly. These are the companies now with the banked revenue with the earnings figures and the technologies we consume (and Red Hat more often provide the support and provide the backbone to achieve stable platforms to base these technologies).

In Cloud we do the EXACT same thing, we build using what we have and we are brave enough to ask questions to understand what we have, and to understand what we need. We change the dynamic of IT by being brave enough to follow the example of Freeman Dyson.

In 1974 as part of this paper Dyson stated “Technology has always been, and always will be, unpredictable. Whenever things seem to be moving smoothly along a predictable path, some unexpected twist changes the rules of the game and makes the old predictions irrelevant.” A more visionary statement you are less likely to find in any management textbook or MBA guidance.

And for those who try to challenge and control or dictate privacy regulation or to impose territory or sovereign specific controls on Cloud. Beware, Freeman Dyson saw you coming nearly forty years ago and cleverly ties in William Blake’s writing he states with such punch that our elected officials in the EU and in other countries should take heed from:

“The other lesson that we have to learn is that bureaucratic regulation has a killing effect on all creative endeavor. No matter how wisely framed and well intentioned, legal formalities tend to become inflexible. Procedures designed to fit one situation are applied indiscriminately to others. Regulations, whose purpose was to count the cost of saying yes to an unsound project, have the unintended effect of saying no to all projects that do not fit snugly into the bureaucratic system. Inventive spirits rebel against such rules and leave the leadership of technology to the uninventive. These are the hidden costs of saying no. To mitigate such costs, lawyers and legislators should carry in their hearts the other lesson that Blake has taught us: “One Law for the Lion and Ox is Oppression.”

Freeman Dyson didn’t invent Open technologies but he does talk a lot of sense. At Red Hat we like to think that the paradigm shift that is leading us to Cloud has a backbone that is empowered by open creative technological folk wearing red fedoras that want to understand how you can get to Cloud today, securely safely and empowering you to be able to answer the difficult question you may face when positioning open technologies vs proprietary stacks. How much does it cost to say no ? After reading this article you should be able to answer a lot of that question yourself. Working with Red Hat we’ll help you get the rest of those answers using the knowledge we’ve worked on over the last thirteen years in the enterprise marketplace.

I was also at GigaOM Structure in Amsterdam recently and Brian Stevens from Red Hat sat on stage doing a fireside chat and was asked the question whether Github was the new Linux ? The question made me giggle nervously as Linux is Linux – there was no polished answer but it relies on a company such as Red Hat and a thought leader such as Brian, Paul Cormier or Jim Whitehurst to continue to prove that our work and our mission statement shares the same punch as Freeman Dyson’s almost prophetical paper did way back in 1974.

The same level of expectation around our support of OpenStack being critical for open hybrid cloud aligned with our proven Red Hat stack and we are doing it openly and transparently as Platinum members of the OpenStack Foundation. You can get the latest Folsom technology preview by clicking here for RHEL users. Challenging to say no to proprietary working methodologies, aiding and maturing OpenStack and the whole Cloud paradigm.

There’s one future-proof cloud and it’s open

Happy Thanksgiving, thanks for reading. With grateful thanks to Freeman Dyson one of the greatest technologists in the modern world. The original Sheldon Cooper.

Value Add – Tough Love in Cloud

There is no doubting the fact that as a lot of enterprise organisations and institutions who have for many years been wholly reliant on silo led computing platform architecture feel a little overwhelmed (or underwhelmed in some parts) by Cloud. Cloud the buzzword de jour, the spin. The undefined re-invention of IT. I see it a lot, and I hear it more. There seems to be this “Tough Love” battle of hearts and minds where the positioning of new IT enablement and design becomes more than technology refresh or even attrition to a position where Cloud becomes just part of the paradigm shift to doing more with less, or getting more for your dollar as you plan and procure your IT spend. It could even, if you outsource some of your current IT mean you spend less with your incumbent provider as you are able to identify and skill requirements and platforms internally with the people who understand your business the best – your current staff rather than hired consultants at arms length.

Cloud will, be under no illusion, also make those service providers and industry service providers increase profitability by being able to create elastic easily consumable cloud services that become stock catalogue items that sell themselves without sales people needing to push the hard sell. If that provider has the right services they become an asset and a building brick for growth – providing people want them. Where demand is met with intelligent solutions in Cloud there is a marriage made in heaven.

Last year, before I transitioned into this role as one of two Red Hat “Cloud Evangelists” I worked alongside the EMEA sales team in Cloud as their technical solutions architect helping providers stand up Red Hat platforms for customers to burst out to or to bring enterprise workloads too. It was enlightening because here was a software and services company working with the provider channel to build context extensibility into providers rather than just providing an OS or middleware capability. Real world business engineering (or re-engineering if you’d prefer to view it in that context) for both provider and enterprise customer alike to build a two way Open non-vendor locked in example of how we envisage those longterm hybrid and public workloads transitioning to Cloud. And then on the back of it building the provisioning and engagement model to assist customers to be able to just slot in as and when they felt the demand and push to do so. Getting over the “tough love” argument by making Cloud business as usual and easy to consume for both consumer of services – and the provider.

Tough Love – The Provider Angle

Service provision at any tier you can define as being able to take a blended approach of solutions and services that customers want or need to be able to contract. With Cloud it’s been hard for the service tier. A massive over emphasis on the hypervisor, on the provisioning and management and the self service element of the equation has left many now with an expensive overhead in the form of the ongoing licencing costs and ownership costs of proprietary technologies and layered or tiered infrastructures. Ken Hess and Jason Perlow of ZDNet explored this when discussing HyperV vs VMWare and there are a lot of other analysts who are now realising that at some point you are left in a position where that most basic cost of Cloud in the public or hybrid tier has to be passed on in the form of the contractual cost to the customer.

They are also missing a point. It’s not just about the provision of Cloud it’s about what you need to do with it when you get there as a customer, your development and deployment of architectures and infrastructures, your hidden ownership charges and your management layer on top. It would be great, and overdue somewhat for the likes of  GigaOM, Gartner and Forrester whose advice and guidance is read and given credence by many to now start thinking out the box and do more than just tickle Cloud ownership. There isn’t one credible ongoing analyst piece around the service provider tier and frankly when I talk to people (people being customers and decision makers) the positioning of left and right mystical fluffy quadrants needs to align itself to physically adaptable IT planning and positioning not just thought leadership and marketing budgets.

For service providers building Open infrastructures on KVM and in the past on Xen (although we now see KVM as the de-facto standard) and who understand the need to use open components such as CloudForms and OpenShift into the mix they are at a major advantage. They are better armed to be able to offer customers a customisable onramp to Cloud adoption at a pace that meets the appetite of sceptical CIOs but also that then reacts accordingly when the consumption and demand for services from that fledgling customer increases at speed. The ability for providers to have that flexibility and capability with the likes of Red Hat at a engineering level, matched and married to a software stack capability across storage, the hypervisor (RHEV KVM), the secure capabilities afforded by SELinux and sVirt, Middleware OpenJRE power in the form of JBoss, Gluster giving them the unstructured kick ass big data story and then wrap it up with their own ability to ride on the back of CloudForms (and DeltaCloud by association) means an immediate IaaS capability. Then as the customers who are already smart enough to be using OpenShift Origin to build out their sandpit PaaS test capability or to have used OpenShift on AWS start to demand hosted PaaS for that provider to be able to do so with applomb.

Bolt on capability = revenue, the providers who think out the box attract and retain customers longer and become an essential part of the foodchain of Cloud.

Tough Love – The Enterprise / Institutional Customer

It’s hard enough sometimes to run an enterprise environment at the best of times. The driving factors that push and promote the need for ever increasing attention to the needs of customers and consumers of your platforms and architecture are only beaten by the fact that from an accountancy perspective there is little to no elasticity in budgets that need to match or at least demonstrate an affinity for ambitions around elastic cloud. Now add on a new found skill as CIO. Contract negotiation at the most granular level. Signing an SLA is only made easier when you know what signing the solution with your Cloud Provider when you know 1) what you are signing up to 2) if you know what the problem is that you’re trying to solve by engaging with the provider.

Bryan Che of Red Hat writes brilliantly about his“2nd Tenet of Evaluating Products – You Have to Know What Problem You Want To Solve”. If it’s the only thing you click on in this article then I recommend you do so as it’s both thought provoking and influential in it’s steering as a guidance piece. Bryan correctly argues that the comparison of two given cloud products or services are aligned to understanding the problem that the consumption or procurement of that service will deliver. You can’t evaulate until that argument is understood and examined.

When we talk about Open Cloud it’s an understanding that to succeed and get the best out of the utilisation of compute capability in a manner that affords an enterprise something very clear. Independent, capable, assured performance married with a commitment to a flexible future as you grow.

An open provider who demonstrates that the tough love in Cloud is part of their problem, not yours, is the one who can give you the flexibility and the core belief to get to the start line (never mind the finish line). The good news is the smartest way to achieve that goal is for that provider to base his platform capabilities on Red Hat Cloud technologies.

It’s not just about the hypervisor and management – if anyone else tells you it is then it’s time to talk to someone who understands the pressures and needs of your expected IT delivery programme. Make sure they’re open, and make sure they use a certified supported open infrastructure married to a upstream that just happens to have millions of pairs of eyes examining its every release and move.

Pays to be open – but genuinely it’s the toughest love and the most responsible you can be when delivering future computing.