Thoughts on Cloud Brokerage

I wrote this post the Summer of ’13 in my old blog.  Bringing it here as it is still relevant in the Fall of ’15.

My thinking has matured, evolved and added. But before I can write that, I need to bring this back.

Service Catalog as a Service Broker. Putting Your aaS to Work

Recently I’ve been involved in a number of conversation around the relationship between service brokers, service definitions, the service catalog and the design of service interfaces.  I’ve encountered lot confusion and wrong assumptions, which have the potential of costing a lot of money.

So as a way to clear up my thinking, I’m going to note a few thoughts on this today. It’s not a finished piece by any means. Wear a hard hat while reading it; pieces will fall.

Let me start by saying I’m vexed by the phrase “Service Broker”. I’m often vexed by people spray painting new words on existing concepts.

One notion is that a service broker is the control plane and panel to obtain on-line services from external vendors. Which is fine, but this is also what a good, modern, non-service desk restricted service catalog provides. I have covered this topic in my last 837 blog posts.

The second meaning for a service broker emphasizes the word “broker”. The broker enables the customer to aggregate and arbitrage services to enable the selection of the service that is cheapest, best, compliant,  name-your-favorite-characteristic.

A common example used by proponents of “brokering” is for the contracting of compute resources, where we may want to decide where to place a workload based on price. After all, a Gigahertz is a Gigahertz everywhere, right. Hmm well, no. The network, storage, location, distance, latency, iOPS, liability protection, certifications, applicable laws and many other factors (Will someone pick up the phone? Is there a number to call?) matter.

I don’t believe there’s any commodification of infrastructure services coming any time soon (like the next ten years). There are just too many facets to internet services such as quality, latency, richness of offerings, laws, SLA’s, data sovereignty and others that prevent making effective like-to-like comparisons on the fly. We will need procurement specialists to do these type of comparative evaluations.

Also, if you drink coffee, you’ll know that coffee, which used to be a commodity, is anything but that today.  Coffee is a lot simpler to acquire than datacenter services. I’ll have my server with half-caf, soy-latte with a twist of lemon.

But even if we could flatten service definitions so they were more comparable (they can be flattened — sourcing specialists do it all the time), the acquisition process still doesn’t match the way the enterprise procures today.

Enterprises engage on two classes of spend: contract and spot. The majority of spend is contract. Why? Risk, pricing, security, control, quality, availability and convenience.

By the way, that’s why enterprises use e-procurement and constantly try to reduce the number of vendors under management.  It’s easier to control a smaller number of providers that are a large part of the enterprise spend, than thousands of small vendors to whom the enterprise’s spend is not meaningful.

For example, take the issue of liability: AWS assumes very limited liability for anything.  Most enterprise contracts have extensive sections around what happens when things fall apart and the network operations center cannot hold.

In my experience reviewing these type of contracts, these type of documents spend a fair amount of time defining the “service” – and it’s not an API call, but it’s the request process, approvals, support, training, incident management, remediation, service level that define the “service”.

By the way, I don’t meant to imply these contracts are actually workable or actionable –most are not– just that a lot of effort goes into creating them to try to define the “service.”

I once spent a week with a team of 15 people trying to convert a massive outsourcing contract into a service catalog. Turns out to be surprisingly easy to do it with 2 people, but impossible with 15.

Two recent examples help make the case for contract buying.  One, Amazon, who does offer compute pricing on a hourly basis, now offers one and three year leases. Why? By the hour pricing is like by the hour hotels, very expensive if you plan to live there a year.You are better off with a lease.

Second, the CIA announced a $600M contract with Amazon to build a cloud.

Well, they are the CIA, someone might say. Of course they need something more secure.  To which I’d say, baby, today we are all the CIA.

Also, if you read the drivers for establishing strategic sourcing and procurement processes, you’ll find a  analogous use cases to brokering: to stop maverick buying (we call it rogue in cloud), to reduce costs, implement governance, reduce or eliminate manual processes, apply consistent controls, rationalize the supplier base.

So it does seem like the service broker concept staples a service catalog to a procurement system; but will it cross the cloud?

As for the idea that somehow an intermediary can establish a market place of services and “broker” between enterprise and service provider, I don’t buy it – pun fully intended.

This approach did not work in the dot-bomb era with e-marketplaces. Turns out the buying power of large companies is significant, the internet flattens information brokerage and margins are way too thin for this intermediaries to earn much money.

As for brokerages serving  small and medium size businesses, I’d say yeah, sure. They are called resellers, like PC Connection, or TigerDirect, or yes, Amazon retail.  This is not a new development.

In summary, there are considerable transaction costs that need to be accounted for in the notion of service brokers. In the service catalog world we talk about policy, governance and automation as the way to get those contract terms implemented. In fact, most enterprise buying is contract buying and not spot buying.

