Barriers to Cloud / PaaS / DevOps Adoption and New Technology Renewal

As described in my simple guide to PaaS, SaaS, IaaS, BaaS, here “The Cloud” is divided into different services which all have common characteristics of incrementally, remote manageability, low initial cost and other characteristics. It is my most popular article.

Many organizations are taking significant steps to adoption of “The Cloud” but there are many that are struggling. I want to emphasize that the “Cloud” as a technology, as a business is a huge success with over $100 billion in sales in aggregate and gaining market share and importance daily at a huge pace but some organizations are still faltering.

In talking to some CIO’s recently I discovered some interesting problems that many organizations are running into adopting Cloud technologies around IaaS and PaaS that are critical to future success.

Some of the major stumbling blocks

If you are a startup organization then adopting the Cloud is a no brainer and relatively easy. You probably have employees who have used the Cloud and may not know how to do things differently. If you have an organization steeped in Cloud technologies you probably have already adopted.

What if you are an older organization with a significant set of existing applications, some legacy from different generations of technology and you want to move to the Cloud and leverage Platform 3 technologies but your organization is not “Cloud Savvy.”

A lot of these organizations are faltering in their Cloud strategy. The recent failure of Nebula is an interesting example where the problems of Cloud adoption can be. For more mature organizations there is a proven success model for how to go forward but first lets look at some of the reasons I’ve seen for failure:

Organizations may have one or all of these problems.

1) Technology Skills of People

The fact is that many people in organizations are not trained in Cloud technology, the newest open source technologies underlying PaaS/DevOps may be putting the organization at risk to adopt before you can handle it. You need a leader who can bring your organization to this new way of doing things and face all the hurdles that will be faced. He / She will need to be able to put in place education and training, find suitable initial projects to prove success and then come up with a plan to transition the whole organization.

Some people think this is all about tools and not about people. They are underestimating the difficulty of change. Going to a DevOps/PaaS technology is more a mindset and philosophy people issue than a technology issue although there will be specialized skills needed to get up and running effectively.

2) Lack of Understanding Cloud Disruptive Potential

If you don’t already have services in a private Cloud on premises, deploy applications in the Cloud or planning to do significant applications or services in the Cloud, you may not have enough value that will be generated by implementing DevOps/PaaS technology. This is frequently the case that many organizations don’t see the value and the need for change that will come from disruption.

3) Resistance by parts of the organization

Many parts of major organizations will resist the cloud as they will see it as a threat to their jobs, their existing way of doing things, existing applications or simply fear the change.

4) Immaturity of the technology

Cloud technology is rapidly changing and is also immature in some ways for some applications. Some users have been burned by bugs that don’t get fixed, capabilities promised and not delivered. Be careful about using technology that is too new. Find out how many customers are really using a particular technology. If it is less than 5 or 10 consider using an alternative solution even if it is only a short term solution.

5) Complicated for the business to understand

Cloud is new and difficult to comprehend sometimes. It changes and complicates some aspects of security, operations and costs. You need to gain experience before you jump in too fast. Given that Cloud is here to stay and has to be part of your long term success you need to make the investment to at least learn.

6) Fear Cloud security

Numerous companies still fear cloud security. I have a blog on this topic and believe that Cloud security is no more of an issue than your internal security probably less. That doesn’t mean you should walk in blind. Different vendors in the cloud have different standards and the threats can be different but overall I don’t believe this should be a concern for any company.

7) Can’t decide on an internal path that makes sense

There may be an effort to bite off more than you can swallow. If you are confused about the path or worried about the path take smaller steps. It’s easy to break your Cloud adoption into small steps.

8) Find the startup costs of the Cloud too high with too few takers willing to leverage the technology initially within the organization

Many organizations with lack of experience in the Cloud are simply not aware of how it will change their organization and what advantages it can be to virtually all parts of your organization. Education is the only answer. Find out more and more about the Cloud and learn from others what they did and benefits they got.

Initial Steps to Successful Large Organization Adoption to the Cloud, New Technology adoption

These are steps any large organization can do to start using the Cloud today with lower risk and big payoff down the road.

A) Adopt the Cloud internally by using an open source Cloud technology such as Openstack, Eucalyptus or others. Promote projects to use this internal cloud technology instead of purchasing hardware. Use Docker to package your applications and deploy in the cloud.

Almost all organizations of significant size can benefit by having an internal Cloud offering that gives internal projects a free or cheap way to get started and tested. If the project is a big success you can always either expand internal resources or “burst” to the regular Cloud for some parts or move the whole application to a public Cloud usually pretty trivially. The internal Cloud gives an organization experience with Cloud technologies without some of the hiccups of dealing with external vendors and the risks and unfamiliarity that this can engender in those who are not quite ready for the external Cloud.

Docker is a key standard technology developing that allows you to systematize the packaging of your applications. Learn to do this fast as it is easy and has payoffs all the way through the following steps.

This is where Nebula failed. They had problems finding organizations that could justify building an internal Cloud infrastructure. Organizations with less Cloud savvy employees may find it useless. Docker is a big advantage in enabling these organizations. You can take almost any existing application, even older school applications, package them in docker and then deploy them easily in an internal Cloud infrastructure.

What’s the advantage? It may not be cheaper to do this initially. What Nebula found was that organizations couldn’t find a benefit for this in some cases. It takes a somewhat longer view to realize the benefit of cloudifying what you already have. Encapsulating in Docker and deploying on an internal Cloud will give you experience but also over time you will find the flexibility, easier management and eventually shared resources will benefit the organization. It may not happen in 6 months but I doubt many large organizations will find that in 2 years their internal Cloud infrastructure isn’t a benefit either to pull together lots of disparate applications and servers into standardized hardware and administration or to facilitate eventually moving some to the external Cloud. Replacing services with new services or easier upgrade and deployment over time will come from a Docker strategy.

