Infrastructure as Code with Terraform and Cisco Metapod

Recently I worked with a customer to explore the concept of Infrastructure as Code.

They like open source solutions for the automation of the infrastructure and for managing the software applications life cycle.

To reach the first objective their goal is a private cloud based on Openstack, while they will use Ansible and Terraform to manage the environments for different projects.

Managing the Infrastructure as Code means that the definition of the infrastructure is maintained in text files, that could be stored in a version control system like you do with the source code of the application.

If you do that, the same lifecycle applies to both the infrastructure and the application: creation of staging or production environments, automated testing, etc.

Using blueprints helps to improve the quality of the final result of the project and grants compliance with policies and eventual legal obligations.

Benefits include speed, cost savings (avoiding a static allocation of pre-provisioned resources) and risk reduction (removing errors and security violations).

Terraform is one of the best open source tools to manage your Infrastructure as Code: it’s easy to install, learn and use (one hour).

You could start from tutorials and free examples available on Internet.

Here is an example of full automation (we'll try to get a little better result):

As a first step, to make the usage of Openstack easier on a large scale, we discussed the value of a managed service.

If the IT organization could just focus their effort on the development and operations of the business applications, instead of running the infrastructure, they would create more value for the internal customers (company's lines of business).

So I proposed the adoption of Cisco Metapod, that is Openstack as a managed service (delegation of all the tough administrative and operational work to a specialized 3rd party, while you just use the Openstack user interface and API enjoying a SLA of 99.99% uptime). 

I have described the advantage of adopting Openstack as a managed service in this post: Why don't you try Openstack (without getting your hands dirty)? 

Services offered by Cisco Metapod

We created a lab where Openstack abstracts the resources from the physical and virtual infrastructure (etherogeneous servers, network and storage) and the configuration of different environments is managed by Terraform, so that you can create, destroy, restore and update a complex system in few minutes.

With Terraform you can describe the architecture in a declarative form (in a manifest file).

You simply describe what you need (the desired state), not how the different components (devices and software) must be configured with all their parameters and their specific syntax.

The goal of Terraform is to match the current state of the system with the desired state.

Desired State vs Current State

Terraform is used to create, manage, and manipulate infrastructure resources. Examples of resources include physical machines, VMs, network switches, containers, etc. Almost any infrastructure noun can be represented as a resource in Terraform. Terraform is agnostic to the underlying platforms by supporting providers. A provider is responsible for understanding API interactions and exposing resources. Providers generally are an IaaS (e.g. AWS, GCP, Microsoft Azure, OpenStack), PaaS (e.g. Heroku), or SaaS services (e.g. Atlas, DNSimple, CloudFlare). 

Infrastructure as Code

Desired State

In my lab I reused a good example that I found on GitHub at https://github.com/berendt/terraform-configurations 

It contains all the resources you need to deploy a new Devstack instance (a all-in-one instance of Openstack, useful for developers) including the needed networks, public addresses, firewall rules on a target cloud platform. That, incidentally, is a Openstack instance (so we are deploying Openstack on Openstack).

Here is the content of the main.tf file used by Terraform: it references variables with the format ${variable_name}, including the output from actions on other resources. Dependencies between resources are managed automatically by Terraform. A separate file can contain the predefined values for your variables (like the references to the Openstack lab in my example).

If you are not interested in the content of this file (I guess it applies to 70% of my readers) you can skip it and go to next picture... there is also a good recorded demo down there   :-)

 

main.tf (the manifest file where Terraform ready the desired state of all the resources):

provider "openstack" {

  user_name  = "${var.user_name}"

  tenant_name = "${var.tenant_name}"

  password  = "${var.password}"

  auth_url  = "${var.auth_url}"

}

resource "openstack_networking_network_v2" "terraform" {

  name = "terraform"

  region = "${var.region}"

  admin_state_up = "true"

}

resource "openstack_compute_keypair_v2" "terraform" {

  name = "SSH keypair for Terraform instances"

  region = "${var.region}"

  public_key = "${file("${var.ssh_key_file}.pub")}"

}

resource "openstack_networking_subnet_v2" "terraform" {

  name = "terraform"

  region = "${var.region}"

  network_id = "${openstack_networking_network_v2.terraform.id}"

  cidr = "192.168.50.0/24"

  ip_version = 4

  enable_dhcp = "true"

  dns_nameservers = ["208.67.222.222","208.67.220.220"]

}

resource "openstack_networking_router_v2" "terraform" {

  name = "terraform"

  region = "${var.region}"

  admin_state_up = "true"

  external_gateway = "${var.external_gateway}"

}

resource "openstack_networking_router_interface_v2" "terraform" {

  region = "${var.region}"

  router_id = "${openstack_networking_router_v2.terraform.id}"

  subnet_id = "${openstack_networking_subnet_v2.terraform.id}"

}

resource "openstack_compute_secgroup_v2" "terraform" {

  name = "terraform"

  region = "${var.region}"

  description = "Security group for the Terraform instances"

  rule {

    from_port = 1

    to_port = 65535

    ip_protocol = "tcp"

    cidr = "0.0.0.0/0"

  }

  rule {

    from_port = 1

    to_port = 65535

    ip_protocol = "udp"

    cidr = "0.0.0.0/0"

  }

  rule {

    ip_protocol = "icmp"

    from_port = "-1"

    to_port = "-1"

    cidr = "0.0.0.0/0"

  }

}

resource "openstack_compute_instance_v2" "terraform" {

  name = "terraform"

  region = "${var.region}"

  image_name = "${var.image}"

  flavor_name = "${var.flavor}"

  key_pair = "${openstack_compute_keypair_v2.terraform.name}"

  security_groups = [ "${openstack_compute_secgroup_v2.terraform.name}" ]

  floating_ip = "184.94.252.189"

  network {

    uuid = "${openstack_networking_network_v2.terraform.id}"

  }

  provisioner "remote-exec" {

    script = "deploy.sh"

    connection {

      user = "${var.ssh_user_name}"

      key_file = "${var.ssh_key_file}"

    }

  }

}

To make it simple, for this blog post I replaced the part that deploys Devstack with a simpler setup of a web server (Apache).

deploy.sh (Terraform will copy and execute it on the remote instance as soon as it is created):

#!/bin/bash

# author: Joe Topjian (@jtopjian)

# source: https://gist.github.com/jtopjian/4ffc82bfcbbcc78d07e4

sudo apt-get update

sudo apt-get install -y -f apache2

The goal is to demonstrate how easy it is to create a new software environment on a Cisco Metapod Openstack target from scratch and run it. 

The following pictures show the Metapod console before and after running the "terraform apply” command on my computer.

This is before I run the command:

The Openstack console from Cisco Metapod

And this is the expected result (network and server infrastructure created, apache installed):

Resources created in Openstack

Next video (the most important part of this post) is a recorded demonstration of the creation of the new Apache server: you can see the launch of the “terraform apply” command that, after reading the manifest file, creates a network, a subnet, a router with two interfaces, a floating ip and a instance on Openstack. Then the Apache web server is downloaded and installed in the new instance.

The Metapod console is left in the background and you see the Openstack objects pop up as they are created.

Finally the home page of the new web server is tested.

 

 

Conclusion

It is very easy to get rid of the delays, the misunderstandings and the inefficiency of many current IT organizations.

If you standardize the process that developers follow to obtain the environment for a new project - in all the phases of the life cycle - you can enable a faster go to market for new business initiatives making your customers happy.

It would be a first step towards DevOps (more is required, mostly in changing the culture of both developers and people in operations).

Infrastructure as code is a brilliant way to create the needed infrastructure on demand (and release it when no longer needed), to maintain it based on blueprints and manage the definition of the infrastructure with the same tools you use for the application source code: a text editor (or your preferred IDE), a version control system, an automation tool.

If you have a IaaS platform like Openstack, provisioning of both virtual and physical resources is made easy.

If you do a further step forward with a managed service, someone will grant that your Openstack is correctly configured for production, up to date and in perfect health. You enjoy all the benefits, without the hassle of setting it up and operating it daily.

References:

Using Terraform With OpenStack - https://www.openstack.org/summit/tokyo-2015/videos/presentation/using-terraform-with-openstack

Configuration to run acceptance tests for Terraform/OpenStack - https://github.com/berendt/terraform-configurations

Tutorial: How to Use Terraform to Deploy OpenStack Workloads - http://www.stratoscale.com/blog/openstack/tutorial-how-to-use-terraform-to-deploy-openstack-workloads/

Cisco Metapod - http://www.cisco.com/c/en/us/products/cloud-systems-management/metapod/index.html

Why don't you try Openstack (without getting your hands dirty)? - http://lucarelandini.blogspot.it/2016/06/why-dont-you-try-openstack.html

Why DevOps: definition and business benefit - http://lucarelandini.blogspot.it/2015/01/why-devops-definition-and-business.html

Infrastructure as Code - https://en.wikipedia.org/wiki/Infrastructure_as_Code

Is Agile dead (already)?

I've been pushing Agile development for long time, as opposed to traditional methodologies like waterfall... or to no methodology.

I no longer deliver IT projects myself, but I help customers and partners to plan and deliver theirs.

The most important goal I set is achieving quick wins, like I described in become-cloud-provider-in-3-months.

A quick win encourages all the stakeholders (the project team, their clients, the lines of business that provide the budget, everybody up to the CEO).

Not only it demonstrates that the solution works, but it is a concrete measurement of the return on the investment.

Generally projects are not done because they are smart, but because they are supposed to generate a financial gain (more revenues or lower expenses). Even when the goal is described as a faster go to market, the ultimate target is generating more revenues.

Agile development is not the only way to achieve a quick win, but it helps.

It also helps in reducing the project risk because, if you have to fail, you fail soon (and save a useless effort).

So, when a colleague sent me this article to solicit my comment, I almost felt insulted by the author... though I'm pretty sure he was not referring to me  :-)

A note on the author: 

Matthew Kern has a long experience in the field, so he knows what he's talking about.

He’s been writing many posts since 2015 to explain that Agile is dead.

Definitely he knows the Agile methodology and its usage, so he deserves respect.

More, he published a followup of that post offering the correct interpretation: probably he received too many protests.

Nevertheless my first impression was negative, because he was criticizing my fundamental believes.

But reading it carefully I understood that he's not wrong. He criticizes the evolution of the Agile methodology and the usage that someone made of it as a marketing tool, also in the light of newest trends like DevOps.

In my opinion, some overstatements in the article - starting with the title - are a mean to get visibility.

Indeed, in the conclusion he explains what he really means (and I partially agree): he refers to the “Agile” brand, to politics and to commercial usage (literature, consulting, marketing...).

When he says that agile don't work for large enterprises, I would distinguish between vendors of software products and customers doing it for their own project. 

The lifecycle of a software applications is completely different in these two scenarios, and so are the business requirements, the expected quality of the product, the variety of users, the frequency of the updates and bug fixes. 

When he says that many projects fail, he highlights a fact that is common to all methodologies.

But, at least, with Agile you fail soon (that is one of the objectives: better to fail in one month than after 1-2 years of unproductive activities eating your time and money).

So, if we focus on the hype, on brands and marketing activity, Agile is being replaced by DevOps (that can be considered its evolution, taking care also of the Operations with continuous delivery and feedback) and later even DevOps will be replaced by next hype.

But they both produce a value for developers and for the IT: you can see it in the cultural shift and in the individual interpretation of the principles, rather than in  coded best practices. As an example, I’ve seen that my colleagues in Cisco Advanced Services started using Agile with visible benefits for both themselves (less bureaucracy) and customers (better and faster projects).

In conclusion, definitions are important and they help to spread the knowledge.

But theory is important for professors only, while a good practice makes developers and project managers happy.

If they adopt the principles of Agile, they work - even using Scrum informally - implementing those guidelines and produce good results, would you stop them?

It’s better to be Agile than not... 

References

http://www.agilemanifesto.org/

https://www.linkedin.com/pulse/agile-dead-matthew-kern

https://en.wikipedia.org/wiki/Agile_software_development

http://agilemethodology.org/

http://lucarelandini.blogspot.it/2016/02/become-cloud-provider-in-3-months.html

Why don't you try Openstack (without getting your hands dirty)?

Is Openstack ready?

But, more important: are you ready for Openstack? 

 

Openstack is mature (but complex).

Surveys and statistics show that Openstack is mature and provides a number of benefit to a broad spectrum of users, from small to large enterprises and service providers.  

Almost every professional in the IT (including CIOs and CTOs) knows the advantage that Openstack would offer to his organization.

But many are also aware of the complexity of the technology, the need for new operational processes and skills to set up and operate Openstack.

A scalable and reliable production environment is different from a lab where you explore the capabilities of the new platform.

The journey to a mature adoption of Openstack is not easy and you need to invest time and money.

In addition, when you hire people (or train yours), there is a possibility that another company steals them with the offer of a better salary, given the scarcity on the market.

So, many IT organizations - excluding cloud service providers, because that’s exactly their business - started wondering if it’s worth spending time in running the infrastructure, rather than running their business applications.

If you are not a cloud provider, that makes money selling IaaS, why should you dedicate additional effort to installation, monitoring, troubleshooting and release upgrades to ensure reliability and performances to your applications (that’s the only asset you should care of, because your business relies on them)?

Focus on your real business.

Why don’t you delegate all the responsibility to a provider, signing a contract that puts the above tasks and SLA on them?

Doing so, you would be free to use Openstack, getting all the benefit that you expect from it, without the burden of the learning curve and the organization implied by the Openstack adoption.

You would focus on using the infrastructure to develop and run your applications, no longer on running the infrastructure itself.

That is called a managed service.

You own the infrastructure and exploit the value of your Data Center assets (you don’t just drop them to escape to a public cloud).

An expert team (it’s just their business) installs Openstack in your DC and operates it everyday in a HA (high availability) configuration, granting 99.99% uptime.

They take care of all the version upgrades and the compatibility of all the new features released by the community by using a certified configuration.

The user interface (the Horizon console, the Openstack API and command line interface) is available to you so you can deploy virtual server instances, networks, storage at will. You get complete and granular reporting on the health of the system and its performances.

You are the owner, but you don't get your hands dirty with the complex stuff   :-)

You pay them for the service, they grant you the SLA.

Just taste if you like Openstack.

The approach described above can be a strategical decision, because you want to focus on your business applications.

But you could also use this trick to stand up a Openstack environment in very short time, test it (I mean if your organization adapts to it, if your applications run well, if the operational model - IaaS at home, on your infrastructure, no cloud provider lock in - is good for you, if your developers are more productive) for a while, e.g. 3 or 6 months, and finally decide if you want to adopt it. 

At that time you can choose between continuing with the managed service or doing it yourself.

It is a zero risk trial of the technology and of the processes: if you don’t like, you haven’t wasted any time and effort to stand it up so you can happily retreat.

You simply do not renew the service contract and that’s all: you have made a real informed decision about the adoption of Openstack.

Cisco Metapod: Openstack as a managed service.

Cisco has a offer that allows you to do what I described above, that comes from the acquisition of a company whose business was exactly Openstack as a managed service, on your premises.

They had a Openstack distribution of their own, optimized and hardened to provide a smooth and effective service.

Now, thanks to a strong partnership with Red Hat, the team is using the Red Hat Enterprise Linux Openstack distribution (OSP8, based on Liberty).

The essential features of this service are:

- easy start: entry level contract for 90 days

- ready to go live in 2-3 weeks from the engagement

- HA included

- the infrastructure to run Openstack can either be yours or provided by Cisco

- both the Openstack API and the AWS API are exposed by the system

And the infrastructure to run it in production can be as simple as this:

The value you can get from it: a well defined SLA, installation included, maintenance and upgrade included, no cloud provider lock in.

I believe that Cisco Metapod is a very good option to start with Openstack.

You can put your foot in the water to test the temperature, then decide to take a bath if you like it.

References

Openstack users survey 

Cisco Metapod official page

Cisco and Openstack on this blog 

A simpler framework for hybrid cloud

Hybrid cloud is one of top mind projects for most IT managers, and there's little content that one can add to be original   ;-)

The hype and the attempt of many vendors (including... Cisco) to provide relevant solutions have populated the space of an incredible number of offers that make it hard to distinguish what works, what's manageable and cost effective, from what is only marketecture.

Recently Cisco decided to invest even more on cloud and, with the advent of a new CTO and some acquisitions, a revision of our approach to hybrid cloud made it easier and more effective. This post is not from official marketing and is not echoing company's direction: it's my attempt to rationalize my understanding of the new framework and to solicit your comments and feedback, so that I can leverage it when I discuss with my customers and partners.
The following picture represents the area where Cisco plays a role, offering hardware and software solutions.
When it comes to the software stack to manage the infrastructure and provide services to the users, we have a mix of Cisco products, open source solutions and integration with 3rd parties. The objective is to offer a set of pre-validated stacks that can match the different needs, granting a deterministic result.

I shared some thoughts with a group of colleagues because we're planning educational activities for our field people: instead of just providing a reference architecture (that would end being a list of products to be forced in every deal) we tried to represent the functions in the system as components of a framework, from which we'll pull the specific architecture for a given project. This, used cum grano salis, should help to be pragmatic and realize quick wins (for both the customers - think of Fast IT initiatives - and of course for Cisco).

As a result, next picture is separating the different functional layers so that they can be explained to sales guys and to customers.
It could also help to manage the possible overlap with alternative solutions that customers may choose – or already have – because every element is replaceable in the picture, based on the open API they expose/consume (as well as any well designed 3rd party product).

It is important to note that the top two layers in the picture are optional, since not all customers need those functions in their system. Based on the level of Governance that they want to have, the existing processes and the way they develop business applications (or use commercial software that only need a resource pool to be deployed), the entry point could be directly at the third layer (Multi-Cloud Management) and ITSM and PaaS would be removed.

So, while we explain all the possibilities as said above, we need to make them feel confident that it’s doable and not overly complex.
In that regard, my motto is that “cloud is not a product (or a set of), it’s a project and it’s complex in nature… regardless the products set you choose”. Generally the cost of hardware and software products is lower than development and consulting services, and customers know it.
If we can claim that a pre-built integration makes the project easier (and we can), I would stress the value of reducing the project risk and delivering outcomes faster rather than a cheaper implementation.

Selling licenses can be (almost) easy, but driving adoption with business outcomes for customers is different. Finally Cisco has built a practice that can deliver IT projects effectively and recruited partners that do the same: customers have different options to choose from.

Now, in the context of a end to end strategy defined with the customer, we can deliver projects based on agile methodologies (e.g. Scrum) and implement the architecture layers with a bottom up approach: from a strong capability to automate the Data Center (and the hybrid cloud) you can create services that are surfaced up to the consumption layers, including a self service catalog.

Software Defined What?

The bottom up approach stresses the value of the API exposed by UCS and ACI (with the further evolution from basic programmability to policy-based management, that I'm not mentioning yet - look out for next post). With the power and the granularity of those API, you can really realize a fully Software Defined Data Center (SDDC): servers and networks can be shaped via software interfaces.
By the way, I take the opportunity here to clarify that Software Defined Data Center does not mean Software Implemented Data Center: you don't necessarily need a software overlay that mimics the behavior of the hardware (living as a separate entity), you need software controllers that drive the shape and the behavior of both physical and virtual resources in the DC as a single system.
Better if they do that based on policies... like the Cisco architecture does  :-)
You will see a post dedicated to policies and application intent soon on this blog.

Competition?

We also recognize that many customers have already an ITSM solution in place, or any other form of governance. So we don't engage in competitive fights, like imposing Cisco Prime Service Catalog vs Service Now, but we rather integrate our solution with the existing components: this is a sort of compromise with a competitor that hurts my pride, but since it's for our customers' benefit... it's a good solution.

Cisco Cloud Center as a broker: the recent acquisition of Cliqr brings a great solution to Cisco to address the multi-cloud management use cases, the most important ones for the majority of customers. In the logical schema above you can see that the hybrid cloud scenario has been qualified better as Multi-Cloud management.
This reflects the fact that having a application deployed partly in your Data Center and partly in the public cloud is still a relevant use case, but many companies are more attracted by other scenarios... like moving from one project stage to next (e.g. Dev-Test-QA-Prod) using different resource pools (on premise or in cloud), or moving their assets from one cloud provider to a different one.

Cloud Brokering and Multi Cloud Management

In the first one (promotion to next stage) it could be useful to leverage resources that are allocated based on business convenience (e.g. cost or flexibility) or compliance (e.g. data sovereignty), so the application and all the needed infrastructure are moved back and forth to the public cloud.
In the second the driver could be a dual provider strategy, or maybe a change in the market conditions that makes one provider more appealing than the current one, or a strategic switch from private cloud to public (or vice versa).


In all these cases, we offer a solution to deploy a software stack (a complete custom application, a development platform, or a commercial software product) as a self service option, where the target can be selected dynamically from a list of available clouds.
You can deploy to your local private cloud, based on vmware or any other virtualization solution, or to a Openstack based cloud, or to any of the public cloud providers if you have an account there.
Any resource pool is a possible destination for the deployment (and the life cycle management, including autoscale or retirement of the application).
The model of the deployment of the application is completely de-coupled from the selection of the target, thanks to the capabilities of the orchestrator that can configure the needed resources in almost any cloud transparently.
It uses the API exposed by the element managers of a multi vendor infrastructure on premise (e.g. vcenter, UCS Manager, the ACI controller, etc.) and those exposed by public clouds like AWS, Azure, etc.

From a logical schema to a real deployment

So we can offer users a different entry point, based on their business needs (they might need a ticketing system, or a self service catalog, a PaaS solution or directly the web portal of the multi cloud manager to model deployments and deliver them).
The customer can have one or more resource pools, allocated wherever he likes (local or in cloud), and let the broker direct the selection of the target based on predefined policies.

The schema in next picture presents different products at every layer: a solution can be based on one of them, or a combination. We have the flexibility to match the specific needs with products from Cisco, from 3rd party vendors or open source.
As an example, MANTL is a new open source project that makes the development of microservices easier if you build cloud native applications.

I will expand the detail of the single products and the open source solutions shown in this picture in my next post.
Stay tuned...

References

http://www.cisco.com/c/en/us/solutions/executive-perspectives/fast_it.html
http://www.cisco.com/web/solutions/trends/futureofit/why-cisco.html
http://MANTL.io
http://Github.com/CiscoCloud/microservices-infrastucture 
http://lucarelandini.blogspot.it/2015/10/devops-docker-and-cisco-aci-part-1.html
http://lucarelandini.blogspot.it/2015/03/aci-for-dummies.html
http://lucarelandini.blogspot.it/2015/09/the-phoenix-project-how-devops-can.html

How to create a service end to end in Cisco ONE ECS

Training and real world usage of the products

Sometimes training is more focused on the procedural detail of the individual components than on the real world usage of a system.
You might miss the understanding of the end-to-end architecture and the use cases that you could address with that solution so you go home, at the end of the training, without a complete awareness.

In the case of the Cisco ONE Enterprise Cloud Suite, that is composed of a number of components, in a course for beginners you will learn how to use Prime Service Catalog, UCS Director, Intercloud Fabric Director and VACS.
But, after you know how to configure them and what's the value provided by every tool, you might still wonder "what I'm going to do with this architecture?" or "how complex would it be to implement a complete project?".

I put this sample use case together to show what is the process to create a brand new service in the self service catalog, complete with all the implementation of the delivery of the service. My colleague Maxim Khavankin helped me to document all the steps.
If you download PSC and UCSD and run them with the evaluation license, you could run through this exercise very easily and make friends with the platform.

Hello World with Cisco ECS

I implemented a very simple service, just to have a context to show the implementation.
No business logic is involved, or integration with back end systems, to keep you focused on the mechanics: you can easily extend this framework to your real use case.

The idea is to order a service in PSC, providing a input, and let UCSD deliver the outcome.
In our case the expected result is writing a "Hello <your name>" message in the log file.

Generally workflows in UCSD make use of tasks from the library (you have more than 2000 tasks to automate servers, network, storage and virtualization). But a specific use case might require a task that is not available already, so you build it and add it to the library.

I created a custom task in UCSD just to write to the log: of course, you could replace this extremely exciting logic with a call to the REST API - or any other API - of the system you want to target: infrastructure managers in your data center, enterprise software systems, your partner's API for a B2B service, etc. 

 

Then I created a custom workflow in UCSD, that takes your name as a input and makes use of the task I mentioned to deliver the "Hello World" service. The workflow can be executed in UCSD (e.g. for unit testing) or invoked via the UCSD API.

Prime Service Catalog has a wizard that explores the API exposed by UCSD, discovers and imports all the entities it finds (including workflows) so that you can immediately offer them as services in the catalog for end users. Of course a customization can be added with the tools provided by PSC.

So the end to end procedure to create a business services is described by the following steps:

1. Create a custom task (if required)
2. Define a workflow that uses the custom task -> define input variables
3. Create a catalog item in UCSD -> offer the workflow from step 2
4. Synchronize PSC and UCSD
5. Use the wizard to import the service in PSC
6. Customize the service in the PSC catalog with Service Designer (optional)
7. Order the customized service
8. Check the order status on PSC side
9. Check the order status and outcome in UCSD

I illustrate every step with some pictures:

Create a custom task (if required)    

Custom tasks can be added to the existing library where 2000+ tasks are offered to manage servers, network, storage and virtualization.

You can group tasks in Categories so that they can be found easily in the workflow editor later. 

 

Custom tasks can have (optional) input and output parameters, that you define based on variable types: in this case I used a generic text variable to contain the name to send greetings to:

The format, contraints and presentation style can be defined:

You can skip the steps "Custom Task Outputs" and "Controller" in the wizard to create the task: we don't need them in this use case.

Finally we create the logic for our use case: a small piece of Javascript code that executes the custom action we want to add to the automation library.

The UCSD logger object has a method to write an Information/Warning/Error message to the UCSD log file. As I wrote earlier, you could use http calls here to invoke REST API if this was a real world use case.

After you've created your custom task it's available in the automation library.
Now you have to define a workflow that uses the custom task: to pass the input that the task requires, you will define a input variable in the workflow.

The workflow is an entity that contains a number of tasks. The workflow itself has its own input and output parameters, that can be used by the individual tasks.

Input and output parameters of the workflow are defined in the same way as tasks' input and output.

They can be useful if you launch the workflow via the REST API exposed by UCSD.

Now that you've created the workflow, it's time to add some tasks to it picking from the library (exposed in the left panel of the workflow editor).
We'll only add one task (the custom task that we created): select it from the library, eventually searching for the word "hello".
Drag and drop the task in the editor canvas, then configure it.

You will see a screen similar to this one:

 Configure the new task giving it a name:

Map the input variable of the task to the input parameter of the workflow that you created:

If you had not a variable holding the value for this task's input, you could still hard code the input value here (but it's not our case: this form would appear different if you hadn't mapped the variable in the previous screen).

 

The task does not produce any output value, so there's no option to map it to the output parameters of the workflow.

Finally we see the complete workflow (one single task, in our example) and we can validate it: it's a formal check that all the tasks are connected and all the variables assigned.

 

Then we can execute it from the same window, to check that it behaves correctly. You will have access to the log file from the same window that pops up when you execute the workflow, so you can see that the greetings appear in the log.

Next action is to expose this workflow to users in UCSD (in the GUI and via the API).

Create catalog item in UCSD -> offer workflow from Step 2   

UCSD catalog items are offered to non-admin users if you so choose. They are grouped in folders in the user interface, and you can make them visible to specific users or groups.

You can give them a name and a description and associate a service, that could be the provisioning of a resource or a custom workflow - like in our case.

The workflow is selected and associated here: 

After defining the new catalog item, you'll see it here - and in the end-user web GUI.

If the service is offered to technical users (e.g. the IT operations team), your work could be considered complete.
They can access UCSD and launch the workflow. The essential user interface of the tool is good enough for technical users that only need efficiency.

But if you're building a private cloud you might want to offer your end users a more sophisticated user interface and a complete self service catalog populated with any kind of services, where you apply the governance rules for your business.

So we'll go on and expose the "Hello World" service in Cisco Prime Service Catalog.

Synchronize PSC and UCSD   

Login to PSC as admin, go to Administration -> Manage Connections.
Click on the connection to UCSD (previously defined by giving it the target ip address and credentials) and click "Connect & Import".

PSC will discover all the assets offered by UCSD.
Now you can use the wizard to import the "Hello World" service in PSC. With few clicks it will be exposed in the service catalog.  

The wizard allows you to associate an image and a description with the service. Here you can describe it at the level of detail and abstraction that are more appropriate for your users (or customers).
You have a full graphic editor that does not require any skills as a web designer.

 

Additional metadata (attributes of the service) can be added, so that users can find it when searching the catalog: there is a search engine that PSC provides out of the box.

And finally you decide who can see and order the service in the catalog: you can map it to single users, groups, roles, organizations or just offer it to everyone.

 

At this time the service is fully working in the self service catalog and his lifecycle is managed. But, if you like, you can still apply customization and leverage the power of PSC. 

Customize the service in the PSC catalog with Service Designer (optional)   

There a subsystem in PSC, accessible only to specific user roles, that is called "Service Designer". It can be used to build services from scratch or to edit existing services, like the one that the wizard generated for us. Just go there and select the "Hello World" service.

The user interface of the service is built on reusable elements, that are called Active Forms (one active form could be reused in many services). The wizard generated a Active Form for our service, with a name corresponding to it.

 

If you select the active form and go to the panel "Display Properties" you can change the appearance and the behavior of the order form.

 

As an example the only input field, named "person", can be transformed into a drop down list with pre-populated items. Items could even be obtained from a database query or from a call to a web service, so that the list is dynamically populated.

 

The power of the Service Designer offers many more customization options, but here we want to stay on the easiest side so we'll stop here   :-)

Order the customized service   

Go to the home page of the Service Catalog. Browse the categories (did you create a custom category or just put the Hello World service in one of the existing categories?). You can also search for it using the search function, accessed via the magnifier glass icon.

In this picture you also see a review made by one of the users of the catalog that has already used the service. You can add your own after you've ordered it at least once.

You will be asked to provide the required input:

 

When you submit a request, your order is tracked in My Stuff -> Open Orders.

This is also used for audit activities.

Check order status on PSC side  

You will see the progress of the delivery process for your order: in general it has different phases including, if needed, the approval by specific users.

Check order status and outcome in UCSD     

If you go back to the admin view in UCSD (Organizations -> Service Requests) you will see that a new service request has been generated: double click on it to see the status.

if you click on the Log tab you can check the result of the execution of the service: the hello message has been delivered!

Now that you appreciated how easy is to build new services with PSC+UCSD you're ready to use all the features provided by the products and the pre-built integration that makes it very quick.

All your data center infrastructure is managed by UCSD, so that you can automate provisioning and configuration of servers, network and storage (of course, from any vendor and both physical and virtual). Once you've the automation done, offering services in the self service catalog takes just few minutes.

References

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