I’ve argued that a service catalog already provides the functionality of a service broker and that there’s unlikely to be a marketplace of services that is profitable or that enterprises will change buying behaviors in the next ten years.

So is there anything new about this service broker concept that is worth considering? And the answer is YES.  The advent of service interfaces aka API’s opens a new service channel.

So for the first time we have the opportunity to design services that are born-automated. How do we think about them? What are their characteristics?

That is worth exploring in its own blog post.

As I said at the beginning, these are my preliminary thoughts. Comments? Questions? Observations? Organic, heirloom tomatoes?

Hi! We have a refugee crisis, it’s bad but it’s better than you think. Meet your local, friendly refugee!!

Hi. Nice to meet you. I would like to tell you a story about refugees and persecuted people that it’s fun and hopefully makes your day.

As we watch the news in horror, tens of thousands of refugee’s are dying crossing the the Mediterranean sea, walking through Greece into Macedonia and Hungary trying to get into France, England, Nordic countries. Anywhere where they can feel safe.

They need help, but they are not victims.

They are strong, resilient people who have taken their destiny onto their hands. They have chosen life over death. Peace over war.  Freedom over tyranny. They might make excellent neighbors once you get to know them. The block parties and bbq’s are going to be tasty.

At this point, they need help. They’ll be fine, once we help.

You may wonder, how  am I so sure?

Well, I’m a refugee.

I came with my family in 1976 under a refugee visa.  My dad spent three years in concentration camps. One day, I’m at school and my mother comes in and says, we are leaving. We met our dad at the airport, took a plane to San Francisco and here we were. Never to return where I grew up.

That visa is pretty legit. You are stamped REFUGEE and you have one year to get the necessary “green card” for residence. (Another story for another time).

I apologize if the suffering is not enough. Branniff airplanes were nice –first time on a plane. But being exiled from your country and family is a universal quality all refugees share. In taxis, hotels, airports, hospitals, restaurants.. we know each other. In a few words. We know each other. Uber drivers rate us five stars. We help each other.

So hello again, you now know an actual refugee.

One that has made a life here, played in a punk band, wrote a book, got married, had “anchor” children (Yet another story!), started company, employed hundreds’ of people, and whose technological innovation is core to cloud computing (or so I’d like to think). Right now I’m involved in helping global 2000 adopt the next generation of cloud technology. And yes, I am a refugee.

Some people know me as the founder of newScale, a software company acquired by Cisco in 2011. Some people would say I’m a “job creator”. I’d say I like inventing futures. But my influence is nothing compared to other refugees / immigrants like Andrew Grove, who escaped Hungary’s communist regime. Or Google’s Sergey Brin, whose parents emigrated from Russia.  All refugees. Steve Jobs’ dad was Syrian.

Hopefully, this gives you hope.

Immigration is a big challenge for any society. Yet it’s a big opportunity for our European brothers.   This massive, ambitious, bold group of people. If welcomed, integrated and helped might create the next European dream.

I write this because between the news narrative, native’s pejorative, the wonder of what could be is being lost.

So let’s start here. Hello. I’m your friendly, local refugee. Ask me anything.

Mind The (Widening, Accelerating Innovation) Gap

Mind the Gap - ink and wash

This is a meditation on the economics of innovation and minding the innovation gap.

It started when I read this article,Productivity Is Soaring at Top Firms and Sluggish Everywhere Else on the Harvard Business Review site.  The article has a terrific and terrifying graphic that shows the widening gap in productivity between firms that are innovating and their competitors.

Perhaps more importantly, the gap between the globally most productive firms and the rest has been increasing over time, especially in the services sector. Some firms clearly “get it” and others don’t, and the divide between the two groups is growing over time.

The strength of global frontier firms lies in their capacity to innovate, which increasingly requires more than just investing in R&D and implementing technology. It requires the capacity to combine technological, organizational, and human capital improvements, globally.

What the author, Chiara Criscuolo, calls Frontier firms are organizations that are experimenting and trying new things at the edge.  This got me thinking that it maps well to arguments I have made before regarding agility, the freedom to fail as the real strategic business value of public cloud.

The piece neatly makes the  case that “cost savings,” if it comes at the cost of agility and freedom to experiment may produce “false savings” when they cause the firm to fall behind.  Unfortunately, many senior leaders don’t formally track opportunity costs or productivity sink-holes the way they track procurement costs.

This translates into the internet meme that says: “Spend a $500 and get three levels of approvals and controls.  Call a standing meeting with 20 people? No one bats an eye.”

These “false savings” are effectively borrowing from the future to make the present seem rosy.

