The breaking down of monolithic code bases into rapidly deployable microservices marks a paradigm shift in software development. As described in the first post of this series, microservices allow for faster release cycles and can help squeeze more performance from your hardware footprint. Realizing their full potential, however, will require you to also introduce Docker containers into the mix.

That said, Docker containers can present a number of significant challenges related to management, hardware, and security. To get the most out of your containers and the microservices they deliver, you need the right approach.

The challenges with Docker containers

Introducing Docker containers into a microservice architecture necessitates a new approach to developing features, which means development teams will need time to learn how to integrate them into the release cycle. Fortunately, the workflow for developing a container-based architecture isn’t much different from the workflow for developing a non-container one, which means the skill gap to be traversed is minor.

Additionally, containers pose security concerns. For instance, are they completely isolated so an attacker cannot use them to obtain root access on the host environment? Are any secret credentials stored in the container metadata or in the running environment?

Containers will also generate hardware-related questions. For instance, are the containers stateless, or do they require persistent storage that would tie them to the underlying hardware?

By considering the challenges associated with using Docker containers, development teams can address and avoid some of them — and quickly identify and resolve any security and network problems that do arise.

The best approach for success

So what is the best approach to mitigating these risks when adopting a container-based architecture?

The ideal workflow includes the following high-level steps:

1. Define the contents.

Choose what to include in the container itself. (This can be everything from cloud components to software stacks to application portfolios.) When defining the contents, consider the security requirements — especially if you are using any open source components. Make sure all components are free of known, exploitable, or vulnerable code.

2. Select the appropriate base image.

By selecting the most suitable base image, the development team can focus on building their stacks and applications, resulting in quicker turnaround on iterations and deployments. Don’t forget to evaluate the base image’s security risks — and the implications of a security breach across the cluster of containers in the development platform.

3. Develop the code.

The development of a containerized application is very much like that of a non-containerized application. Be sure to constantly build your image with a pre-commit hook (or bash script) — a critical safety defense that can prevent “bad” code from being released into production. Pre-commit hooks should be used across the entire team and included in all your code.

4. Test the code.

Verify that any application code within the new container is functional by adding a step to the developer workflow to build and verify the container before committing changes to a source repository. (Don’t confuse this test with full code verification testing; this only confirms that the deployment unit — the container itself — still provides the service on the expected port.)

5. Deploy the code.

Send the fully tested container to a central repository from which it can be deployed. Many teams use a staged deployment that involves a central build system executing a controlled build that then submits the container to the central repository.

A win-win situation

So is your team ready to adapt? After addressing the minor skills gap with the new toolset, most teams can make the change to a container-based development approach with little impact on productivity.

By updating your development workflow — a considerable task, but one where Pythian can provide expert guidance and advice — and by giving upfront consideration to the overall security requirements and container interactions, a container-based architecture will pay off through efficient, high-velocity development and deployments.

As well, Docker containers reduce infrastructure costs by removing the overhead of virtual machines and using compute resources more efficiently. They provide a reliably consistent deployment experience from development to production. This is a win-win for CIOs, developers, and those demanding digital consumers.

You can learn more about microservices and containers in Pythian’s white paper Getting Started With Microservices and Containers, including a more detailed look at each of the steps that make up the approach to adopting a container-based architecture.