Around 2005, I went with two colleagues and our team leader to present (or maybe deploy, I can’t remember exactly) the in-house web application we had built for the client. It was built using ASP.Net WebForms and connects with a MS SQL Server instance. I remember installing IIS, transferring the application successfully, but it didn’t work as expected because something was missing (I don’t remember what exactly, since it’s been nearly 20 years) and I remember calling another colleague who’s already in the office to bring another CD (not the application) to fix the issue. The environment we built the application in wasn’t the same as the one we deployed it to, so we ran into all sorts of unexpected errors we had to fix on-site.
This is where container technology really comes in handy. Now we can deploy web
applications in containers that package everything they need such as code-base, runtime, libraries, etc. into a single unit (a container image). All you need is a container engine, and it can run anywhere and guaranteed to behave the same as it did on the developed machine.
Even though container technology eases the headache of deployment, it’s still not enough for modern micro-service architecture. Each micro-service, running in its own container, needs to be managed, preventing outages, spinning up new instances when demand spikes, and so on. That’s where Kubernetes comes in. With Kubernetes, we can now automate, manage, and scale containerized applications up or down as needed.