I’ve seen these behavior in sales organizations, where deals are “pulled-in” from future quarters to make this quarter look fine. I’ve seen it in engineering groups, where short term hacks result in “technical debt” that will be expensive to fix later.

You’ve probably experienced it when you get hidden fees from your bank or airline, which as clearly chosen “cash now” at the expense of customer satisfaction and/or brand identity.

Unfortunately, that debt does not show in the balance sheet where it could be controlled and balanced, but it is there. It will show up as increased costs of sale and loss of margin. Or product falling behind competitors and losing market share. Or customers moving to an online digital service with clear consumption pricing.

Whether the the firm chooses to compete with product, customer or operational innovation, there needs to be a “speaker for the future”– call them Chief Technology Officer, or CIO or Innovation officer. The name doesn’t matter; what matters is that it’s necessary to have someone(s) helping the rest of the organization guide the present decisions and map them to the future, to speak for the future.

CTO’s sometimes are also asked to be chief cheerleaders and marketers — that’s part of the job but that’s not the entire job.  The core part of the job entails getting deeply involved in the design of products and services, articulating a vision and an innovation road map, and helping senior leaders understand the trade-offs between now and later.

The Power of Cloud Driving Business Innovation

This is my talk about cloud at Hawaiian telecom university for non-technical people.

There are four parts to this talk.

First, what is cloud?

Second, how the world is changing, which I call “Age of Miracles” This is followed by a word from my sponsor about the intelligent business cloud and work we do at Accenture.

Then I close with a bit of how markets are being disrupted by cloud services — called, naturally, Age of Disruption.

This conference is attended by a large number of tiny, small and medium size business in Hawaii. So I felt a special obligation to try to summarize all this tech into a “What does it mean for me, personally? What should I do?”  Hopefully the intention comes through.

I was asked to wear Hawaiian shirt and a lei. This dude abides.

Cloud Blueprints Give Developers Freedom to Innovate

"1950 Architect Table with House Model***" i like the crumpled blueprints1950 Architect Table with House Model

This post was originally posted on the Chef blog. It’s reposted below for your convenience.

As a community, cloud developers are not prone to follow specific directions to deliver an assignment. Like pirates and cowboys, many developers would rather be left to their own devices to create solutions then follow an “Insert Code A into Line B” regimen.

So you’d think developers would take umbrage at a technology called blueprinting, which sounds a little too much like painting-by-numbers. But the fast-developing world of cloud generally, and blueprinting specifically, is evolving into an ideal environment for giving them more freedom to innovate, not less. Here’s how.

A blueprint is simply a template that describes infrastructure requirements, server configuration requirements, and application configuration requirements that can be built up quickly in an environment in a repeatable, reliable, and predictable way—and always in compliance.

This is an ideal solution for development and test teams, who need to deploy complex application stacks on a regular basis. This activity is labor intensive, error-prone and time consuming.  Blueprints make it easy for architects to define a complete application stack and provide a simple, repeatable one-click deployment, thus saving weeks of effort and enabling faster development and QA cycle times.

For developers, the value is that they can quickly launch reconfigured environments or reconfigured platforms in the cloud of their choice, a tremendous time saver. Instead of manually configuring these environments, they can be launched from a blueprint–and the list of available platform components is growing. For example, some users like to develop and test on a public cloud platform such as Amazon, then move the project to private cloud for deployment. Blueprinting technologies are helpful in making that happen by providing easy, one-click ordering for application development teams.

Chef is another central cloud technology that, when paired with blueprinting, helps developers do their job better. Chef allows developers to deliver code that automatically installs and configures their applications in true DevOps fashion. By defining the relationship between servers and required Chef roles in a blueprint, the developer is assured that their application is properly installed: repeatedly, reliably and consistently.

In short, blueprints allow precise specification of infrastructure and application configuration requirements, while providing flexibility for customization. Blueprints are enabling—not controlling.

Accenture understands that, in a sense, developers are the real target of cloud. So we’ve filled the Accenture Cloud Platform with developer-friendly tools and self-service catalogs. Accenture Tools in the Cloudis a manageable and scalable solution that offers projects the ability to significantly reduce lead times for getting development and test environments up and running while having continuous integration and delivery tools such as Git, Sonar, Nexus and Jenkins deployed and ready to use. The result? Developers can bring their cloud application ideas and solutions to the customer faster.

Blueprinting saves developers time, encourages innovation, and allows them to focus on what they do best.

How to Use the Dial Phone

An example of basic training for the first self-serve cloud service.

The transition from operator to self-service required teaching new practices like “dialing”, use of a “phone-book” and what is a “dial tone”.

“0” was the help-line to the operator.

What is intuitive to a young generation is not to to an older generation.

