DEVOPS DEBATES: IMAGE-DRIVEN OR BUILD-DRIVEN DELIVERY

In the last 12 months, Docker and the containerization paradigm has challenged the foundation of some of the software delivery principles. People are resorting to things that were unheard of 18 months back and are now using them to successfully deliver software faster and cheaper. One such thing is the debate around build-driven delivery vs image-driven delivery.
Over the last few decades, software has been packaged and built by a build system and tagged with a number; testers aligned their testing to the tag as the entity being tested and promoted them until it reached production. The build number was one of the most important tag for anyone to communicate about the status of the software in the delivery pipeline.
For some time now—primarily due to Docker—several teams are moved to a methodology in which the image defines the version of a software. Every change in application program and deployment program will together create a new image, which is tagged and used as the version of the software to be launched for downstream use and finally into production.
The debate then is, which option is better?
Let me take a shot at this, and will invite your thoughts on this as well.

For builds-driven delivery:

  1. Builds helps software to be tagged irrespective of the target hardware and other deployment options. It bundles all dependencies to ensure the software works when deployed to the expectation. This provides the development team a good hand-off point to move on to the next set of work, or sprint.
  2. Builds are much smaller in size, as the build bundles only necessary software needed by the application; hence, keeping them aligned with every change will not be a costly storage proposition.
  3. Versioning of artifacts and bundling them at run time has given tools such as maven to build and link dynamically, collecting all dependencies from the cloud. This makes it easier to keep a thin build and further reduce the redundant data to be kept in each build.
  4. Build repositories have matured over the years to provide a very easy way to version and mark dependencies so deployment tools can find new versions and automatically upgrade environments as needed.

For images-driven delivery:

  1. Images takes the concept of build to the next level and ensures the variability in target hardware and deployment options are removed completely. It bundles the application as given in the build or built as part of the image creation and pushes the image as a build.
  2. Docker registries have started to compare and contrast themselves into a build repository by providing similar options for end users.
  3. The images-driven option provides a much better benefit of standardizing all your environments, removing the question,”It works in my environment; does it in yours?” If it works in the container in a developer’s laptop, it should work in production as well—everything is same, except for the size and number of resources.
  4. Images are much larger than builds, given that it has to now carry the system software and the application base software within the image. This option was unheard of earlier, but with container images coming down to megabytes, this is not such a big issue today. With layering sizes can be reduced much further as you start peeling the onion of dependencies. Take a look at this nicearticle by Brian on this topic.
I guess the choice depends on where your application is in its life cycle, the questions teams should really ask are:
a) Do we need to change too much to pick an option for an incremental benefit?
b) Do I have the issue of environmental differences?
c) Can I merge these options to get a hybrid solution going?
But for me the larger question is, Which option would you choose, if you were starting from scratch tomorrow? I would love to hear your thoughts.
Finally, irrespective of which way you lean, image-driven solutions is one of the best way to bring DevOps culture to a team: If the image works, the team has won; it doesn’t matter whether it was ops code or dev code!

Comments

Post a Comment

Popular posts from this blog

Agile and The Moving Train

Back into the Blogging mood after long years! The reason is simple, I did not have much to share than the mundane stuff that kept on running for the last few years. I am back because I am now beginning to implement agile development process for a large team and am discovering wonderful stuff as and when I plough through the details of the agile delivery model. There are a lot of anologies that comes to my mind and I will keep writing these as a beginner trying to unravel a new world. First is an anology that I draw to a moving train. In agile you make timeline constant but scope the welcome variable (which is exactly the opposite in Waterfall), this means how often you deliver to the outside world is constant, but what you deliver is what you play with. A moving traing has stations and their locations constant (where/when) and how many people you move across is a variable. When you start with this basic analogy, there are a lot of things you can draw and ensure various roles are unders...
Read more

The joy of the journey

The software industry in India has really taken a toll on the IT employees. There have been plenty who are talking about exhaustion , retirement and moving out of the industry after 15+ years of hard experience. These are some of the stalwarts, greats who have done well for the IT service industry. The key reason has been that they have put in long midnight hours to bring a new project, work on bring the the projects into control and just executing this cycle with different pace, complexity and size but the cycle has been the same. When you take a step back at these instances, it is very evident that the industry will very soon take the exhaustion path unless we device a mechanism to bring in the joy of the IT journey at everything we do in IT. I have found less and less people who enjoy what they do, and always have a reason why they do not like what they do. The key is 'What is the joy factor of the Indian IT industry?'. Improving this is hard both individually and collectiv...
Read more

HOW SHOULD MANAGEMENT ENGAGE DEVELOPERS?

It was in one of those meetings, a senior leaders from a large company told me, ” You know, when I was a team lead, I had such a good time interacting with the team – I knew exactly what they are working on, how they were working and how I could support them. And I knew exactly how I can make a difference in their life. Today, I have a much bigger organisation under me, but I don’t know exactly what those individual contributors are working on? and no clue on how I can make a small difference to them and hence multiply those small differences to affect change in the company.” This got me thinking. He was absolutely right, the higher you go, the less you know about the individual contributors, but you have more individual contributors under you! “The larger your ability to make a difference, the lesser visibility will you have to bring that difference. An irony of life!” But I believe, you can actually make a big difference to these individual contributors even when a large orga...
Read more