Microservices Without Containers

The world of Microservices architecture is inching in popularity and the same is true about Container Technology. It is a known fact that the two complement each other perfectly well since Containers provide a means to package and deploy Microservices in lightweight runtime processes.

Keeping in line with the global trends and digital adoption, enterprises want to embrace Microservices architecture for agility. However, security and operational readiness will take a while for adoption of container technology just as how the adoption of Virtual Machine (VM) technology took its time. The million-dollar question today is – Should enterprises wait to adopt Container Technology, and then adopt Microservices or should enterprises adopt Microservices regardless of containers.

Before we go ahead and push Containers at the curb, let’s look at what will be missed when enterprises ignore Containers in Microservices architecture.

• Lightweight – Containers are lightweight when compared to VMs. As a result:
  • Storage – Container storage requirements are lesser when compared to VMs
  • MTTR (Mean Time To Recover) – Due to a higher resource footprint and boot time of VMs, (Mins in VMs v/s Seconds with Containers), it takes longer for the VM to restart post failure
• Economic Impact – A strong service isolation requires services to be deployed on separate VMs (one service per VM) or Containers (one service per Container). With the availability of Containers, it becomes easier to deploy on physical machines. On the other hand, VMs need higher resources to run the same number of Microservices
• Compromising Isolation – For optimized usage, businesses generally encourage multiple services to be deployed per VM. This approach however carries across several challenges such as:
  • Network port conflicts across services
  • Rogue service or a service that is under heavy load could leave other services starved for resources
  • Bringing down a VM for a specific service upgrade will affect other services

Although containers have many advantages as listed above, their unavailability is not the end of the road for Microservices. Enterprises can still reap benefits through the adoption of Microservices because of following reasons.

• Agility - Developers benefit from design time isolation in designing, developing, testing and release a service independent of other teams building other services.
• Polyglot Thinking - Architects can adopt fit-for-purpose technologies for different services. For example, Elastic Search for product search, Redis for shopping cart, and MySQL for order capture.
• Deployment Flexibility – Microservices gives flexible deployment options that can evolve.  One can start with deploying multiple services within a VM. If a VM is to be deployed to handle high-intensity traffic, the same could be done in a separate VM and scale it independently

Enterprises will however have to build the following capabilities to compensate for the absence of containers.

• Create strong DevOps capability, in order to provision, run and terminate VMs through automation.  This reduces both environment differences and service deployment times
• Institutionalize monitoring tools, alerts and quick action in case of service failure
• Employ dynamic Service Registry, Load balancing mechanisms to handle proliferation, runtime discovery and access to services

Conclusion: Enterprises should proceed with Microservices adoption. Transition to containers only requires change in deployment mechanism.  Once containers are ready, the transition can be done seamlessly.