Declarative deployment is the wave of the future

When at all possible, I like getting my information straight from the proverbial horse’s mouth. There is no better source of information, and I can avoid the intentional and unintentional biases interjected by intermediaries. When it comes to my day job, the source of truth for me is those working in companies to build and deploy application environments. When I start working with new teams, it is nice to get a feel for what they see as their biggest inhibitors. Not surprisingly, I get two predominant concerns from these teams regardless of their company’s size or the industry in which they participate:

1) They suffer from the amount of time, hair pulling, and arm-twisting involved in getting approvals to build an application environment.

2) Once the approvals are in place, they struggle to quickly and consistently deploy the target application environment.

In some organizations, the process to get to the point where a team has the necessary approvals to actually build an application environment can be bewildering. This sometimes involves business level approvals, usually involves architectural and design level approvals, and can stretch on for weeks or months. Unfortunately, there is little that technology can do here. Sure, you can buy and put into place workflow request and collaboration tools, but if organizational culture refuses any adaptation, you are simply stuck!

So, acknowledging that the first problem requires some amount of cultural adaptation on the part of the company, let’s move on to the second major problem. That is, once the approvals are in place and the team is ready to pull the trigger to standup the application environment, how do they do that quickly and consistently? My answer to any application team looking to overcome this major hurdle is to embrace declarative deployment models.

What do I mean by declarative deployment models? Simply put, I mean application teams should embrace the idea of defining what they need for their application environments, but focus less on how to apply configuration to meet those needs. To be clear, I acknowledge that certain companies come up with configuration or integration details for their application environments that offer an advantage via things like performance optimization. The knowledge of what they need to do is separate from actually carrying out the discrete tasks to do it though. At best, these individual configuration tasks are burdensome and tedious, and they offer little in terms of competitive advantage.

Now, maybe you are onboard with the general idea of declarative deployment, but it sounds a bit unattainable. The good news in that regard is that many concepts we are seeing with cloud computing, such as templates, patterns, and virtual images, are putting declarative deployment models within reach. Templates, patterns, and virtual images allow us to capture an application environment, persist it, and deploy it any time necessary. That said, these resources still depend on user-supplied configuration tasks, albeit possibly only once. That means you are still creating and maintaining scripts, carrying out configuration actions, and otherwise spending time doing things that offer no advantage.

In that sense, a better solution for declarative deployment is one in which you can associate a template, pattern, or image with a set of configuration tasks associated with the environment. As much as realistically possible, these configuration tasks should come from a system that presents them as simple options to the environment deployer. This is similar to the approach put forward by the integration of WebSphere CloudBurst and the Rational Automation Framework for WebSphere shown below.

I believe strongly in the declarative deployment style for application environments, and I believe we are just at the beginning of advancements in this style. As more and more companies turn to the cloud and look to reduce costs and activities that do not provide competitive advantages, expect declarative deployment models to increase in importance. This should come as a relief to the overwhelmed and underappreciated folks in charge of building and delivering application environments.