EngineerBetter CTO: the logical truth about software 'packaging'

This is a guest post written for the Computer Weekly Open Source Insider blog by Daniel Jones in his capacity as CTO of EngineerBetter — the organisation is a member of the Cloud Foundry Foundation is UK-based and specialises in Cloud Foundry, BOSH and concourse.

NOTE: BOSH is an open source project which offers a tool chain for release engineering, deployment & life-cycle management of large scale distributed services. Concourse is an open source pipeline based CI system that focuses on simplicity, usability and reproducibility.

Jones writes as follows…

Software that is well-packaged requires a lower cognitive load of the engineers using it, allowing them to focus on solving business problems.

If a service has only a single responsibility then we have very few things to remember about it. Single-purpose tools are more efficient, too. Although we can make dual-necked musical instruments that combine a guitar and a bass, you can’t play both necks at the same time, but we do still have to carry the weight of both even if you only need to use one.

Multiple modes are dangerous

Software that can do many things requires us to remember more about its capabilities and its state. This is the reason that interfaces with multiple modes are dangerous in critical applications – plane crashes have been caused by one button that does different things depending on the state of the aircraft.

Humans prefer things that always work the same way. How many times have you failed to log into a system because you accidentally had CAPS lock on? 

Software with a single responsibility can be reused more effectively and by defining well-thought-out boundaries with clear interfaces it can be changed and iterated upon with minimal impact on other elements of the system.

Packaging principles

Way back in 1995, long before microservices were the latest craze, Robert C. Martin outlined a set of packaging principles that outline how to achieve this reusability and independence: if you can’t re-use them together, they shouldn’t live together; things that change together live together; things that are used together live together.

These principles combined with a platform that can offer self-service zero-downtime deployments allow engineers to continuously deliver business value in discrete reusable chunks. Being able to pick from a catalogue of stable and well-defined components enables agility – imagine if architects had to build every house fitting from scratch instead of picking them from a catalogue.

Any ‘unit of currency’ in software engineering benefits from having a single concern that is separate from those of its peers: this enables them to evolve independently and so change frequently.

Cloud Foundry’s buildpacks

Logically then this discussion brings us to Cloud Foundry’s buildpacks.

These are a good example of a clear separation of concerns: you provide the app code and the platform provides the operating system, base filesystem and language runtime.

This separation of concerns allows app code to have a ‘change cadence’ independent of the underlying layers, meaning kernel patches can happen underneath deployed applications.

Technologies such as Docker have blended these responsibilities, causing developers to need to care about what operating system and native libraries are available to their applications – after years of the industry striving for more abstraction and increased decoupling!