Containers or not, Application Centricity is the key!

While containers have stormed themselves into mainstream infrastructure play, it is now time to take a step back and think how can you really leverage them to your advantage. You now have a very fast and effective Ferrari at a small percent cost, but is that what you need? Will you be able to handle it? Will it only make a mess out of an already messy set up you have?

The world of containers is about immutability - Use and throw. It is clear that fixing an infra issue is more expensive than building a fixed one from scratch. While that is a great solution from a infra perspective, will it help manage application to be delivered faster and better in a consistent fashion? Can business see difference in service levels? 

Containers come and go, Applications are here to stay

In such a case, the focus has to be on Application centricity and building the container infrastructure to help manage applications in a very cohesive way.

What exactly does it mean to keep the container infrastructure 'application centric'?

Below are a few thoughts I have put together - please add your thoughts further:

• Bundle all provisioning automation at the environment level to ensure that the container level automation is made as a core plumbing with minimal changes going into this layer. (Example: Have one common environment creation pipeline used to provision all environments, the composition of such a pipeline may have container creation as part of it - the end user sees only 'create environment' event for a given stage, without any nuances of what containers get created under it, or what existing servers get integrated)
• Bundle all container actions at an application level and apply these at an environment level rather than taking any action at container level. Forbid any action at container level at all times. (Example: Action may be applying security patch - you may actually create a new set of containers, but from an application perspective, you just applied a security patch)

• Progress application environments across various life cycle stages by using containers or container compositions promoted to these stages. Proactive container (or container compositions) progression help creating clear view on what containers are available at what stage. (Example: All containers in a given stage is visible to the end user for him to ensure he can create new environments for that stage using them)
• Roll-up monitoring events at application environment levels to ensure the environment is up on the whole, and use garbage collection heuristics to deal with the anomalies at the container level. (Example: an infra event at a container, need to be handle at that level, while the health indicator not bothering about it unless it breaches application level tolerance)
• Roll up all operational events like log-shipping, audit events, network policy management, secure access and validations all at an application level, and pushed into or pulled from containers consistently.
• Wrap running containers as application versions such that the end user can get to the right version of the application without the nuances of containers and container id, but by Application and Application Versions.

 Thoughts?