In my previous blog post, “What kind of cloud do I need for DevOps?" I mentioned that the IBM implementation of a continuous delivery pipeline with IBM UrbanCode Deploy (UCD) is not dependant on any specific (IBM) cloud solution. Throughout the coming weeks I’ll give you some more insight into implementation examples of how to integrate cloud platforms into UCD.
Today I’ll start the journey by explaining the integration between UCD and IBM SmartCloud Orchestrator (SCO), which is a private cloud solution for providing infrastructure as a service (IaaS) or platform as a service (PaaS) based cloud services. SCO is based on the concept of a pattern (there are other IBM cloud solutions beside SCO that also embed the concept of cloud patterns) to describe and request a cloud service. A pattern is like a “codified reference architecture” that you have defined in your enterprise and that you want to be able to reproduce as often as needed—for example, within the walk-through of a continuous delivery pipeline.
The screenshot to the right is an example of a pattern representing a multi-node topology of a WebSphere environment. Multiple nodes and node types like web servers, application servers and database nodes are assembled into a platform that you can deploy your application into once it is provisioned. The pattern-based cloud service represents everything from an infrastructure-perspective that is required for the developer to deploy and test the “new build” inside the continuous delivery pipeline. DevOps is often talking about the concept of “infrastructure as code,” and the cloud pattern is exactly this, a description of the infrastructure.
So how is this pattern concept used within UCD with respect to a full stack release approach?
Let me explain the cloud pattern integration based on the object model inside UCD that brings together all the required information of the application and infrastructure world. UCD is providing the concept of an application blueprint, which is a template to deploy an environment. So if you as a developer or tester request an integration stage with your latest build of the application, you can do so based on an application blueprint.
An application blueprint inside the UCD object model integrates various entities of application and infrastructure-related elements into a unified description of a full stack release model. The diagram to the right highlights the most relevant ones.
Let me explain this in some more detail:
- An application (for example, a claims application) is a logical container representing a number of deployable and separated components. A WAR file to be deployed on a web server or servlet engine, an EAR file to be deployed into an application server or a DDL file to be deployed into a database (DB) system are typical examples.
- The application usually is deployed throughout various environments before it gets deployed into the production environment. So there is an association between the application and defined environments.
- The infrastrcucture or platform requirements are described within the concept of a resource template. A resource template is a collection of resources that need to be provisioned if an environment is requested based on the defined application blueprint. Examples are web servers, application servers or DB sytems. In the diagram above this is summarized as “other resources.”
- In addition, each system in the collection requires having a UCD agent installed in order to receive application deployment requests once the infrastructure has been provisioned. This is represented in the model as an agent prototype. An agent prototype represents an agent that is not yet (but during provisioning will be) installed.
- A resource template as a whole can be automatically generated based on the import of a cloud pattern, for example by importing it from SCO.
- In order to know which application components have to be deployed into which infrastructure nodes, there is a mapping of components to the resources inside the resource template.
This screenshot reflects an example of mapping the deployable components of the “ClaimSystemApp” application onto infrastructure nodes that have been imported through an SCO cloud system.
You would now be ready to create an environment stage in the cloud based on this application blueprint.
A full stack deployment in the cloud when you need it in less than 30 minutes—doesn’t that sound of interest to you? Let me know if you’d like to hear more details about what I described today.
IBM Executive IT Architect, Cloud Architecture