The Rise of Containers

Introduction

If you are an engineer in IT who started working in the last 5 years in the world of container technologies like Docker and Kubernetes, this is something you have grown up with. Using Docker containers to solve enterprise workloads has become a part of day to day work, no questions asked. It is an interesting topic to analyze how we got here. When I started my engineering career in the early 2000s (anyone remember the dotcom bubble?) one of the key technologies for creating scalable server-side components was Enterprise Java Bean(EJB) part of Java 2 Enterprise Edition(J2EE) specification. This specification was created and promoted by Sun Micro System (Now part of Oracle). In the 2000s an engineer with EJBs and other J2EE skills was in high demand. In this story, we will start with learning a little bit about EJBs/J2EE specification and how quickly technology changed and moved forward to where we are now.

A New Hope

The goal of EJB specification was to create reusable server-side Java Components. “Build-Once-Run-Anywhere” Components would implement predefined methods or hooks which allowed them to be deployed in any EJB Compliant Server. Clients would invoke components using Java Remote Method Invocation(RMI) protocol. Some of the key services provided by EJB Containers are listed below-

EJB Cache/Pooling — This will allow us to specify how many components are created during startup and ready to process client requests.

EJB Scaling — This will make sure components are scaled up if the number of client requests increases.

Life Cycle Management — If a component crashes due to some error the container would recreate. When a component is getting taken out of the service container would call destroy method on the container

Transaction Management — This allowed us to define the transaction boundary on EJB methods. Multiple EJBs can participate in a distributed transaction.

This ushered in a new era of building reusable server-side components. EJB along with other J2EE specifications became a new gold standard for building enterprise applications.

The Application Server Menace

During the early 2000s, every software company was building J2EE specification compliant application servers. Below is the list of top J2EE Application Server vendors:

BEA Weblogic Application Server (Now part of Oracle)

JBoss Application Server (Open Source Option)

IBM Web Sphere Application Server

These application servers provided a platform for building high-performance scalable enterprise applications. Other key J2EE specifications include Servlet API, Java Database Connectivity (JDBC) API, Java Message Service (JMS) API, and Java Connector Architecture (JCA) to mention a few. To differentiate the product offerings, vendors started bundling special features and tools with application servers. In the next 10 years till around 2010, we saw tremendous growth and adoption of the application servers. Every enterprise was running some form of application server platform.

Soon it became clear that the dream of having reusable server components in the marketplace which can run anywhere is not going to happen. Few of the reasons I can think of:

— J2EE Specification was built around Java and so other programming language workloads could not participate, which drastically reduced the footprint of reusable components

— Application Servers became a complex platform to manage for enterprises, resulting in valuable engineering time invested in keeping the platform operational.

— Application server vendor built their own extensions and features on J2EE specs reducing the portability of components.

The Force Awakens

The industry was looking for something more advanced than the ability to package and run components only in a J2EE application server. Specifically, something which can support multiple programming language and hardware platforms, something which is more open and not controlled by few Application Server vendors.

When the Docker platform launched in 2013, it met the needs of the industry that I outlined above. Docker defined specifications to package and run applications written in any programming language on a virtual machine with a Docker engine. This is a new level of abstraction which J2EE application server is not able to provide.

Since 2013 Docker has seen rapid adoption in the enterprise. Creating Docker images for enterprise workloads has become new normal. Docker Hub has become the official repository for publishing and downloading Docker Images. The dream of having a reusable server component has finally become a reality.

In 2014 Google Open Sourced Kubernetes — a Container Orchestration framework. Kubernetes brings features like load balancing, auto-scaling, container health management, rolling updates, etc. to Docker containers. This just was the right timing for two technologies: Docker+Kubernetes, which caused Enterprise building Cloud Native apps to immediately latch on to these two technologies.

Final Thoughts

Since 2013 we have seen enterprises adopt new container technologies like Docker and Kubernetes as a platform for greenfield projects. Most of the enterprises are moving away from J2EE Application servers. Building containerized and serverless workloads seems to be the way to go for the foreseeable future. It is still worth reminding ourselves that nothing in technology is permanent.

May the force be with you!

Disclaimer: This is a personal blog. The opinions expressed here represent my own and not those of my current or any previous employers.