Finally getting around to doing this blog, it’s been a busy few months with lots of change coming in the new year for me.

I have been discussing automation and cloud strategies with customers for a while now and the themes that come up time and time again when discussing cloud are;

  • Multi-cloud usage - they envisage making use of multiple public/private cloud as well as their existing on premise investments and want to use single providers (a big shift to the way It has worked over the last 15+ years)
  • DevOps friendly - devops, devops, devops is something customers are talking about and trying to bring that culture to organisations or the development community have already adopted the culture and Infrastructure teams are being expected to catch-up and provide tools to make life easier to the DevOps guys and gals.
  • Visibility of cost and what/where applications are deployed
  • Governance, control and enforcement of policies

When these sort of topics come up it often leads me into a discussion of the multi-cloud management capabilities Cisco have. While Cisco has number of solutions around cloud one that is resonating well at the moment is CloudCenter.

So what is CloudCenter and why do I think it can help?

Back in April time Cisco acquired CliQr which is when I started to play with in the lab and got a heavy focusing as one of the technical pre-sales experts covering the UK & Ireland. Over this time I’ve had many conversation with customer and how it can help solve some of the cloud strategy challenges.

The official homepage to the solution is here, although a lot of the useful material is still on the original CliQr website while assimilation occurs.

Before I breakdown how it can help let’s see some official material form the BU (the stuff that I think is pertinent anyway);

  • Bring extra value when using ACI

The mantra is ‘Model’, ‘Deploy’ and ‘Manage’ which means that you model your application once and then can constantly deploy to any supported destination (cloud or traditional on-prem virtualisation) and also provide visibility and management of your application.

What I usual highlight

I tend to take the official messaging and put my own twist on it (I personally find the American centric material doesn’t always translate in the UK. I also prefer to use whiteboards over powerpoint, although that’s not always possible so I created the below as a single slide to talk around the capabilities.

Model

You model what an application looks like using what CloudCenter calls ‘services’. Applications can be single servers or more complex depending on what is needed.

In the above diagram you can see an example in the top right where I have used various different components (services) to create an application that is services end-users. You can see that it consists of;

  • NGINX - Load Balancer Capabilities
  • Apache - Web server for end-users
  • Redis - Database cache and message broker
  • .Net - To provide Application Logic
  • Postress Database - Store Data
  • NodeJS - Used to provide backend visibility of records in the database

You are provided with the ability to graphically create this model in the tool, including dependencies and what configuration is important to the installation of the service (operating system, application code location, database schemas etc.)

It also allows you to define the security rules that are required to access each of the services, for example the Apache service would probably only require TCP ports 80 and 443 to be opened up;

Once the ‘firewall’ rules have been configured these will be used when the application is deployed to automatically configure security (based on the capabilities of the target destination, uses features like AWS security groups or Cisco ACI etc.).

The idea is that your infrastructure admin will create and define what a ‘service’ will look like. This could be the location of the installation files, the operating systems that can be used, code locations, firewall rules, migration steps, in fact pretty much anything that is needed to satisfy the organisations requirements to get things up and running. Once the service has been created it can then be reused across the organisation time and time again helping to enforce consistent of installations across multiple applications.

Deploy

Now that we have modelled what our application should look like we can then deploy to any of the supported cloud destinations. Currently it numbers around 19 and increases with every release (the roadmap is to open this via an SDK), example are public clouds (AWS, Azure), Private Clouds (Openstack) and existing traditional data centre virtualisation (VMware, Hyper-V).

   "Model once deploy anywhere"

Manage

The management of applications covers a number of bases;

  • Location of applications (which cloud) and who deployed
  • Costs associated with running of application
  • Benchmarking performance
  • Governance and Control
  • Development Lifecycle
  • Upgrades/Stop/Start/Termination

Some example dashboards and reports are below;

Dashboard Summary; Dashboard

Deployment Overview; Deployments

Usage Details; Usage Report

It is useful to understand how your application performs from an end-user perspective in different locations and/or server sizes. You can use JMeter tests to help simulate end-users. An example below is showing an application run in Openstack and in VMware in our lab as well as various Openstack instance sizes;

CloudCenter allows you to restrict where/who/what can be deployed allowing an organisation to gain back governance, control and compliance back. This can be done without causing pain to your consumers by being transparent to them via the GUI or allowing the tool to be inserted into existing pipelines by making use of the Rest API.

Modern development cycles (Continuous Integration and Continuous Delivery) require the spinning up and down of environments quickly for running tests. You can insert CloudCenter into the development teams existing processes allowing you to get all the features and capabilities without holding the development cycles back. An example of this is using the concept of Projects and phases where you can put controls around costs and locations of deployments for different phases. It is unlikely during development you want to mirror production so you can select the best location for that phase while during Pre-Prod you will most likely be mirroring production. Each phase can have its own set of rules.

A plugin has also been created for Jenkins to make it nice and easy for developers to carry on with their existing tools and integrate with CloudCenter. Should Jenkins not currently be used the Rest API can be used to create the required integration points.

Summary

The three major benefits I tend to see with customers are;

  • Model and Deploy to many destinations. This can be very useful for organisation that develop their own application and need to spin up environments to test during development phases however want to have options around the location (Openstack might be preferred for quick test, Azure for longer running test and say AWS for production).
  • Development pipeline and the ability to integration CloudCenter into their existing pipeline. The Jenkins plugin is a great example.
  • Governance and control. It can be the wild west trying to get visibility and control of how things are deployed with a hybrid cloud strategy including what they are costing the organisation!

I should point out that many more features and capabilities exists but I wanted to give you a taste of some of the key ones. You can get more information from the CliQr website, at some stage I am sure that this will be fully migrated to cisco.com however this has not yet been complete.