Container as a Service?

Every day, IT professionals live and breathe applications, yet our focus for operational tools is a single container, virtual machine, database, etc. How do these items map to the application in use? Even the monolithic-looking applications of yesterday were actually made up of services. Those services will be reborn as microservices within the applications of tomorrow. How do we make this transition? Is it possible with a container as a service model? Or should we scratch the past and start over?

Container as a Service (CaaS) companies want us either to start over or to rethink the past while leveraging what we can do to move from a monolithic application to a service-based application.
Let us take a simple example: management tools. Many of them use databases. Either those databases are embedded in the tool, or the tool calls an external database. Yet, databases are the epitome of a service. They are a data service, and as such, they are easy to split off from the main application and containerize, control, and otherwise manage. There are security tools to protect them from SQL injections and data loss. There are brokers to convert from one form of database to another, to mirror them, or to otherwise make them available. There are even tools to containerize the database service so that you can run more on one node than another. Granted, this has always been possible, by using different roots or instances.
The goal of all these tools is to increase the reliability, availability, and security of the service. We have been putting brokers, security tools, and management in front of our databases and similar services for years. However, we still look at things from an OS level, not an application level.
Is the database the application, or is the user interface plus the middleware plus the database the application? Don’t we want to know the performance, the security, and the issues with the entire stack, rather than just one piece? We try to stitch together these metrics instead of actually looking at the whole. Humans are still needed to define this whole, and that requires systems engineers and others who can see the pieces that make up the whole.
CaaS further imposes a new part of the system. We can now use this to handle just one part of the service—in some cases just the data services—but I see this as being a crucial part of all applications. All applications put together services like so many beads on a string. If we do not understand how the services work together, a break in the string makes a royal mess and can be difficult to repair.
Now, this is not an argument against CaaS. I think CaaS is a step in the proper direction, as it forces IT to consider what services our applications use. But first, we need to step back and look at the entire picture. We need to stop being hyperfocused on just one service and increase what we view. Even if we increase that view by moving back 1,000 feet, we are still far short of the 30,000-foot view the business planners see.
This is a call to start thinking of the systems that surround our applications, to find all the beads that make up the services the application touches. If I got anything out of InfoSec World 2016 this year, it was the idea to stop playing in the weeds and start looking at the lawn. See as much as you can. Increase your view and your knowledge to gain a systems-level view of the application,  the enterprise, and even the business.
We are hamstrung by hyperfocusing on just one thing. We need to grow and increase our view—not all at once, but fast enough to see the bigger picture that makes up the application, the processes in place, and enough of the business to make sense of it all.
Where are you in this process? Perhaps it is time to start looking at logical containers for parts of your existing environment. That is a starting point that may move you toward actual containers, such as Docker, DH2i, and others in production.