I keep hearing, “Do you have a container for that, or are containers are the only way to move to the cloud?” and many other phrases of that ilk. So, the questions I have to ask are “When is the best time to use containers? Can you use them for everything, and should you?” Those are really the questions moving forward. As we move up the stack, is container technology the right way to go, or is there a better approach? As always, the answers depend not only on who you ask, but also on their understanding of the problem, and on the problem you are trying to solve.
Containers in General
Containers in general are simply a method to package up an application that includes not only the application code but any library that is not part of the base operating system upon which the container will reside. Most container operating systems are just enough OS. In other words, they are a kernel, the basic libraries, and enough operating system to allow someone to connect to the network and deploy their containers. This implies they are very tiny things indeed. The applications, then, live within the container. Access to the container is through a container manager, a web interface, or some other API.
Why Use Containers?
Containers are often designed to be used as microservices or discrete parts of an application. These microservices do one thing extremely well and generally only one thing. Perhaps the service logs data very rapidly, looks up geographic data based on IP, sums up critical data for instant reporting, or, well, you get the picture: any number of activities. The key is that these activities are tiny and do one thing very well. They are the KISS method of software development. Each microservice has inputs and outputs and often communicates via an API. In essence, when you use microservices and containers, you are forced to redesign your application to be a set of discrete and unique sets of functions.
Do You Need Containers?
This is often a huge question, and the answer is a resounding “no.” There are many older applications that already make use of microservices and discrete components that do one thing and only one thing. However, those applications are few and far between. They need to be architected that way from the beginning. It is terribly difficult to bolt on microservices. Why? The API to call the microservices needs to be well understood, part of the base application as the client, and used by the microservices to perform their actions. If that is not designed well, it often fails miserably. However, when it is, you can easily use containers or just discrete services outside of the container world. Containers provide a packaging method that is very useful, unless your existing application already handles this.
So, Can I Put Everything in Containers?
This is the big question, and the answer is “probably”—but the real question is “should you?” For example, it is possible to containerize many databases, but the containers end up so large that you might as well make them their own system. You gain very little by making them containers. Still, if you have a microservice that is a single service with very little overhead and maybe a few libraries, then using containers can be a benefit. I think there are simple rules for putting things in containers:
- Is the object to place in the container a microservice? If so, then yes.
- Is the object to place in the container API driven? If so, then yes.
- Is the object to place in the container using a web interface? If so, then yes.
- Is the object to place in the container in need of human non–web browser interaction? If so, then maybe.
- Is the object to place in the container huge? If so, then maybe.
The “maybe” part of these rules is based on your feel for added complexity. For example, to gain shell access within a container would require the shell to be present within the container, but it would also require the container management software to be used to gain access to the shell. Some may not find that too complex; others may find it more complex than they desire. In other words, to use Docker to gain access to the command line within a container:
- You do not just log in to the system—you have to find the ID of the container, then transfer to that container and start the shell, and then perhaps log in. It can be daunting unless very well scripted. From a security perspective, that level of access to use a command line may not be the best approach.
- Or you would configure a proxy so that you could ssh to the container through the proxy and be connected directly. However, this would require you to add more into the container. In this case, user management would need to be considered carefully.
There are many ways to achieve what you want within a container, but does the overhead of using the container, of the extra security required, move you outside your comfort level for complex solutions? We have yet to talk about persistent storage.
By all means, use containers, but remember that not everything is geared to be a microservice. Or more to the point, adding containers adds a level of complexity. Sometimes the complexity is warranted to ensure fast and efficient deployment of microservices. However, when direct human interaction is involved, often containers are not the best choice.
How do you use containers today? What rules do you follow when you use containers? How do you handle direct user interaction?