Why should we care about containers for development




Why Containers

It's no doubt that you have heard the buzz about containers over the last year or longer. If not containers, then some technology, framework, or tooling associated with it; Docker, Kubernetes, microservices are just a few of these. What are are the benefits from a developer perspective?

Works on my machine

The scenario of each environment your code or application is deployed to could be different. How many servers, the configuration of CPU, RAM, etc. may vary from Development, QA, and Production and there is no guarantee the app will perform the same. Using containers provides the capability to define these parameters upon startup such that each image has the same requirements regardless of where it is deployed.

docker run --cpus=2 --memory=1.5g myapp  


Applications that are comprised of many services may not be developed in the same language or framework. If you are developing a service in .NET Core for instance that calls a downstream service written in Node.js or Go, the development team responsible for that service can build the container image and make it available in your private registry.

Using a docker-compose file, you can then bring in that container image without needing Node.js or Go installed on your machine and test your calls against the development version.


    image: nodeservice:dev
      - NODE_ENV=Development

      - nodeservice
    image: namesweb
      context: .
      dockerfile: namesweb/Dockerfile
      - NODE_SERVICE_ENDPOINT=NodeService-Dev
      - "57270:80"

Test Data

There are a rare amount of applications that do not involve data and maintaining an instance of your production system locally can be a task. Installing the tools, platform, server etc., as well as keeping all of these items up to date is above an beyond what you'd probably want to worry about as a developer.

Here in this docker-compose file an instance of SQL Server on Linux is started and with a script file, the test database is created, and finally, test data is loaded using the Bulk Copy tool.

version: '3.0'  

    image: microsoft/mssql-server-linux:latest
    container_name: mssql
      - 1433:1433
      - /var/opt/mssql
      # we copy our scripts onto the container
      - ./sql:/usr/src/app
    # bash will be executed from that path, our scripts folder
    working_dir: /usr/src/app
    # run the entrypoint.sh that will import the data AND sqlserver
    command: sh -c ' chmod +x ./start.sh; ./start.sh & /opt/mssql/bin/sqlservr;'
      ACCEPT_EULA: 'Y'
      SA_PASSWORD: [email protected]$$w0rd



echo creating resources in $wait_time  
sleep $wait_time  
echo starting...

echo 'creating Names DB'  
/opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $SA_PASSWORD -i ./init.sql

echo 'creating Names Table'  
/opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $SA_PASSWORD -i ./data/NameTable.sql

echo 'importing data...'  
# Bulk load data from a csv file
/opt/mssql-tools/bin/bcp Names in data/Names.csv -S -U sa -P $SA_PASSWORD -d Names -c -t ','

echo 'add uniqueid column'  
/opt/mssql-tools/bin/sqlcmd -S localhost -d Names -U SA -P $SA_PASSWORD -I -Q "ALTER TABLE Names ADD ID UniqueIdentifier DEFAULT newid() NOT NULL;"

echo 'checking data'  

init.sql & NameTable.sql



USE Names;  

  LastName nvarchar(max),
  FirstName nvarchar(max),
  FullName nvarchar(max)

Using this test database image a subset of the production data is loaded and available for the application to use. The container_name: mssql is set as the server name for the connection string. All that is needed for the application is to hit this server now is a change to the setting.

If you are using docker-compose for all of the containers, the DNS name resolution is handled automatically. To use the database container individually, get the IP Address by using the command docker inspect -f "{{ .NetworkSettings.IPAddress }}" <containerId>

"ConnectionStrings": {
    "NamesConnection": "Server=mssql;Initial Catalog=Names;User=sa;[email protected];MultipleActiveResultSets=true"


Never is there a scenario of deploying applications easy, right? Rolling back on failures ever a harder story and at times this is almost in itself another deployment.

Whether you are using a full CI/CD system to build your containers, command line tooling through docker build or Visual Studio Docker Tools; all of the dependencies are isolated to the image when deployed to the host machine from a registry, it is still that same container.

Should there be problems with a deployment, things do go wrong, rolling a deployment back a version can be as simple as changing the version number of an image from 1.1 to 1.0 and your app is reset.


Containers provide a packaging and deployment mechanism for our application and its dependencies. The container registry is a powerful concept that helps with the deployment and distribution of our application.

Containers also improve the "inner loop" of our development experience when working locally, particularly as we trend towards building microservices over monolithic applications. They provide greater parity across local and remote environments including the cloud and help our infrastructure to become more immutable.

The vibrant ecosystem of tooling around containers also help us consume cloud-native platforms and development methodologies. Whether we are using serverless containers, a PaaS platform that supports containers, or an orchestrator like Kubernetes, we focus on our application instead of thinking about and managing the individual host or hosts we deploy it to.


Tweet Post Share Update Email RSS


azure docker containers