B) Do at least one project using the external Cloud right away (most organizations have renegade groups doing this already if it hasn’t been officially approved.)

Gain some experience with a vendor and start to get people trained by actually using the Cloud. It is almost certain that a large company has this going on whether IT is aware of it or not. Try to find these projects and bring them into the light and learn from their experiences. Start to expose the Shadow IT projects all over your organization and help them become better and learn across the organization to improve your risks and best practices.

Most organizations have limited space in their IT infrastructure for new projects. It can take months to free up a space to even put a server in. Using an external Cloud is a good way to get these projects going faster. You will need to learn the security risks and mitigations eventually, so you might as well start sooner because of shadow IT you are probably already taking those risks.

C) Move some parts of your organization over to DevOps/PaaS technology to gain experience with Cloud Automated Deployment technologies.

A big part of the gain in the use of the Cloud comes if you leverage DevOps/PaaS which automates the delivery of services and provides for more agile operation.

A lot of organizations start to build their own “PaaS” for a number of reasons. Engineering finds that a full PaaS is over their heads in scope and learning. DevOps using Chef and Puppet are starters to PaaS that help you gain experience in automated issues. So, operations adopts these tools and starts to build a PaaS.

A typical problem here is that management and Operations are scared of full scale automation as it takes away responsibility from a lot of people. The fact is DevOps keeps a lot of operations people around because the automation is hand built by operations people and run by devops it provides for faster more consistent delivery but not necessarily reducing costs of your own internal operations. PaaS will eventually make most of your operations group need to find new work. There is some work in understanding and bringing up and managing the PaaS but it won’t be nearly the same workforce size and maybe not the same people.

It is easy to argue that PaaS is too big a step but if you don’t cut the constant development of DevOps technologies you may find yourself essentially implementing an entire PaaS yourself with problems in stability, compatibility with other projects. I believe it is better to jump as fast as you possibly can into using a commercial open source or other PaaS technology that meets your needs or you will end up repeating the mistakes of many companies that have already gone down this path.

The benefits of PaaS/DevOps are significant and are critical. The ability to deploy to the Cloud quickly, to scale automatically, to deploy upgrades and to do this on a daily basis if needed is critical. This will transform your ability to respond to customers, to create value quickly and to improve every aspect of the technology side of your organization.

A full PaaS implementation will give you the ability to deploy new functionality daily if you need to. It will give you the ability to scale up or down as demand changes. It will give you much more agility to deploy new services and applications. These are significant benefits but the road there isn’t as easy yet as it should be.

One caveat I would offer is to look at mainly open source PaaS, but depending on your usage scenario you may need some features more than others. I have a blog on selecting a PaaS. I also have a blog on 9 use cases for PaaS. Please read both of these to learn key features and places to start.

D) Do an API Management project to start taking your existing services and providing user friendly RESTful APIs and mandate that new projects must put their APIs and services in the API store you build.

A key part of virtualization of your organization and leveraging the benefits of the new technologies including the Cloud is reuse of APIs. I consider this a critical and first step for many organizations. Most bigger organizations already have numerous services in the organization and it is trivial with a good open source API management product for instance to start to build your library of internal services to reuse and manage better.

The transparency that comes with the API Management adoption is critical to encouraging the kind of innovation and fast new product development most companies are looking to achieve with the Cloud. It also will start to give you a path to organizing the external APIs you use and managing all services your organization uses internally or externally as you grow your Cloud usage.

Most large organizations I talk to get the benefits of doing this step and it is the most profound change going on in most organizations in my opinion because it is a crucial step in leveraging new technology whether in the Cloud or not. I have a blog on 21 reasons to use API Management. Also a blog on API revolution and on the API/Enterprise Store and its importance.

E) Do an integration project with a Cloud Service such as Salesforce, WorkDay or other major SaaS vendor you are using today.

This is a trivial first step to cloud usage if you are already using a SaaS vendor. In many cases you will find that there is Shadow IT usage of SaaS in the company. If you provide amnesty or some other way to get these projects visible you can find the ones you want to endorse and then build integration to bring that “outlaw” usage into compliance with the organization by integrating it.

Almost every large organization using a SaaS product in the Cloud will want to integrate it with internal applications. Put the integrations you build into open source inside the company. See Inner Source. Place the APIs you use or build with this integration in your API Management infrastructure to give transparency and make it easier for others to integrate.

Bigger Steps to Cloud Adoption

After you have gained some expertise and experience with Cloud technologies and you have some people up to speed, some experience with some vendors and the ways your organization can benefit from the Cloud consider more widespread adoption

F) Move all new technology development to Cloud based technologies

G) Establish standard vendors for Cloud and sign specialized SLAs and security requirements with them

H) Consider the scope of a transition to virtual organization, what money could be saved and what it would cost based on real world experience you’ve gained in previous projects.

I) Put in place the performance and application, API management platforms, the PaaS automation to make large scale usage of the cloud automated, scalable and manageable. I have a blog on the new way to manage virtual enterprises.

G) Dismantle your hardware infrastructure and move or transition to new applications, provide lifelines to software and hardware that won’t be going.

“The Cloud” is facing resistance or failing in many organizations

Barriers to Cloud / PaaS / DevOps Adoption and New Technology Renewal