Best Practices for Container Development

At some point, your development must transition from traditional monolithic applications to microservices. That means containers. The world of container development is significantly different from what you're used to, meaning many old best practices no longer apply.
So, if you want to move away from standard application development, what should you do? Learn as quickly as possible. And given how fast the development world is evolving these days, that pace has reached a frantic speed. So you have to quickly master best practices, or else you risk either being pushed out of the game or constantly deploying applications that either don't work, are unreliable, can't scale, or are too insecure for enterprise use.

So what are the best practices for container development that you should already know? Let's look at some of the more pressing ones that can be implemented from the very beginning of your journey.

Use Stable Images from Reputable Organizations

This item tops the list simply because it has become one of the most important issues related to container security. Everything you develop in the container world starts with an image. You can create your own image from scratch or take the quick route and grab an image from, say, Docker Hub. If you go the third-party route, you should always use only stable images from reputable organizations.
For example, you want to deploy a container based on the latest Python image. If you search Docker Hub, you'll find many Python images, but only one official image from the actual Python developers. That's the one you should use. Every image obtained from an official organization will be labeled as such. It's important that you use only these images. Do not take an image from an unknown source, because you never know what it might contain. 

Keep Image Sizes Small

You might be tempted to build your containers based on an image that includes several bells and whistles. Remember this: The larger the image, the larger the container. If when deploying an application with many moving parts, all containers are based on larger images, that not only leads to unnecessary services but also significantly increases cloud hosting costs.
Remember, the idea of containerization is to achieve huge scalability while reducing cost. So deploying containers based on large images contradicts that goal.
Don't do it. Always use the smallest (official) image you can find. And if you can't find an official image that's small enough, create your own. Moreover, when using a larger image, the attack surface can grow exponentially.

Use Persistent Data

You should not store data in the container's storage layer. Why? Two reasons: storage and availability. Think about it: If you store data in the container storage layer, that container will grow exponentially. But that's not all. If the container fails, access to the data will be impossible. Instead, you should store data in persistent volumes.
Using volumes ensures that container sizes won't grow as data accumulates, and stored data will be accessible to multiple containers. 

Use CI/CD for Testing and Deployment

You'll need a lot of testing. And deployment will happen constantly. Remember, when containerizing an application, the goal is automation. You don't want to slow down deployment time because you have to manually test and redeploy everything. Instead, you should use a Continuous Integration/Continuous Deployment (CI/CD) approach.
The goal of CI/CD is to automate as much as possible. If you use CI/CD for testing and deployment, you'll find that everything works much more efficiently.

Tag Container Images Wisely

As you create your own images (or modify ones you've obtained), they need to be tagged before being pushed to repositories. When you tag these images, make sure you do it wisely. Don't just tag an image with "latest" or a date. Maybe you added some specific feature to the image or created an image for a specific purpose.
Make sure you tag these images in such a way that you will always know their purpose.

Ensure Security at Every Stage

When developing containers, security starts from the first step and never stops. This is especially true when the goal is automation. In this case, security should be viewed as a circle that runs through all aspects of deployment. 
Security starts with base images, goes through container manifests, checks DevOps, GitOps, and automation tools, follows deployment, and returns to the repositories where your code is stored. If you consider security as an infinite component that must follow the container from start to finish, you can ensure that such deployments are worth using.
Just remember, security in container development never rests.

One Application per Container

Although you can deploy a single container that contains all the applications needed to run a service, you should not do that. Why? The main reason is that single-application containers are easier to scale. And since scalability is one of the main goals of containerization, this is clear.
Scalability becomes possible because the cluster manager can deploy more containers when needed. For example, if scaling your application only requires increasing the number of database instances, then if you deployed that database in a container with other applications, scaling would include those applications too, which is inefficient. 
Moreover, single-application containers are much easier to build and test. 

Conclusion

If you start your container development journey with these best practices, you'll already be on the right track. Of course, there are always more best practices to find, some of which will be dictated by the specifics of a particular project. But overall, what you see here should help you in most container deployment cases.