The promise of self-serve environments is closer than ever, and by combining UrbanCode Deploy and SmartCloud Orchestrator, you can pretty much achieve utopia. So let’s examine the integration.
The job of SmartCloud Orchestrator is to build virtual patterns that are used to spawn virtual systems. The beauty of this solution is that these patterns can represent the established deployment platforms for various technologies. For example, you can build a pattern that represents the standard web application topology for a given enterprise. This makes it easy for application teams to understand what they will be provided and what they must target for their applications. It also makes the self-serve environment story achievable. I simply spin up a pattern and I have an environment ready to go.
But let’s examine in a bit more detail the application stack and the responsibilities of the cloud solution and the application deployment solution. The job of the cloud solution is to utilize its virtualization environments to create nodes with specified storage, memory, and processors, install the OS on top of the raw node, and also install the various middleware solutions that are necessary. The interesting part is the middleware configuration. It is my contention that the cloud solution should provide a configured middleware solution ready to accept an application. That means that, using a WebSphere example, that WAS is installed on all of the nodes, the necessary profiles are created, the node agents are installed across all nodes and connected back to the deployment manager, and clusters are created (if necessary). This is the value of the orchestration part of SCO. The WAS configuration can do nothing in this state but it is ready to accept an application. It is now UrbanCode Deploy’s job to install and configure the application onto the resulting virtual system.
There are a few things to keep in mind when creating virtual system patterns. Work with your pattern architect to insure that these items are accomplished. First, you need to have the agent installed onto each node. Included in the UrbanCode Deploy plugins zip file is an agent package that can be added to SCO and then added to each node in your pattern. The agent name will be specified later, but the UrbanCode Deploy server and port need to be hard coded into the pattern. Also, insure that the agent installation is done as close to the end of the node stack as possible. Once the agent is installed and running and comes online in the UrbanCode Deploy server, you can then assume your node is ready to go. Finally, work with your pattern architect and insure he/she understands the details that are important to you. For example, you may need to know the installation location of your middleware solution. That location is important to the installation process and it should be made known to the pattern engineer that it can’t be changed without some notification.
So now let’s assume our pattern is ready to go and meets our needs. We can now integration UrbanCode Deploy with SCO to quickly and easily create environments. Step one with UrbanCode Deploy is to make a connection to our cloud provider. This is easily done via the Resources tab in UrbanCode Deploy. Get the credentials from your cloud administrator. You need a user with permissions to view and instantiate virtual system patterns.
Once you have your cloud connection, you can then create a resource template. Resource templates is the integration point between SCO and UCD. A resource template represents the virtual system pattern in UrbanCode Deploy. The resource template is where you spend your time thinking about how this pattern will be used by applications in UrbanCode Deploy. Creating the initial resource template from SCO is easy. In the resource template page you have the option to import a resource template from the cloud. Using your existing cloud connection you can interrogate SCO for its list of virtual system patterns. Pick the one you are interested in. Once completed, you get a simple template with each node of the template represented by an agent prototype.
Notice the agent prototype names in the resulting template below. These names may mean something to a pattern engineer, but don’t mean much to an application architect. This is another area that you can work with your pattern engineer to provide meaningful node names.
Now is when you need to think about your deployment processes that will use this pattern and flesh out the template to that it is usable by applications. The first step will be to better organize your template. Application teams will need to map their application components to the resource template via an application blueprint. Therefore, make it easy on them and create folders that hold the agent prototypes. These folders will serve two purposes. The first being that it will help categorize the nodes and make it clear the purpose of each node. In our example above there are two nodes that look exactly alike, but actually one has a middleware solution installed on it and the other has a database installed. There is no way to tell via their names. Use folders as a way to organize your template, something like this.
I also added a top level folder in my example here. I should have named it something better, but when an environment is created from this template, it will become the top level folder in your resource tree. Name it something valuable.
The other reason for adding a folder structure to your resource template is to be able to include properties as part of your template. This is where you can make your template valuable to applications. Remember that this single template can be used by many applications. After all, a standard topology should be the default used by all applications of a particular technology type. Put your deployment process designer hat on and think of the properties that will be needed by a deployment process. For example, you may want to expose an install location for a middleware solution. Maybe a URL for the deployment manager of Tomcat, for example. Maybe a port number needs to be exposed. Put those properties for each node in the folder that holds the agent prototype. The resource properties are then readily available to any component process that utilizes this template.
Also at the top level folder (Top in my example), I typically chose to include properties that identify the agent prototype names for all nodes involved in the pattern. It is typical in a multi-node situation where you will need the IP address of the database node, for example, as part of the deployment process to the app server node. By having the agent name readily available as a property, you can easily interrogate the agent properties in a single step to find its IP address property.
In the next installment of this series, we will map an application to this resource template using an application blueprint. Happy deploying!!