I personally think the concept behind running your (micro)services inside containers is a big game changer in the tech landscape. Every tech article, conference or just a chat with someone in the tech community there is a phrase about containers.
Picking up containers and transform your architecture, team or company isn't that straight forward. This blog post gives you some hand-holding for your first steps into containers and starts the transformation.
Shipping containers
Like the real world shipping containers, it's all about playing by the rules. If your container getting build following those rules (dimensions), it can be shipped everywhere.
A port can handle those containers, a ship can transport them over the ocean and a truck can bring the container to your doorstep. Any the nice thing, it's doesn't matter what is inside a container because it's isolated by the form factor of the actual container.
Container isolation
Like the real world example of a container, the contents is isolated. Software containers are doing the same, it's an isolated process. A secure sandbox your (micro)service can freely play and make their own rules. One container can contain a Golang app and the other container, 100% isolated, runs a Java app or even a database.
As shown is this little cat animation, containers are isolated but using networking they still discover each other and consume the services if needed.
VM vs. Containers
Why containers and not equal to VM's.
A virtual machine (VM) is an isolated operating system
A VM is isolated by the hypervisor and can consolidate the bare-metal power into separated chunks. Each chunk is an isolated system. Running services (processes) on a VM are not isolated from each other. They can interact with the same CPU, network and memory space.
Running a polyglottic microservice architecture on a VM or a set of VM's is hard.
A container is an isolated process
A container shares the kernel of the underlying operation system (VM or bare-metal server) and uses his own isolated runtime environment for the process. Running services (processes) on the underlying operation system is just as simple starting a new container. The container runtime makes sure the are isolated from the root filesystem, user space, CPU, network and memory space.
Running a polyglottic microservice architecture with containers is easy.
The containerization machine
Running a service using container starts with creating the contents of your container. The dominant container technology is still Docker. If you want to containerize your services with Docker you need to understand the Dockerfile format. The Dockerfile is the contract telling how the contents of your container look like, the output is what we call the container image.
You need to understand and make the containerization process your own. Steps you need to take:
- Install the Docker runtime on your local box
- Run and understand the hello world tutorials and the docker commands
$ docker run hello-world
- Writing your own Dockerfile
- Building your first image
$ docker build -t=awesomeimage:1.0.0 .
- Run you first service using a container
$ docker run awesomeimage:1.0.0
Of course, if you are into service oriented architecture, mix-and-match technologies, or add a database to the mix, it's time to learn Docker-compose.
Docker-compose gives you a simple DSL (domain specific language) using a YAML format to define which service you want to run and how they are related (networking).
With both those tools mastered and understand how thing are related, you can start deploying your application to production.
Final note
At Cloud 66 we offer Cloud 66 for Docker to run your containerized application on any cloud or bring your own (bare) metal server.
Have fun learning Docker and the containerization machine. It's a journey with ups and downs. At the end of your journey, you'll find enlightenment and start releasing more often, breaking down monoliths and transform your company with containers.