Most off-the-shelf deployment solutions are no better than scripts
In my previous blog Why application deployment scripts fall short in supporting today’s enterprise I talked about how current script-based solutions in the enterprise are outdated. For many involved in the application deployment process, the challenges of a constantly evolving landscape and the alarming increase in the number of application deployments, written of in my previous blog, aren’t news, it’s just a reality and quite frankly a way of life. These challenges haven’t completely gone unnoticed. There are many entrepreneurs who thought this was a good opportunity to fill a void and a need, and of course make a buck in the process. However, in their rush to create a solution they sacrificed an opportunity to really innovate. So in this blog, I will discuss at both the technical and operational level the limitations of off-the-shelf solutions that are out on the market today. I think you will be surprised to learn that off-the-shelf solutions have done nothing more than just replicate some of the same limitations and never really addressed the real issues with application deployment in the enterprise. The real issues for deploying an application in the enterprise are pretty straightforward. I’ve listed them below. • Having expertise on the various middleware platforms to deploy an application • Being able to deploy the application consistently while the application and target systems are evolving • Being able to quickly, consistently and reliably deploy to all environments • Being able to deploy the entire application and all of its components and configurations, not just the application binaries • Being able to provide front to back-end integration with current toolsets as to provide an end-to-end deployment solution • Managing the increasing number of application deployments and the complexity of a constantly changing infrastructure Today’s modern solutions that are process design or configuration based, on the surface seem like a great improvement over previous script based solutions. However, upon closer inspection you will come to realize that at best it’s a minimal improvement. After closer inspection of these solutions you will notice that they really didn’t innovate, often employing many of the same concepts scripts do. Listed below are some of the concepts that carried over from scripting solutions: • Expertise still required to construct deployment process • Deployment logic pre-determined (static) • Does not deploy all application components to all middleware platforms • Distributed Agent based architecture • Solution intended for operations staff You see off-the-shelf solutions still require experts; someone has to still construct the deployment logic just like someone has to write the scripts. Of course they’ve most likely provided you with a nice user interface that can arguably make it easier to construct the logic but at the end of the day you still need the expert to define the steps necessary to successfully deploy the application. The other issue with the deployment logic that you construct is that it’s static in nature, just like scripts. What I mean by static is that the deployment logic is based on the initial deployment and doesn’t take into consideration subsequent deployments, which will likely have changes to both the application and infrastructure. Everyone knows that applications and target systems are always in flux. The other issue with many vendor-based solution is that they rarely automate the entire application deployment. Off-the-shelf solutions are usually focused on deploying to the application container only or even worse, a specific middleware just like scripts, but we all know that applications usually consist of more than just binaries and container specific configurations. There are usually database components, messaging components and various other middleware components that comprise the application. Most off-the-shelf solutions also require that you run an agent on the target machines, which introduces a lot of additional overhead to manage and maintain. Actually if you have a very large infrastructure you will eventually need a tool to deploy, your deployment solution, which is absurd if you think about it. Additionally, off-the-shelf solutions never really addressed the productivity challenges in development and testing. Quite often their target users, just like scripts, are operational staff that of course means they don’t have the notion of self-service deployments and as a result programmers/QA staff still require others to carryout their deployments thereby never eliminating the bottleneck that currently exists. A modern solution shouldn’t replicate or inherit any flaws from previous paradigms. It should be void of agent-based models and the solution should be based on a non-invasive approach, as to reduce management and overhead. A modern solution should be dynamic in nature and account for changes to both the application and its intended target systems. It should also be designed to intelligently and automatically calculate the deployment steps as to eliminate reliance on highly skilled and expensive resources and also to greatly reduce deployment time by eliminating unnecessary steps. The solution should be intended for all users from development, all the way to production so that all can benefit from automating application deployment.