Blog

Avoiding Obstacles to Cloud Adoption – Part 1


About Solinea

Solinea services help enterprises build step-by-step modernization plans to evolve from legacy infrastructure and processes to modern cloud and open source infrastructure driven by DevOps and Agile processes.

Better processes and tools equal better customer (and employee) satisfaction, lower IT costs, and easier recruiting, with fewer legacy headaches.

 

The Blog:

This is part 2 in a series. Take a look at Part 1 to get the whole story.
 
Avoiding Obstacles to Cloud Adoption

Part 1 of a series: Technology and Security

Problems with adopting cloud computing models have received plenty of coverage in recent years, however there is also a large and growing number of success stories; it is definitely possible to do it right. In this series of posts we will look in detail at some of the failure paths and how to recognize and avoid them – with an emphasis on private cloud implementations. This first post will focus on the technology implementation approach and will be followed by a second post on security. Future topics will cover more detail on building a successful architecture for your cloud.

Many of the “Top Reasons Cloud Implementations Fail” stories correctly observe that cloud computing is based on technology that IT people are already familiar with: x86 servers, virtualization, storage and networking. This leads some to mistakenly conclude that cloud implementation projects can be treated exactly the same as any technology project, and this is the problem that we will begin this post with.

For a recap on the prerequisites for a successful cloud implementation take a look at the two-part series on Making the Case for OpenStack: You Would be Surprised What Enterprises Overlook and Critical Success Factors, and the follow-up Five Cloud (or Open Infrastructure) Critical Success Factors – Redux.

Technology Obstacles

Your objectives are clear, executive sponsorship secured, KPIs are defined and agreed and the development team is waiting for their cloud APIs; so what comes next? If you’re planning to run the implementation the same way you would any other technology project, then this is a good time to pause and revisit the project goals. If those goals include reaping the benefits of cloud models for development and operations, or if your KPIs include deployment speed and agility then you might be about to make a wrong decision.

Here are some common mistakes when Technology teams select cloud platforms:

  • Use cases are overlooked. It is often assumed that all use cases can be supported simply by “maxing out” the technical specifications.
  • Over engineered technical requirements. Teams come up with an exhaustive list of technical must-haves. Extreme IOPS, maximum network performance, huge memory VMs, sub-second live migration, HA everywhere, and an assortment of the latest published features. The result is either impossible to implement or extremely complex and expensive. Product selection by market research reports. Unsure of technology, the implementation team studies all the available research reports and picks the ‘leaders’ in all the cloud categories and performs a weighted selection based on local preferences.
  • Designed around a legacy operational model. Non-functional requirements are gathered from how current infrastructure is operated. Automation is viewed only as removing repetitive tasks.
  • Proof of concept only involves infrastructure. The implementation team runs a PoC but does not involve Governance, Development, Security, and Operations teams.

The outcome of any of these decisions could be a cloud platform that does not meet the overall goals and KPIs. This may seem counterintuitive if you believe that OpenStack will smooth over any technology differences.

It won’t; here are three reasons why:

  • Vendor Selection: Not all OpenStack vendors’ offerings are alike. This is not to say some are better than others but that they have different opinions about how things should be implemented and which features and vendor integrations they are prepared to support.
  • Cloud Architecture: Not all cloud architectures are alike. Different use cases, security models, and non-functional requirements can call for very different architectures in both the control plane and the infrastructure components.
  • Technology Components: Your technology selection will indirectly force an overall architecture. If you did not plan a cloud architecture with your development, security, and operations teams then you will have one imposed at implementation time by the technology choices. 

Here is where cracks begin to appear. The security team doesn’t like the CMP, it won’t federate with their IdP. Governance can’t get chargeback data or enforce usage controls. The network team says there’s no way they’ll ever support user-initiated overlay networks. The developer automation tools are unable to use the platform API because of insufficient privilege separation. Security Groups are not considered sufficient and external manual firewalls must be used. Automation is impossible. All of these things turned out to be essential for making your cloud use cases work.

The reason these issues surface late is that they are not typical infrastructure or system software problems. At this stage of the project it can be very difficult to make rectifying architectural changes because many of the technology decisions constrain the solution. Additionally, other project stakeholders may be

Solution: don’t treat cloud just as a technology implementation

The corollary of cloud being based upon standard technology is that the most important aspect of cloud is not about the technology; it’s about how technology is consumed and the processes for supporting and managing that.

For a team accustomed to running traditional virtual infrastructure this is an easy mistake to make. At a single point in time an application running in a cloud looks exactly like an application running on your legacy hypervisor. The point overlooked is how did that application get there.

The solution is to make the technology selection decisions last, after the new cloud operational model is understood and a high level architecture is established, and then confirmed only after a proof of concept implementation.

Our preferred methodology for cloud platform deployment follows this order:

    • From the objectives and strategy, define the use cases that must be supported. These use cases should cover the process for developing/testing/deploying applications and well as governance, security, and operational use cases related to the overall objectives.
    • Architect a solution and technical requirements to support the use cases, reviewing with the development, governance, security and operations teams. 
    • Make a provisional technology selection and plan a PoC or Pilot implementation, selecting a target application to demonstrate use cases supporting project objectives.
    • Based upon PoC conclusion, confirm the technology selection and proceed with implementation strategy. 

    This methodology greatly reduces the risk of technology failure and ensures that the cloud platform will deliver on the program objectives and KPIs.

    The OpenStack documentation site contains a detailed Architecture Design Guide that covers design considerations for many examples. In the next post in this series we will summarize some of the more common architecture patterns for enterprise cloud deployments.

    Check back for our follow-up post where we will summarize some fundamental security. 

    Solinea specializes in 3 areas: 

    • Cloud architecture and infrastructure design and implementation, with a specificfocus on OpenStack – We have been working with OpenStack since its inception,wrote the first book on how to deploy OpenStack, and have built numerous privateand public cloud platforms based on the technology.
    • DevOps and CI/CD Automation – Once we build the infrastructure, the challengeis to gain agility from the environment, which is the primary reason people adoptcloud. We work at the process level and tool chain level, meaning that we haveengineers that specialize in technologies like Jenkins, Git, Artifactory, Cliqr andwe build these toolchains and underlying processes so organizations can buildand move apps more effectively to the cloud.
    • Containers and Microservices – Now enterprises are looking for ways to driveeven more efficiencies, we help organizations with docker and kubernetesimplementations – containerizing applications and orchestrating the containers inproduction.