Become a cloud provider in 3 months

This is the story of a company that decided to become a Cloud Service Provider.
They were already a successful IT outsourcer in the financial industry, with many customers' environments running in their data center.
Outsourcing was a healthy business but they started having some challenges, due to slow and inefficient provisioning processes and operations.
Any new request from a customer started a new project, so their customers started exploring public cloud services to get more flexibility and speed.
For this reason, the company decided to adopt the cloud delivery model and to offer their customers a self service catalog.

Of course a cloud project cannot be done in one night, so they were cautious in their approach.
Both technology and operational processes needed to be proven before embarking in such a challenge, but the traditional waterfall methodology made the expected return appear uncertain and distant.
To make things worse, they had tried to implement a PaaS project with a different vendor and they had spent a lot of money without tangible return.

I was engaged to support the evaluation of a new IaaS catalog that could evolve to PaaS and to self service applications management.
I made sure that the Business and IT strategy were in sync and I proposed to start with small steps to validate the approach. I also invited them to qualify the quick wins that they would expect to justify the investment and show the stakeholders an immediate return, so that the project lived enough to reach the expected success.
As you know well, many projects last too much and die before showing any business return.

We analyzed the current situation and defined a future vision. This was the driver for a gap analysis and for the prioritization of user stories, that we decided to implement in short iterations (sprints of 2 weeks, according to the Agile Scrum methodology).
Their data center was mainly based on Cisco networks and servers, but this was not the main reason for selecting the Cisco software stack for the cloud project.
After the initial workshops, some product demo and talks about other projects they understood that our people - and our partner company that implemented the project with them - were experienced enough to plan the project seriously and to chase the quick wins that we all considered so important.

The Cloud Management Platform chosen for the project was the Cisco ONE Enterprise Cloud Suite (aka ECS).

One of the most important features considered in the decision was the possibility to create flexible templates, later exposed as self service options in the end user catalog, for the deployment of complex applications. A set of servers with different roles, and all the networks needed to make them work, can be provisioned as a dedicated and virtually separated environment (multi tenancy in a shared infrastructure that offers economy of scale).

As an example, the following picture shows a environment that could be ordered - fully configured - with a single click. It is based on a component of the ECS architecture that is named VACS (virtual application cloud segmentation):

 

It was easy to engage the SME (subject matter experts) for the servers, the network, the storage and the virtualization in the customer organization and to ask them to define the basic policies that we would use as building blocks for all the services to be offered.
This model-based implementation is quicker to build and easier to maintain, and it can be exposed to the end users in a way that they understand and trust soon.

The automation that we built was considered useful by the SME (after winning their initial suspicion, because every good craftsman loves manual work) because it set them free from the manual operations that previously made their work tedious and error prone.
Delegating the configuration to an automated service gave their customers a faster service and a higher quality (no rework needed because of manual errors or missing information).

One more component in the architecture is the Stack Designer.
It is a tool provided by the Cisco ECS to create templates for application provisioning. It takes IaaS templates - made in the infrastructure management layer, that in our case is UCSD, to deploy a topology of servers and networks - and layers the software stack on top of them.

You can decide what software products (or custom applications) must be installed - and configured based on the input parameters provided by the end user - including monitoring agents and backup agents, and save this new template in the repository.
The integration with Puppet, an open source solution used to provision software applications, is leveraged to install and configure the entire software stack from the images in the repository.

The new template can now be offered as a self service option in the catalog, so that the end users don't need to install and configure the software stack themselves. A end-to-end solution is provided, up and running and ready to be used.
All the components of the ECS solution are pre-integrated and this makes the project faster than you would expect. But, since they communicate through standard protocols and open API, every component of the architecture could be replaced by an alternative product (from a different vendor or from the open source community). You should not be afraid of vendor lock in  :-)

Agile Delivery

In terms of project delivery, the following table shows the different iterations that allowed to complete the delivery in only 3 months.
But the amazing result is that at every sprint (i.e. every 2 weeks) new use cases were available in a usable environment.
The first demo to a real customer (a customer of my customer) was done after 2 months from the start of the project, and the first customer was onboarded after the 5th sprint (i.e. 2.5 months).

Conclusion

