Article

Private Cloud: The Journey

Starting a project to build out your private cloud is certainly no easy task. It not only requires new skillsets, but can also be seen as a threat to teams who have operated IT the traditional way. In addition, once you have your private cloud, how do you make sure the users have a great experience and start to take advantage of the investment that has been put in? Are you creating services that are meaningful?

In this series, my goal is to walk you through key parts of the journey to a successful private cloud that provides Infrastructure as a Service (IaaS).

Where do you begin?

First, with a cloud strategy.

Without a cloud strategy, the project will most likely fail. This strategy needs sponsorship across multiple teams and support at the highest levels of the organization. In all the workshops I’ve been in, it is clear that there are generally disconnects between the various silos in IT and, in many cases, major misunderstandings in how each group’s varying technologies work.

For example, when talking to one team about automating an operating systems deployment, one engineer asked, “How do the servers get backed up?” This engineer represented server deployments but did not know how backup works, only that it happens after the server gets built. As it turns out, there were additional requests the backup team was expecting, and often just found out later by chance that they had missed some VMs during a routine check, and then added to the list.

Another example, which often comes up, is how service management tools work with the cloud. Where does the enterprise service catalog end and the cloud blueprint catalog begin? These questions, along with many others, all need to be answered in conjunction with the various teams’ input.

Once this is complete, there should be a clear direction of the technologies involved and a roadmap that shows the journey in multiple phases.

How do I make the cloud meaningful?

While there are a lot of pre-packaged workflows and deployment guides for getting the cloud up and running, no two clouds are the same. Infrastructure and consumers differ greatly between businesses, and it is extremely important to build a cloud that means something to you.

Some questions to ask early on in the strategy phase include:

  • Who will be using the cloud?

  • What services do they want to consume?

  • Can we use this as an opportunity to make the entire process more efficient?

  • What about operational tasks?

  • What types of daily requests does the IT team typically receive?

  • What are all the handoffs that go into an operating system request?

Milestones

Many cloud projects simply try to launch with too many features. In fact, many organizations look at cloud as a project that people get assigned to and then roll off onto the next one. Instead, the most successful clouds are the ones that constantly provide new services and have a continuous flow of communication from IT back to the consumers.

When you have finished your first cloud launch, be prepared to already be working on your next set of services.

A typical maturity model for your cloud may look something like this:

cloud_maturity_model

Starting with the most basic service, like an operating system request, and then gradually adding new services provides a great way for the cloud team to learn the new automation skills they require and learn from the pilot groups.

Fully automated OS request

This is generally the first offering you will present in your cloud as one of the main use cases is for Windows and Linux servers. The reality is that even getting to a point where you can offer this, although it may sound simple, will require a number of automation tasks to be completed first. We often refer to this as the plumbing phase. From the requester perspective, they only really care about the OS and, eventually, any applications you offer as services. From the infrastructure team perspective, however, there is a large amount of automation that needs to be coded for all those mini tasks and team handoffs that have historically happened. Think of tasks like IPAM, Backups, Monitoring, Host, Storage, Agents etc.

Think of this as building a Microservices task library.

microservice_task_library

On average, this piece takes three to six months, depending on the complexity of the organization, and requires a dedicated team to be highly focused. It’s certainly an investment but, once complete, doesn’t require a lot of maintenance.

In the next post, we will dive in deeper into this area and how this can be broken down further.

Moving up the stack

Once the “plumbing” phase is complete, every additional service you offer is generally another configuration of the OS. This is where tools like Puppet, Chef, Saltstack, and many others really shine. We can create a number of configurations in these tools and then ultimately present them as services in the service catalog.

Multi-machine blueprints and network/load balancing

As the journey continues, you will end up with a number of pieces that can make individual server blueprints, but what about deploying environments? At this point, the shift moves to building more complex, multi-machine blueprints.

Examples could include:

  • Three-Tier Windows App
    • 2 x Web
    • 2 x App
    • 2 x DB Servers with sample data populated
  • LAMP stack
  • Two Linux VMs with a software load balancer
  • Elastic applications that can join or unjoin themselves from a load balancer pool

There are a number of combinations and use cases at this phase, and again it depends on what the consumers are demanding. This is a great place to work with the software development and QA teams, as they often need environments quickly. In addition, it is also a great way to deploy training environments.

The journey never ends

I think this is the final point I will leave you with. The cloud needs to continue to evolve, and marketing all the new features to the business is key. Maybe the next phase is to offer a new hypervisor choice or a public cloud option? How are we integrating show back effectively? Should we focus on offering more and more application templates? Can we eliminate additional complexity in the infrastructure and reduce user choices?

With each new project that requires infrastructure, it’s an opportunity to utilize and expand the cloud services to meet those needs.

Stay tuned for the next part where we go through the automation technologies in more detail.

Schedule an AHEAD Lab Briefing