The other day a colleague and I got into a heated discussion regarding the definition of an enterprise application. He contended that each server hosted 1 or more apps which combined to make an “application stack”. I on the other hand defined an app as all of the components needed to effectively provide a service, regardless of how many servers they were spread across.
It seems like a silly argument I know. You’d be right to say “Who cares as long as it works?” I mean, at the end of the day the only thing that’s important is that the business is getting the service they need right?
Right, and that’s the problem. You see, I realized then that I had the benefit of seeing the world through service assurance tinted lenses. For better or worse I spent 7 years getting more intimate than I wanted to with CMDBs, service models, SLAs, KPIs, etc.. and like the people running the NOC I now viewed the app holistically rather than as a collection of parts. My friend on the other hand hadn’t made this leap and was still thinking in terms of projects, which got me thinking…
Why do we deploy our applications in a semi-manual piecemeal fashion and then expect them to function as a unit? Throughout the application release life cycle we manually deploy and redeploy the individual application components into a variety of environments without any thought for how the process itself is invalidating the testing and QA we’ve done. Then we scratch our heads when our production deploys fail.
It’s my contention (and that of Elasticbox) that it’s time to take a page from the service assurance playbook. It’s time to define and deploy our applications holistically, regardless of the underlying infrastructure. Only then will we a have a repeatable process that minimizes the manual effort that introduces so much time, cost, and human error into the deploy process.