So you have built an image that contains your application and have been able to run it as a container. Now you want to have it run in an orchestration framework such as Kubernetes or Swarm. There are some things that you need to consider within the design of your application to make sure you are fully leveraging the abilities of the orchestration framework that is executing it.

Externalize all values that are different between environments

These values usually come in the form of database host names, usernames, passwords, etc. The values that your application needs to function that are going to be different as your application moves from environment to environment. Every effort should be made to adjust your application to expect these values as environment variables. Orchestration software such as kubernetes have a built in resource called a "configmap" that allows you to define all of the environment variables your application needs. Another resource exists within kubernetes called a "secret" that allows you to store sensitive information and still provide them to your application in the form of an environment variable. It is also possible to use a volume mapping to represent the values as a file (properties files for example) in the event that it is difficult to convert your application to use environment variables. You should never store all of the properties you need for all environments within your image and then have it take in a variable of "DEV" or "PROD". This model requires production values to be made available to every level and also requires a re-build of your image when a value changes.

Provide a endpoint that serves as a health check

Most orchestration frameworks provide the ability to monitor your application and also provide seamless rolling updates. The accomplish this by allowing you to specify a "liveness" check and a "readiness" check. These checks can be in the form of running scripts but the most common implementation is to configure them to make API calls to your application. This means that your application should provide an API endpoint that will return a successful response when your application is considered "healthy". You can also create another endpoint to represent when your application is "available" for traffic. In most cases this endpoint can be the same for both checks. The orchestration framework will call the endpoint that you have configured to be your "liveness" check at an interval that you specify to decide if it needs to kill your application and start another instance of it. Since this call will be executed frequently you have to make sure it returns quickly and doesn't consume a great deal of resources to check what ever you have it checking. It should also log at a level that will not pollute your logging framework with the same messages over and over. The same considerations apply to the "readiness" check. This check is performed by the orchestration framework to decide if it can start routing incoming traffic to the new instance of your application. For example, if you have a java based web application that runs in Tomcat there is a difference in the time it takes Tomcat to be considered "running" and when your application then loads, initializes and is considered "running". By providing a "readiness" check the incoming traffic will not get routed to your application until your application is fully up and ready to accept that traffic.

Make sure the startup and shutdown of your application are as efficient as possible

During installation or updates of your application the orchestration software is going to start a new instance of your application and stop the instance that was running previously. These steps also occur if your application is deemed to be unhealthy and the software tries to create new instances and terminate old ones. It is for this reason that consideration should be made as to how long your application takes to start and also stop. Reasons for why these actions could be more or less efficient vary greatly, but the point is to investigate the time it takes for your application to start and stop. Areas that you can improve the efficiency of both actions will greatly impact the performance and health of the overall system.

Conclusion

There are more things to consider as you more frequently deploy and test your containerized application in a orchestration framework. These are just some of the most common items that I have to bring up to application development teams after they have build their application and now want to have it run in a orchestration framework. If you think about these things earlier in the development process it could save you a lot of time and increase your time to market with your application.