I have an article up on OpenSource.com directly related to the themes addressed here; outlining key decisions points, beyond the license, when considering open sourcing code.
Have a look: Open source code and business models: More than just a license
There are excellent examples of large successful ISVs making the most with the cloud, many of which are the next generation businesses that natively benefit from cloud availability and scale models. Netflix, Zygna, Salesforce.com, and many other market making examples show how to leverage the power of the cloud, and in most cases are either designed for, or even built by the scale provided in cloud computing.
But what if your challenge is in taking an existing ISV business into the cloud? What do you have to consider? Where do you start?
A good starting point is with the basics:
1. What is your value and how does it translate to the Cloud?
2. How will you transact with your customers in the Cloud?
3. Where does this lead you and your customers?
At Red Hat we have (and continue) to go through this transformation to the cloud. I will use Red Hat as an example of the transformation that I am seeing with other ISVs, with the appropriate, and amplified, disclaimer that I work for Red Hat, and that these views are my own.
Red Hat is certainly building new solutions specifically for the cloud, but just as importantly we are molding our core businesses to both leverage and provide value in new cloud consumption models. Under some definitions, Red Hat is as an ISV, having built a large enterprise business sold under a subscription model, metered via well defined metrics (sockets is our most prevalent example), through a large channel distribution relationship, with a large ecosystem of partners, backed by award winning support portals and services.
So how do you take a model like the above and translate it to the cloud? Following are some of the responses that we have conceptually made and how they might affect a typical ISV looking at the same situation:
1. What is your Value and how does it translate to the cloud?
2. How will you transact with your customers in the Cloud?
3. Where does this lead you and your Customers?
Ultimately, moving to the cloud requires that you rethink your Value as a business, what you mean to your customers, and how you want to be perceived going forward. It some ways this becomes an experience of really getting to know your own business in ways that you have not considered before.
Cloud computing is blending the fundamental definitions of consumers, suppliers, and service providers in such a way that distinguishing one from the other is increasingly challenging.
An ISV, who built on top of my products before, may now want to resell my products with their software. A customer who ran internal infrastructure on my products may now want to offer my product as a service to their customers. These may not be new questions, but they are rapidly enabled by the emergence of cloud business models.
This ecosystem singularity (no, not the Technological Singularity) blends routes to market, handily breaks existing legal constructs, pricing frameworks, and most importantly – forces the reevaluation of what value is being provided and to whom.
A basic question that has to be asked today is: Does the cloud give you as much choice as before?
From a technical perspective, the debate on Cloud APIs is well underway. OpenStack, Amazon APIs, etc. all frame the questions on how to engage with a series of public providers from a technical perspective. Openness is keen here so that an ecosystem member who will be consuming the services of one or more clouds, has the ability to choose between vendors.
However, when the concept of business relationships enters the discussion of cloud consumption, a path to answer the above question about openness is not yet as clear.
Example of Future Yore (Today?):
As over-simplified example:
Take an ISV that historically provided packaged software, priced as a license with annual maintenance, delivered via a distributor, who sold it via reseller, who delivered it to an IT department, who married it with: hardware from an OEM, an Operating System (disclaimer: I’m partial to Red Hat Enterprise Linux), installed it in a datacenter, and maintained it for an internal Marketing department, who used the running software to develop and distribute a marketing campaign to customers, who buy the companies product.
Whew.
For simplicity and without reducing the value that each provides, I have excluded managed service providers, system integrators, hosters, and a sundry of other services that typically get injected into larger deals. Note also that I conveniently ignore the complex topics of compliance.
Breaking down the actors in this example:
Sample value provided to/by each of the actors:
While complicated, the story works and has evolved in the free market (when everyone plays fairly) to provide a competitive environment that encourages innovation of services, value, and cost.
The ISV knows how to craft legal language, price their product and sell it to the distributor, the route to markets innovate their services and build relationships with the service provider, the service provider knows who to call and how to buy more product or renew their maintenance, and the consumer knows where to go to get service for their application, while the customer doesn’t care about any of the above.
What is interesting in this, is that there are multiple, ingrained business relationships, backed by legal contracts, pricing constructs, support relationships, supply chain relationships, and ultimately expectations on appropriate business relationships. These took decades to develop a natural ecosystem based on relationships that provides value to customers.
And relationships are free to change.
If a reseller does not meet the expectations of the company, then the IT Department can start purchasing from another reseller (or perhaps the ISV directly). If the Marketing department does not like the software it is receiving, it can work with the IT department to find an alternative software vendor. If the Software Vendor does not like the service that its resellers provide, it can contract with other providers.
Sure, lock-in does occur, but there are alternatives at each stage of the cycle bounded by multiple business and technical relationships.
World of Tomorrow (Today?):
So what happens when the Cloud enters the scene?
Trying to keep the same example framework, and massively oversimplifying by using a Public Cloud with an ISV SaaS:
An ISV develops a piece of software, prices it as a service based on number of campaigns, which is premised on continuous consumption by, and possibly directly with, a consumer, then finds a route to market, which in this case is a Telecommunications Company who has released a public cloud and starts messaging directly to the Marketing Department (the consumer) using its own service on the Telco’s cloud and provides the service directly to the Marketing Department who builds and distributes campaigns to customers.
Breaking down the actors in this example:
Value provided to/by each of the actors:
Ultimately, the consumer and customer still receive the same service and hopefully on a more consumption based model. However, things that have changed:
I do not portend to state that the Distributor, Resellers, and IT Department don’t have roles to play – as simple tweaks to the above example would have included them just as easily with a Private Cloud.
Where this is leading us?
The relationships that have built up through the open market ISV, Channel, OEM, Consumer are changing. Understanding the complexities that the cloud model introduce is not merely a case of understanding the technology changes, but as importantly – how the business models that emerge in the cloud will affect how you interface with your customers and suppliers.
The core question that you need to ask regardless of your role above is: How can I keep my choices Open.
Public, Private, Hybrid, Community – the deployment options for deciding how to use a cloud seem pretty clear…until you try to actually distinguish between them.
As many have done – you can start with the definitions provided by the National Institute of Standards and Technology in the NIST Definition of Cloud Computing by Peter Mell and Tim Grance.
I’ll leave it to you to read the very short paper (recommended) – but let’s focus on the definition of Hybrid Cloud from NIST:
“Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).”
As I speak with consumers of public clouds, ISVs determining their cloud models, channel providers determining how they will participate in the cloud, and last but not least the service providers who are/will offer a “public” cloud – when the question about the hybrid cloud comes up the practice of Public and Private being “bound together by standardized or proprietary technology that enables…” is deemed insufficient. There are business and operational requirements that not only go beyond the technology, but make it even harder to distinguish between the public and private models and combine those into a hybrid model.
Rather than trying create a canonical definition for hybrid, I encourage everyone I speak with to look for a continuum that ranges from Public to Private, where the technology, operational support, and business models are considered as separate components in the definition rather than the defining characteristic of hybrid (or public or private). I have a hard time fitting the community into this model, but I’ll save that for a later tome.
To focus in on the Operational aspects of the hybrid cloud and its challenges I can take a real-world example from some of my discussions.
Background:
A large corporate IT department (think 1,000+ employees) builds a certified gold master server image. This image consists of configured OS, custom scripts, in-house applications, and even some 3rd party applications depending on target deployment. The image is managed by an internal release engineering team, released under strict certification guidelines, and rolled out uniformly to any servers within the corporation’s environment.
This gold master server image is defined such that the 1,000+ staff in the technical staff can rely on the fact that they have legal, technical, and support coverage. There certainly may be software or custom configuration that meets industry or government regulation that the corporation’s IT and legal departments require to ensure compliance. At any point in time, there are multiple versions of this image that must be tracked, maintained and supported by the IT department.
In many ways, the IT department is a Software Vendor (although not independent).
This model has worked for decades for both on- and off-premise. For example when a department in the corporation needs to leverage an external hoster or service provider. Yes, it’s hard work – but understood.
Enter the private cloud:
Things go relatively smoothly since very little changes in the operational models, whether (as the NIST definition promotes) the cloud is on-premise or hosted at a 3rd party. The IT department still releases the same software and manages those across now a virtualized set of servers. There will be changes such as managing sprawl, allocating resources efficiently, and tracking where things are deployed – but the management software and models exist or are tenable. As long as everyone deploys the same gold master images, the environment is controllable.
Enter the public cloud:
Taking the purist view of IaaS with virtual machines running on a multitenant server (and conveniently ignoring SaaS and PaaS), things may change more here. What happens when there is no import mechanism for the gold master image from the IT department? Are there tools for the IT department to rebuild the exact image in the public cloud and have a controlled release to their internal users? How are images and instances updated? Does the public cloud provider or service provider manage the images and instances on behalf of the customer?
Many of these questions will be eliminated by partnering with a provider who permits the IT department to do most of what they need, but changes will be injected to accommodate new public cloud models wherever necessary.
Enter the hybrid cloud:
Take the same questions introduced in the public cloud example and attempt to marry the complexity with the private cloud. As defined by NIST, the technology enables data and application portability, but does the operational model of the combined private and public environment work in such a way to permit a single gold master to be deployed and managed between both in a consistent fashion?
The hybrid cloud in this case is adding yet another layer of complexity that must find a match in the operational models between public and private for the gold master, without adding undue complexity, without reducing the benefits that are afforded the combined deployment models.
There is much more to the hybrid cloud than the technology enablement. Consider the impact to the operations team and how to serve or modify the models that have been built up, yet know what you are getting in the hybrid cloud and hopefully in the process we can start defining what hybrid means.
Today, Red Hat launched the first highly available file system for Amazon Web Services, Red Hat Virtual Storage Appliance. One of the first articles written about it was from Barb Darrow on GigaOM, Red Hat attacks cloud-app gap, which I think illustrates a very important aspect of which the cloud is enabling. Specifically, that there are existing applications and systems which may start to benefit from the cloud now that infrastructure services are beginning to present consistent and familiar services to what the applications already use.
Earlier in my career I worked at two startups which were focused on the “Legacy Transformation” market. At the time the intent was to legacy COBOL/JCL/VSAM code into modern languages by extracting the nuggets of value – marketed as business rules – and transform those into manageable objects and constructs that both matched the state of the art in coding as well as were more malleable and reusable for other purposes. I spent far too many hours using tools I had helped write to recode systems into Java and C/C++ so that they would mimic what was being done in the original system.
That is all they were doing – mimicking what had already been done.
There was no discussion about massive scale. No focus on how the legacy systems could start to serve new markets in innovative ways. Just that they would be “modern”.
Some of the biggest issues were not with the business rules themselves, but transforming the applications so they would work with the new services provided, including 3270 terminal to Web migrations, flat file to relational db migration, etc. While there were, and likely still are, success with some of these migrations – many of these ended up either remaining in place on the original hardware and support infrastructure because the business benefits were not sufficient to justify the migration.
The older environment just worked well enough.
With Cloud, specifically the public cloud, I believe we are experiencing a change of capabilities, rather than a change of technology. This means that while there will be new services which are built on and by the cloud – think Hadoop, Condor, etc. – which have and will engender, often in mind-blowing ways, new services such as Big Data – there will also be a significantly large category of applications and systems that can to take advantage of the business value the cloud presents without significant technology change.
Crawl, Walk, Run.
That doesn’t mean that these systems can’t and won’t take advantage of where the cloud can lead them – but it does provide a starting point for systems that provides incremental value, whether Shadow IT, or basic scalability, that would have otherwise been more challenging or impossible to achieve outside of a cloud environment.
For this, these applications will need a consistent environment in which to run. Whether the OS, database, networking services, security constructs or, as Red Hat announced today, a consistent file system.
As these support systems come online and present familiar APIs and services within the cloud – they in turn will start to provide more capabilities to the “legacy” applications than would have been available in the legacy environment.
A good example is with a single Virtual Storage Appliance being able to scale to 100TB linearly. Sure, that could happen outside of the public cloud, but it is the business and operational model of the cloud that makes that type of scale possible. The Public Cloud business model provides the storage, immediately, that many IT shops could never provide…without requiring changes to the design of the application.
Consistent application, consistent interfaces, but massive scale enabled via the business model of the public cloud.
There will always be improvements possible, such as applications specifically written to take advantage of cloud-scale. But the first step is to make sure that applications work as they did before and can take advantage of capabilities provided by the new business models of the cloud.
As I speak with my co-workers and industry associates, one of my favorite quotes is: “product management is hard.” So hard, that academic studies, personal careers, and massive industries are built around just defining the practice of identifying, building, delivering, and maintaining a new product in a market.
But what happens when what is being built is not a product, but an amalgam of new and old technology, offered under non-industry-standard business models, condensing multiple sales routes and channels, which spans global markets simultaneously, and holds the promise of transforming every industry by enabling new solution categories, all while delivering infinite power and data directly to an individual sitting on their mobile device in a remote part of the world.
This is the Cloud.
The Cloud is not a product that needs to be managed, but a change in the business, operational, and technology models that affects every individual and entity that sells or consumes information technology.
So, if product management is hard, how do we even start to address what happens when the technologies enable an entirely new consumption model? How does a business adapt? What are eventhe questions that need to be investigated?
Keep it Simple, Stupid.
I have worked with ISVs over the past 20 years building new products, integrating new products, and partnering with offerings from partners. While there have been many checklists on launching a new products, different development models, and curriculum and certifications of excellent frameworks for creating a business and product; none of these seem to work when the question is as broad as what Cloud presents.
Rather than focusing on the breadth of the question of how to address Cloud Computing and its flavors, such as SaaS, IaaS, and PaaS – I have found that by thinking of three arenas; Business, Operations, and Technology, we are able to start communicating where the questions may lie. With the caveat that some of the below are tainted toward both Red Hat, some representative questions we continue to ask:
Business:
Operational:
Technical:
There are many, many other questions to be asked so the above is not inclusive by any measure. However, by repeating the conversation around Business, Operations, and Technology – I have found that we can at least articulate to those that are not part of the conversation how they can participate.