This quick win demonstrates that even complex projects like building a public cloud platform can be done in a reasonable amount of time.
The era of endless projects, based on complex technology and measured in function points, has passed forever.
There are simple solutions (like ECS) that make your work easier, but a good organization and the right methodology allow for incremental building and refinement of the solution. Every iteration of the project delivers a usable result in the production environment, and you don't need to wait the completion of the entire project to start using the solution.
If you are a service provider, you can start selling your services soon and produce a ROI.
More services will be added incrementally and the catalog will be richer at every iteration.

References

Cisco Enterprise Cloud Suite
and its individual components:
- Cisco PSC - Prime Service Catalog 
- Cisco UCSD - UCS Director
- Cisco VACS - Virtual Application Cloud Segmentation

Fast IT
Cisco Prime Service Catalog in action: Cisco eStore

Scrum (agile development) 

Governance in the hybrid cloud

This post shows how a company can solve one of the main issue that CIOs have today: the so called Shadow IT.

This term defines the usage of cloud services (either IaaS, PaaS, SaaS) in a project without any control, decided by the application developers or designers because they think it's beneficial for the agility of the project.

Sometimes leveraging available services is really good for a project: it's useless to rebuild something that is easily available as a standardized service. Even when the IT organization of your company (or your customer, if you're a consulting company) provides the building blocks that you need for your architecture, it could be difficult to get approvals or a fast enough provisioning.
So there are different valid reasons to incorporate public cloud services, we can't blame those that try to fully exploit a Service Oriented Architecture.

Unfortunately this way of assembling applications using any available resource you consider useful creates troubles for the IT organization.
Besides additional costs, that arrive as a surprise (developers bill to a personal credit card or to a corporate one, but sooner or later those costs will be factored into the cost of the project), some corporate rules could be violated without even being aware.
Just a few examples: storing reserved data in a database outside the company's datacenter, or invoking services without encrypting the input/output parameters, not granting the end to end High Availability or Disaster Recovery of the entire system.

The subject of costs can be easily underestimated: at development time you need very limited cloud resources, for a limited time. It costs near to zero, before the application goes to a full production environment. But after that, it will need more computing power and more storage, and of course more bandwidth, to serve all the users. Cloud services tend to increase surprisingly in these conditions.

So the CIO has a dilemma: to try to block, or limit, the usage of cloud services - limiting cost and risk but appearing like the one that slows the innovation down and prevents the lines of business from achieving their business result - or to allow maximum freedom, with the additional risk of becoming not relevant because they can bypass the IT organization?

There is a solution in the middle: IT could offer a facilitated access to cloud services, adding them to a Service Catalog where users can self serve, granting compliance by design.
Public cloud services will be selected based on agreed architectural and security policies, they will be documented, audited and reported, eventually subject to approval from a financial standpoint.

One possible implementation of such a catalog can be based on the Cisco ONE Enterprise Cloud Suite, as I did in a recent project at one of my customers.

The Cisco ECS is a reference architecture comprising one flexible Service Catalog, a automation engine and a platform for hybrid cloud that allows the extension of your datacenter into a kind of "bubble" in the public cloud. In case you need additional power, you can burst your workloads into the virtual private datacenter keeping all the security and networking policies you defined in your private cloud: even the IP address of the virtual machines does not change, as long as the secure segmentation of the application layers and any other policy.

I'm not going to describe the Cisco ECS, because you can find the official documentation here.
I'm showing how we extended the services offered in this catalog with CliQr Cloud Center for managing the provisioning and the lifecycle management for applications in the cloud. So the great capabilities of Cisco ECS in term of IaaS are complemented with the offer of the deployments of simple or complex applications and software stacks, that you can target at any cloud just selecting from a drop down list.

I mean that the template for the deployment is not cloud dependent,  and the user can - within the limits of his authorization level and the corporate policies - choose to provision it in the private cloud (e.g. on vmware in the corporate data center) or in the public cloud (e.g. AWS or Azure).
The lifecycle operations (start, stop, resume, delete, etc.) will be also offered as well as the migration to a different cloud: from private to public after the QA test is done and you're ready for production, from a public provider to a more convenient one, etc.

THIS POST HAS BEEN REDACTED

After the publication of this post Cisco announced the intent to acquire Cliqr (not because of the post :-) ), and our policies require that we don't speak of deals while they are in progress. I can't show the way we integrated Cliqr in this project because the official statement on the reference architecture will be communicated by Cisco after the acquisition is eventually completed.

References:
http://blogs.cisco.com/datacenter/introducing-cisco-one-enterprise-cloud-suite
http://www.cliqr.com/