Druva finds a path to Docker with Calm.io

It takes guts to become an early adopter of Docker. And if you are apart of a larger, already established development team, it also takes some strategy as well. So you have to balance a complex equation, introduce the power of container technology without losing team members and breaking things. Druva has balanced the equation, and because out-of-the-box (OOTB) Docker cannot do it alone, they leveraged Calm.io to adopt Docker in an organic way.

Druva is no stranger to changes in their software development processes. What originally started as an on-premise solution for data protection, backup, governance, and availability has recently transformed into a cloud-based solution running on AWS EC2.

Not only did they survive a major transition from on-premise to cloud. They also are very familiar and aware of risk and compliance. As their most common use cases are in Government, Healthcare and Finance. Which means they are dealing with terabytes of secure data that has to be considered during every release.

With all these challenges it might seem that Druva is an unlikely candidate to be a Docker early adopter. But yet, they saw the benefits of containers to streamline their release process, and boost quality, and so they pushed forward, making a deliberate effort to user Docker right now.

Sponsorships Available

Sponsorships Available

Sponsorships Available

The Druva development team consists of 71 developers with more than 200 developer machines. Their stack is not terribly unique, the application is developed in Python with backends in AWS DynoDB, and S3. In their development environment they leverage virtualization on their local development machines via Proxmox.

Their operation is a little a typical instead of going all in cloud, with dev on through to production environments, they operate in a hybrid environment where dev/test/stage is on-premise, and production is in the cloud. The reason for this is “the speed of deploying to dev/QA was too slow, we had to wait almost a day to complete a release” says Faisal Puthuparackat a Principle Engineer at Druva and internal Docker facilitator.

For their releases they have been leveraging modern approaches. Currently their release processes is driven by Jenkins, and they are releasing applications as tarball images, leveraging Fabric (now transitioning to SaltStack) for orchestration. Their current setup is not old-school by any means. But it has it’s problems. Namely:a

1. Supporting the development of two separate products introduces a lot of variables.
2. Development environments are as varied as the number of developers. Need consistency.
3. Doing test builds is slow, and thus limiting the number of builds they can do a month.
4. There is a lot of change. Druva is growing extremely fast and they need a better way to handle the growth of the development team, and components in their growing application.

What Faisal and team identified was that all these challenges addressed by a Container driven pipeline. Where the application releases become full-stack deployments ( applications deployed as the entire stack including Libraries, Environment, System Configuration, and Code ) from a private registry and pre-built containers. But not only are they going to leverage Containers for their integration releases, they have gone ahead and added all their test automation into the containers as well.

As they made this transition Faisal realized that there are several areas where Docker OOTB and their current tool set was not going to offer all the functionality they needed.

1. Orchestration has been limited to individual machines. Docker swarm wasn’t production ready.
2. When working with many Docker containers, it is hard to get a high-level view of the entire container ecosystem across all 200 developer machines.
3. Container by container maintenance is time consuming.
4. Scale up and scale down of environments is not as easy as it seems.
5. Need an easier and better way to provision and de-provision containers from a private registry.

He had hit a wall until he discovered Calm.io. Once they deployed Calm.io for their on-premise development, QA and Staging environments, they reduced the time between QA/Dev cloud deploys from 1 day to 15 mins. Allowing them to dramatically increase the number of builds, and thus tests they are able to run before the end of a sprint. They have not changed the use of tarball deployments, that will come next states Faisal. The Dockeized version of the app injests the release tarball during the docker build process.

Calm.io was the oversight and high-level orchestration tool that Druva needed to take their Docker adoption to the next step, and accelerate it into production. As they grow with their container environment they are now able to ensure that not only are they moving at Docker speed they are able to support governance, change control, and ultimately a sustainable DevOps environment. Next on the docket for Druva is leveraging Calm.io to do production releases to AWS.

While many companies are playing with Docker, Druva intends to make it a permanent fixture in it’s modern delivery chain. And they took the additional step to acquire the 3rd party tools required to make Docker an end-to-end solution.

Druva shows us that existing large and growing development environments in a highly secure eco-system can build out modern delivery chains like the startups. Docker alone was not the answer, but the eco-system of supporting tools to make Docker more mature like Calm.io came to the rescue and put Druva’s development team in a great position to move from bi-weekly sprints to continuous delivery and deployment.