I was recently reminded of a key insight included in a presentation from the Datical team at IBM Innovate 2014. They automate migration of databases changes (and naturally have an integration with UrbanCode Deploy). However, because they are application focused, they try to outline what parts of database schema and configuration they manage (the “Application DBA”) and what they don’t (“System DBA”). Things like capacity planning and performance tuning are generally system work while things like application schema and stored procedures belong to the application.
This distinction is relevant outside of the database space as well. When automating the deployment of more complex applications it’s important to clearly identify what stuff is part of the application, and what is infrastructure or system settings. Things like application server configuration also fit this model. A security certificate or application server patch may be treated as infrastructure. Connection information to databases or message queues, as well as thread and memory allocation probably belong to the application.
Making this distinction helps identify what should be managed through your application deployment automation. Anything that belongs to the Application goes in. Anything that isn’t Application does not. It may be a better fit for a generic infrastructure automation tool, or be the domain of expert administrators.
How do you draw the line?
System stuff is going to be things that tend to be shared across applications. In multi-tenant scenarios, this is most obvious. If a single application server hosts a dozen applications, changes that impact many applications are probably system. Looking at the driver of the change is another clue. Is your application server being patched because applications need the update (probably not) or because all your application servers from that vendor are taking the standard update (more likely)?
There are going to be grey areas, overlap and special cases for any application. It’s ok to take your best guess and just pick a designation. Expect those elements to cause a bit of friction, but for things to basically work out reasonably well.
Expect this distinction to go away (eventually)
With the shift to more cloud centric models, multi-tenancy is on the decline. The entire infrastructure stack from virtual machine to application configuration is increasingly seen as part of the application. This full stack approach will require bringing together application centric automation and system centric automation into a single definition of the application. This is what we’re doing in UrbanCode Deploy with Patterns.
For most teams though, this transformation towards full-stack engineering is not likely to be completely adopted for some time. If you are in this normal set, you take the time to explicitly define what your team will treat as part of the application and what will be treated as outside the application. Your standards will shift, but they will serve you well in avoiding conflict and streamlining your automation efforts.