close
LOW-CODE
PREFABS
SOLUTIONS
EVALUATE

Wired for experience®

[vc_row][vc_column][vc_column_text]Are we bracing ourselves for a world where we are going to see developers, testers, and other stakeholders in a development process working on their own sandbox containers?  The answer seems to be a resounding YES.  Let’s jump into the concept of container-driven development (CDD) - I think I just found a new acronym that’s going to be famous, in a world that’s begging for more acronyms :).   Or do you think DDD - Docker Driven Development, sounds better than CDD? (;-) Anyways, let's jump in.

In an application life-cycle process, let's take the 3 biggest stages - Development, Testing, and Production.  This post is going to focus on how Docker containers can play an active role in each of these life-cycle stages and benefits that can be derived from them?

Note, I am going to make assumptions (like just 3 life-cycle stages) to keep this post short and concise, but an enterprise is free to extrapolate and devise better ways of doing the same.

Develop in a container
Consider a scenario where every developer builds his application inside a container, which is provisioned exclusively for the project being developed.  These Docker-based containers are extremely lightweight.  They can be instantly provisioned in a developer laptop or an enterprise server infrastructure that can be accessed remotely through console utilities.  These development containers will be based on a Docker image that can contain all the relevant utilities for a developer.  Docker image itself can be stored in a Docker Registry.  These containers, based on the Docker image, can be provisioned in a matter of seconds. For example, if a new developer joins a team, he can provision a container instantly with all the utilities (like Eclipse IDE) pre-installed.  And finally, after the developer gets his app to work, he can push the image of the app build to the registry.  A docker container for a developer can look like how it is.

A container has 2 primary configurations to it.

  1. The hardware configuration is a factor of 3 parameters - CPU, memory, and disk.  A sample configuration of Dev, Test, and Production containers.
  2. The software stack is contained in the container.  In this case, from Fig-1, you see that the Dev-Container has Eclipse, Java, and Tomcat as a part of it.  There is also a dedicated DB container that is used by the development team that contains MySQL as a part of the container.

Also note that the utilities that need modifications to their configurations like the DB settings, utilities for monitoring, and log files need not be a part of the container necessarily.  They can be configured when the same container is provisioned in different release stages.

What are the benefits of using containers during development?

 Test in a container
Once the app-build (See App v1.1 in Fig 1 & 3) image is pushed into the registry by the developer, it indicates that the build is ready to be tested.  In pre-container days, the tester would set up a new physical machine or a VM instance, install the requisite software, and then deploy the app.  It never worked the first time.  The developer just says “It worked for me”.  All these kinds of excuses are going to be a thing of the past, now that the containers have emerged.  In my previous post on Docker, one of the benefits I highlighted was “Guaranteed Reproduce-ability”. That means, by packaging your ap­pli­ca­tions into containers you can be sure that they will run as it did in a development environment, wherever they are deployed. In summary, there is a guarantee of reproducing the same behavior wherever it is executed.  Hence when a Tester/QA provisions a container based on the app-build image, it's guaranteed to work as it did for the developer.
QA can provision individual containers for themselves to focus on various aspects of the app like performance etc or all individual QA members can work on just one provisioned test container and focus on a particular area/feature of the app.
QA can find bugs in the app that can be reported back to the development in no time and this process can speed up the overall delivery process, with a little automation. In fact, consumer-facing services/apps like Amazon do multiple releases in a very short span of time (an interval of one to few days) using continuous delivery processes and containers are going to make that even more faster.  The idea of having a 1:1 mapping between the app being developed and the container also speeds up the delivery process with a lot more clarity, since now the deployment of the app is nothing but simply provisioning a container.
At this stage of the app lifecycle, the testing containers are provisioned and the lifecycle is visually represented.

What are the benefits of using containers during testing?

 Deploy in a container
Once the app build has passed the QA, it’s ready to be deployed into the production environment.  All that needs to be done is to provision a new production container (bigger size as given in Fig-2) and it's all set.  The guaranteed reproduce-ability will make sure that the app deploys and works as effectively as it did in the dev and testing environments.  There are few more steps like migrations of DB, services, etc but that looks like a topic of another blog post.
The instant provisioning and de-provisioning of containers offer tremendous flexibility to update to newer app versions with rolling upgrades or blue-green deployment.  The lightweight nature of the container also makes the localized error detection and fixing extremely easy.  All that needs to be done is to image the production container and move it into a debugging environment for a quick inspection.  An app in a container has also added fuel to the new MicroServices based app architecture, where independent modules are deployed in separate containers and are scaled independently.  The commoditization of hardware and container-based PaaS platforms offers tremendous benefits to instantly scale the application.  Check out my previous blog for more details on localized error detection, horizontal scalability, and lightweight containers.

The complete app life cycle after the app is deployed into production should something like this

What are the benefits of using containers for the production phase? 

So, What next?
It all seems so easy, isn't it? Not really.  There are a lot of unresolved issues during this app delivery process that is being/yet to be addressed.  Some of them include...

 How can you solve this? Are there any tools that can ease the task for you? I would suggest you take a look at WaveMaker's case study on "How WaveMaker Got Faster, Better, More Agile with Docker".  It also touches on the general benefits of Docker and issues of management complexity.[/vc_column_text][/vc_column][/vc_row]