What is happening with cloud services is that a new generation is building, thinking and finding opportunities that the data center generation cannot even comprehend.

Evolving Private Clouds: Welcome Fishermen, Hunters, Cloud Admins & Other Liars

Liars Welcome

I’ve been meditating on Tom Bittman’s recent blog post, Why Are 95% of Private Clouds Failing? and what it means for the evolution hybrid cloud applications.

My colleagues at newScale, then Cisco and now at my current employer have been watching the same phenomenon.  We thought there was a high rate of struggle / flailing and probably a high rate of failure, but the number in my head was more like 40%.

To me, 95% is stunning. Rarely in tech do we 95% of anything. But 95% failure tells there’s something deeply wrong about what people think a private cloud is.

Tom’s recent poll shows 31% fail to change the operational model, 13% fail to change the financial model, and 11% spend too much time defending the status quo / doing too much and 10% on the wrong benefits.

From my point of view, these really all go into the bag of “failure to change the operational model.”

What does “failure to change the operational model mean?  On the ground, it looks feel like this:

IT doesn’t know what a service offering should be, the capacity management process is barely sufficient for static infrastructure. It  involves long planning processes,  ok for static capacity, but not adequate for real time infrastructure.

  • IT policies are executed through manual processes and forms that involve many reviews, not automated and controlled by software in real time. This introduces friction and delays to provisioning.
  • There maybe a little automation, but the developers don’t have access to this automation nor the API’s.
  • The financials are difficult. Either there was no chargeback, or IT doesn’t know the unit costs of their offerings–hard to know if IT doesn’t know the offerings.
  • It’s impossible to provide elasticity on a fixed amount of finite infrastructure, so more policies and friction are added to prevent over-consumption
  • App teams want all the goodies of cloud (elasticity, on-demand, etc) but are not able or aware that they probably need to make changes to their development process and architecture to really take advantage of a cloud architecture.

In other words, IT Operations “private cloud” is  something that is an evolution of virtualization, but it’s really not a cloud (standard, metered, on-demand, automated, elastic, etc).  As I wrote a few year ago, we go from From cruising at self-service speed to “we gotta have a meeting”

Meanwhile, over the last few years, developers have adopted cloud services en masse.. These services are elastic, on-demand, metered, elastic, etc.  No work needed to achieve that level of maturity required –there are other challenges, but those have become increasingly easier to deal, while the transformation challenge remains stubbornly immovable.

The result has been a kind of silo’d hybrid cloud. Things work one way in public, the tools are different, the people are different.  Something that Gartner has started calling bimodal IT. A kind of truce under the clouds.

Unfortunately, apps have gone hybrid and this truce has become war by other means rather than peace.  The private cloud that isn’t real can’t deliver what the developers need.

Hybrid cloud gets real

The biggest opportunities for enterprises today lie in how they will engage and interact with their customers. And these customers want to interact on their smart phones and tablets, while hanging out on Facebook, Pinterest, Twitter. The kids on Snapchat and WhatsUp, the parents deciding where to live on Zillow. These are new ways of living, shopping, entertaining, and socializing.

Meanwhile, the marketing and sales groups want campaigns to engage their customers where they are, in the way the customer wants to engage.  And the business wants measures and metrics to understand what’s effective and working in their marketing spend.  And which boss wouldn’t like to have a (positive) viral video?

This implies that to measure things that couldn’t be measured before, the enterprise may need big data to process those Google search streams, it needs a scalable video architecture to deliver those viral videos, it  need it’s login integrated with Facebook and Twitter to make it easy for the customer to engage — plus it gets better data from Facebook on what they like than from its traditional transaction systems.

All of these new capabilities also need to integrate with the enterprise traditional systems of record: ERP, sales, etc.

This is how we arrive at our hybrid app era: on the back of cat videos and a billion likes. These are today’s equivalent of the old appointment TV or water cooler shows of the sixties and seventies; which were underpinned by the need for consumer marketing and brand building by enterprises.

Marketing is not the only use case, but today this encompasses any enterprise that uses the internet to engage and transact business: real estate, banking, credit, insurance, travel, etc, etc — all are now internet businesses with a clickstream and a need to engage with their customers.

This year hybrid gets real because applications have gone hybrid

Hybrid cloud management now needs to be put in place. Not because hybrid clouds require it, but because there’s now enough applications across multiple places that this brings a new management problem: how do you managed both?

We noticed that the market is asking for a single control, management and service plane that encompasses both public clouds and private clouds.

And this is where the old private cloud – the one that failed to deliver – has to be matured to the next level or it won’t be able to be managed along with public cloud resources.

We are at the end of the era of fake private clouds and at the beginning of the hybrid cloud era.