An introduction to Containers-as-a-Service
The most important moment in the rise of a new technology is when it is crowned with a not-very-helpful acronym. For all of us working on web architecture that moment has arrived: let me hear you shout “CaaS”! It stands for “Containers-as-a-Service” — let’s try and figure out what that means…
What are containers?
Containers allows developers to build their source code into an image called a “container” that includes the original source code plus all of the code’s dependencies. Once the source code has been “container-ized” it can then be reliably deployed on any Linux machine. This could be a developer’s laptop, a local testing server, or a virtual machine running in the cloud on AWS. With a container there is no need to spend time configuring the server environment — the container contains everything that the code needs to run.
What do you mean by “as-a-service”?
The ‘as-a-service’ part is harder to pin down. Over the past few years, there has been an explosion of companies and products aimed at leveraging the advantages of containers. Some are focused on turning your code into a container and registering it (check out our hackathon project ContainerFactory), some are focused on tracking your containers and deploying them in the cloud, and some are focused on orchestrating the activity between containers once they are running.
OK — so how are containers used?
Containers really shine during deployment and scaling. Containers can be deployed to any of the large IaaS providers (think AWS) and if there is an error they can be scaled up or stopped and restarted automatically. But if you’re working on a new project or a small project then deployment and scaling are probably not your principal concerns.
One emerging use for containers is as a component of a distributed architecture, sometimes referred to as a “microservices”. The term ‘microservice’ is not a technical description, rather it just refers to the fact that the component is smaller than a whole application, and also that it meets a few criteria: it’s business-focused (the service only handles one business need), it’s independent (the service is not dependent on other services), and it’s stateless (each request to the service is independent of requests that came before it). Check out this blog post for more information on microservices.
Microservices plays very nicely with containers. For example, if your microservice is stateless and independent then it can be easily scaled — as your traffic increases you can just create more containers and distribute the load across them. When combined with a service-discovery component such as Consul or Kubernetes, these containerized microservices can be added, removed, swapped and upgraded as needed.
So I need to convert my infrastructure into containerized microservices?!
No, probably not yet : ) Although the industry is eagerly embracing containers and microservices, the tools and services for managing distributed architecture are still very much in flux. Over the coming months we expect to see many more improvements and new products in this space — stay tuned!