Over the last year and a half, if there is one thing that the world of IT, DevOps & Cloud would not have missed discussing about, that would be Docker.  Docker is an app containerization technology that was developed by the erstwhile PaaS vendor DotCloud.  In fact, DotCloud was so enamored about the discovery that they remodeled their entire business strategy around Docker, renamed themselves Docker, and sold off their PaaS business.  And boy were they right!!!  Docker is nothing short of an epidemic now and literally every company with any kind of interest in the world of IT, DevOps & Cloud have embraced it with open arms and it includes Google, Microsoft, Amazon, VMWare, and more.

In this blog post, I will take you through those points that throw light on why Docker indeed has created so much buzz and how a Docker architected platform is superior, offering tremendous cost and performance benefits to the end-user, over traditional cloud platforms using hypervisor-based virtualization.

I am not going to explain “What is Docker” here.  There are a lot of articles on the web to explain that in more detail.  In fact, docker has an "Understanding Docker" section that does the job pretty nicely.  This post is just going to answer the question “Why a Docker architected PaaS platform is more superior?”

 

More bang for the buck:
Docker containers are lightweight compared to hypervisor-based VMs.  They don’t have the concept of a guest OS for every virtual machine(VM) that is created and shares the OS resources.  This means that more containers (2-3 times more) can be packed into the same host machine compared to packing VMs.

This higher container density aspect has a tremendous impact on the pricing front and offers the user more bang for the buck.  In fact, in WaveMaker, we have achieved almost 80% savings on operational costs of wavemaker online by using Docker architected WaveMaker Cloud platform on top of AWS.   I have to add, however, that the savings also includes benefits from WaveMaker Cloud’s additional optimizations on top of Docker containers.  But how is it possible to achieve so many savings? Let me try to explain that with an example.
Every time you provision a new virtual machine instance on EC2 you'll need to pay for it. Imagine 1500 users are simultaneously logged onto wavemaker online and that would mean I need to have around 1500 EC2 instances provisioned.  That is a tremendous waste of resources, especially if the application is light.  But with containerization, we provide a container for every logged-in user and a lot of containers can be packed inside a single EC2 instance giving us this cost-benefit.

Easy updates to higher app versions:
With the lightweight Docker containers, release management of applications especially upgrading to newer app versions has changed.  App version upgrades using old school approaches are not possible without server downtime and hence business continuity is lost.
With containers, a newer version of the app is provisioned in separate containers alongside the containers containing the current version of the app.  Once the new version of the app has stabilized, the older version is phased out and its container de-provisioned.  This approach is called the Rolling Upgrades.  Rolling Upgrades would not be possible with such ease if not for Docker images (see Fig 2), a concept of snapshotting the container with the application and its dependencies.

Faster start-up times for horizontal scalability:
Lightweight Docker containers can be provisioned in a matter of milliseconds compared to a few minutes that are needed to provision a hypervisor VM instance.  This is because Docker containers use a layered approach to the mounting file system.  So instead of having to make full copies of whatever files comprise a container, Docker references back to existing files in a read-only layer,

This commoditization and instant availability of hardware resources have brought back the idea of horizontal scalability (see Fig 4) into focus again, where a new container can be provisioned instantly as the app load increases.  This on-demand scalability is achieved in style and forever will change the way applications are architected for scalability.

Faster app delivery through continuous deployment:
Docker images are a way to snapshot the app and all its dependencies.  Images are templates based on which containers are provisioned.  These images are extremely lightweight and can be easily pushed to different app life cycle stages like development, testing, and production (See Fig 5).  This facility along with the guaranteed reproduce-ability (explained in the next section) is a huge deal for release management because significant time goes towards dependency resolution in traditional development approaches.

Guaranteed re­pro­duce-abil­i­ty:
A typical scenario in enterprise systems is to have scripts to deploy apps to a server.  However, the script executions will vary across different environments that include parameters like time, hardware, software versions, etc. But by packaging your ap­pli­ca­tions into containers you can be sure that they will run as tested wherever they are deployed. In summary, there is a guarantee of reproducing the same behavior wherever it is executed.

Enforces certified software usage:
Docker registries (see Fig 6) are components that hold Docker images. These are public or private stores from which you can upload or download images. The public Docker registry is called Docker Hub. Enterprise IT teams have the control to make available only IT-certified software components (as of Docker images) through these registries.  This enforces certified software use across the organization.

Better error detection and recovery:
Isolated containers running individual apps also offer a targeted error detection and correction, without affecting other parts of the application.  This becomes especially valuable considering that the lightweight containers offer you quicker error recovery options.
Consider that container C1 is up and running with image I1.  A new version of the image I2 is created and C1 is provisioned again.  However, due to an error that got introduced into the system, the app is down.  Now the user can quickly snapshot the current state of the container that has the error and create a new image, say I3.  Now C1 is re-provisioned with image I1, which used to work correctly before.  I3 is sent across to the development team with all the logs and other details to be examined for issues and corrective measures.  This is amazing since the developer has a snapshot of the problem from a live environment, allowing faster debugging of the issue.

With containerization providing a wide array of benefits covering cost, effort, and time, it is just a matter of time that cloud platform vendors are going to adopt containerization as the default architectural style.

WaveMaker recently released its PaaS software - WaveMaker Cloud - which is architected using Docker containerization technology.  If you like to know more about the newly released product contact us or request a demo at wavemaker.