Standardized application infrastructure contracts

When we began implementing a continuous deployment pipeline for yet another application the age old principle of DRY (Don’t Repeat Yourself) started to become more difficult to ignore. Our applications had been produced at different times each with varying technology stacks and each with the newest approach the team had come up with to: deploy, load balance, monitor etc.. The newest applications were being continuously deployed to test and production environments an instance at a time (to provide zero-downtime), the oldest were being deployed by hand by executing a script in the target environment (and would take the service down); some applications were deployed from a maven style repository, whilst some applications were being deployed from our historical homegrown repository; some builds pushed the artifacts into the target environment via scp, whilst some builds instructed the target machines to pull the artifacts from their respective repository. All scripts for doing these were different for each app even though some shared the same heritage.

Each application had its own puppet codebase, its own way of providing information to our monitoring infrastructure and its own way of interacting with the load balancers; to put a new application into this world was like starting from scratch everytime.

The infrastructure team now had a backlog of requests to put new applications into production so we thought a more homogenous approach maybe more appropriate. The result was that a representative group of developers from each of the teams ended up in front of a whiteboard where we “merged” all our current implementations in order to form the new standard, and so the application infrastructure contracts (AIC’s) were born.

New applications must implement the contract and must pass the contract test, those that do get zero-downtime continuous deployment for “free”.

In the next post I will explain the various parts of the contract, to support: deployments from standardized repository locations; standardized interaction with our load balancers and more.

Leave a Reply

Your email address will not be published. Required fields are marked *