How to Contract a Software Developer

We are a small company developing custom software that typically implements some business critical function. Actual back-ends with lots of asynchronous transactional business workflows, mass-data processing, integration with other back-ends, machine-data and shop floor user interfaces.

We do not design or implement this software from scratch. We have tools and a solid software foundation and experience to analyze business processes, map them into software and eventually implement them. That’s what we bring to the party.

We do in general not do fixed-price projects. We do not do that because – in general – that simply does not make sense – not for us, not for our clients.

This post is on why asking for a fixed-price project is more often than not the wrong thing to ask for, for us as developer and for you as client. It is on why you should not want to contract a developer for a fixed price project and what you should do instead – to make life better for you as client and us as developer.


Normally you will read that the very first step of any software project is to develop an understanding of the actual business problem, its essential data relationships and what users will need to solve it using a software system.

And indeed, while there will be an initial problem description, it is not necessarily describing the problem to solve in terms that map easily to a technical solution approach. So you need to create a more technical and fundamental formulation of the business problem to solve as to create a foundation onto which the project can be planned and implemented.

However that is not the whole story. When you are at that point, you are already in the project. Another indispensable step that comes first is to build ground for common trust between client and developer.

Why would a client trust a software project that potentially evolves into a multi-million euro endeavor to a developer based on an exchange of design ideas and some vague planning?

Why would a software developer risk expensive litigation because of a misunderstanding of what a solution to a million-euro software project is supposed to deliver based on a design that turned out to be wishful thinking?

I believe there are three essential (moving) meta-milestones in any project:

Next: All the features and fixes you know are needed and of which the developer knows (or believes to know) how to do them right. Everything in Next can be done now.

Near: All those features that you believe could be done down the road, possibly relying on the Next, that you think would be really useful to have but you are not sure you are really willing to pay for all them just yet nor is your developer certain how long it will take and how well it will work.

Far: The vision of what could be done, if you had the Next and some of the Near, and maybe some cool idea and the right business framework. You would not know how to plan for it now, but sharing it provides orientation of where, eventually, we want to go.

These moving target meta-milestones define the grounds on which to repeatedly plan and commit. By agreeing on them, we build a common understanding on how we believe the project is to move forward – while committing to the next “realistic” fraction of it:

The Near defines the Next by showing you the boundary of what you feel sure about. The Far on the other hand guides the creation of the Neart and the vision to communicate when justifying the effort as a whole.

While working in the Next, the Near and the Far become clearer – ideally Near flows into Next and there is constantly food for work and success in the project.

Here is the deal however:

  • While agreeing on the Near and communicating the Far, you only contract on the Next.
  • While working on the Next, you fill it up again from the Near.
  • You make sure that splitting up, while not desirable, leaves no more burned ground than the current Next.

Practically Speaking

As potential project partners, developer and client should agree on a first set of a Near and Far. I tend to call them Phase 1 and Phase 2, as that is probably more expected. As the first thing to do however is to come up with an initial high-level design or even somewhat of a specification, that would exactly define the Next.

And that is what should be the first commitment.

The result of the specification will be an understanding of a refined Next, Near, and possibly an updated Far as well. The goal posts will have moved, and you can move forward into the next iteration: Actually implementing the Next.

Speaking in agile development terms: An iteration here is generally not a sprint, but more likely multiple sprints, depending on the size of the project and the planning horizon. You would nevertheless align budgeting and mid-term planning with sprint boundaries as to not interrupt work unnecessarily.

At any time, you make sure that work has been specified and documentation has been updated to the extent that work can be passed on if required.

As a developer, you know that everything is set and you do not have (unexpected) technical or documentation depths that will haunt you later on.

As a client you know that there is no unnecessary dependency that may mean that you lose control over your asset.

In particular this means:

  • Contracts do make sure that anything developed belongs to the client
  • If necessary, the client can continue development with a different team, bring in new developers, move development in-house, if that is desired.

The latter means that project organization tools and content, development and testing infrastructure is either already operated by the client, comes with the project, or can easily be re-created by the client.

It is naturally best, if development and testing is inherently contained with the project sources and mostly independent of other external or proprietary tools.

In order to maintain trust versus the project and in you as a developer, you should make sure to manage a well stuffed backlog for the Near so that continuity of the project is preserved.

Z2-environment Version 2.9 is Available

Finally, Version 2.9 is available for download and use. Version 2.9 comes with some useful improvements.

Please check out the wiki and online documentation.

Support for Java 15

Version 2.9 requires Java 11 and runs with Java up to Version 16 and supports a language level up to Java 15 based on the Eclipse Java Compiler ECJ 4.19 (#2088).

With Java 15, we have now finally multi-line text blocks, saving us some painful reformatting when needing markup or code blocks or long messages as string literals.

public void multilineStrings() {
	// Text blocks are kind of
	// nice for mark up, messages and code
	create extension pg_stat_statements;
	substring(pss.query,1,100) as query,
	pss.rows as totalRowCount,
	(pss.total_time / 1000) AS duration,
	((pss.total_time / 1000)/calls) as "avg"  
	from pg_stat_statements as pss 
	join pg_database as pd on pss.dbid=pd.oid 
	order by duration desc limit 20;

Check out the JDK 15 Documentation for more on Java 15.

Upgrade to Jetty 10.0.1

This version now embeds Jetty 10.0.1 as its Web container (#2090). Jetty 10 is the last version supporting the Jakarta EE 8 namespace and the first to support the Servlet 4.0 API.

NOTE: With the next upgrade (Version 2.10) we will move on to Jakarta 9 that is NOT backwards compatible with previous versions of the Jakarta EE or Java EE APIs. This is mainly because package names change from “javax.*” to “jakarta.*” throughout the EE APIs.

See also Understanding Jakarta EE 9.

Supporting JUnit 5 (a.k.a. JUnit Jupiter)

This is arguably the coolest new feature in Z2. Previously Z2 already included an extremely useful in-container testing feature z2 Unit that was built on JUnit 4. I described it in detail in In-system testing re-invented. This is so useful for integration testing of anything that may call itself a meaningful application that I could not imagine developing without it anymore.

Hence it was all the more painful that it took so long to support the JUnit 5 API. Compared to JUnit 4, JUnit 5 is not only completely different but also significantly more complex from the perspective of an extender. However, it is also architecturally cleaner and allows for more testing features and testing flexibilty.

The new implementation of #2036, called z2 Jupiter, now allows to run remote integration tests transparently to the client (IDE, ANT, Jenkins,… etc) without compromising on JUnit 5 features in your tests – even more so than z2Unit did.

package mytest;

import org.junit.jupiter.api.Test;


public class AZ2IntegratedUnitTest {

    public void someTestMethod() {  
        System.out.println("Hello World!");

I will described the implementation approach in another blog post. For now please check out How to Unit Test in Z2.


Check out the version page for more details. Go to download and getting started in five minutes or check out some samples.

Posted in z2

Software Design Part 3 – Working With Persistent Data

This is a follow-up on the post Software Design – The Big Picture (Intro) and Software-Design – Part 2: Structuring For Control Flow.

Imagine a world where there is no constraint on availability of computational power and memory. We would have software that could simply run forever and could design it in a way that all data it processes is indefinitely kept within its runtime memory. Would we call the data it manages persistent data? It will not get lost, right? That is in fact not what we generally refer to as persistent data.

Persistent data in the sense used here is data that is kept independently from the execution of any specific interpreting or modifying software and may be useful for a variety of different existing or yet to be designed applications. And that is where the trouble starts.

Generally speaking, we need to consider that the same data set is accessed from different execution environments at the same time, implying consistency and concurrency considerations.

Secondly in many cases, just as we want to have a modular software design we want our data to be up to serving such design.

Finally, we want an implementation pattern for data access that is easy to implement, easy to use for dependent code, and provides good control over the former two aspects.

Consistency and Concurrency

The cornerstone technique for consistent data access is transactional data access as implemented by your typical relational database management system (RDBMS). While there is some niche scenarios where this is not required, any implementation scenario where control flows spans an a-priori unknown scope of data access (which is generally true for modular, extensible applications) will rely on transactional data access for operational state management. Trying otherwise is pointless.

As laid out in the previous post (Notes on Working with Transactions), a transaction should typically span an “interaction”, be it a user interaction or a “step” in a background workflow execution. This is the span where your code will invoke data changing operations.

While transactional database access will guarantee that all or no changes of transaction will be applied, it does not necessarily guarantee consistent reading of data nor does it prevent concurrent changes of data. At times you need to make sure that some control flow has exclusive access to some portion of data. That is what (so-called pessimistic) locking is for. As the use of “pessimistic” suggests, there is also “optimistic” locking, which is beneficial only for certain scenarios however and hardly in the general case.

Modular Data

An intrinsic feature of the relational data model is that it allows for arbitrary relationships between tabular data for as long as you can make data types fit. In particular this means any given data model may be enhanced by adding related data. By modeling constraints, even new consistency rules may be added to an existing data model.

If your application structure is reflecting that same modularization, you would want to re-use data type definitions just the same, instead of re-implementing extended domain model types for every extension.

While the relational model is a natural fit here, object-relational mapping tools like JPA for Java make this a little less-obvious. It is possible but requires some care when crafting shared entity classes. I wrote about this in Modularization And Data Relationships.

We will not go into domain model design here. There is an abundance of literature on that and I wouldn’t know how to add to that. See e.g. the classics Domain Driven Design, and The Data Model Resource Book.

In any case, extensibility is a key aspect of data modeling and data model implementation. If you are not prepared for the future, you will not be ready for the present!

Designing Repositories, Implementing Data Access

Given a data model, say, already modeled via some database schema, you need to represent data structures and access methods to those parts of the application that need to read and write data.

  • Data types specified using your programming language of choice that represent to the database schema – the domain API.
  • And a Repository API:
    • Data access methods for reading entities of your data model into memory (typically by id and paged for display etc.)
    • Data access methods for writing changes of entities to the database.

I strongly advocate to separate read access to data from write access and to have more or less completely behavior-free data type implementations. The repository API should very much follow a Command-Query-Responsibility-Segregation (CQRS) approach with complex update objects.

That is:

  • Design read methods matching your query needs.
  • Have one or very few write methods per updatable domain entity type that takes a structured update data object, describing possible updates.

This is not an object oriented design. But, let’s face it: Data modeling does not fit object orientation very well. Here are some benefits of this design:

  1. When mixing structure with update behavior in the implementation of your data model, you easily end up with a spread out update logic that has unclear validation times and is not very instructive on where to find the right update logic.
    In contrast, going for an update object forces you to design a document that explains what is the possible scope of update plus it makes it easy to standardize complex updates (e.g. of nested collections) and has a very natural point in time to apply validatation logic.
  2. Adding business level behavior to entity implementations is a bad idea as it tends to ignore the possibility that there may be many future extensions with modified or extended behavior for the same data.
    In contrast, strictly separating these two aspects makes sure we do not force any competition on entity model interfaces by extensions of business functions working on the data.
  3. A dedicated update data “document” structure is light on your implementation as it is substitutes for possibly many small update methods and is highly efficient in terms coding effort as it can be re-used in service interfaces and user interface models.

I wrote about this in the past (Java Data API Design Revisited). This is similar to the concept of Service Data Objects (I was representing SAP in the SDO expert group at the time). An idea that is even more effective within the application than it is outside: Use a generic to use update descriptor that can be used on many layers to describe modifications on a domain model:


Describing more implementation details here is beyond the scope of this blog. But, if there is one thing to take from this post:

Carefully crafting domain APIs and repositories to not only effectively represent the data model but also provide a simple and widely usable data API that is exensible and instructive is probably the best implementation-related investment possible.

Software-Design – Part 2: Structuring For Control Flow

This is a follow-up on the post Software Design – The Big Picture (Intro).

Processing a request to do something, be it a user interaction, a remote service call, or a local scheduler invocation always require the same “logical” sequence of steps:

  • Check whether the request can be granted execution (permission checking)
  • Translate the external request into internal data structures and validate input
  • Log the request
  • Call one or more repositories and/or local services to retrieve data and perform computations, progress some workflow, and update some data.

Simple enough. In reality however things get messy quickly. That is why in this post we describe a simple but effective and many-times proven abstraction that help us breaking up complexities in code by layers of responsibilities:

The separation of code into three layers that are orderd in terms of control flow simplify dependencies and make the implementation simple to understand.


A Facade is a consumer-specific presentation of a function that is implemented via one or more internal services and data subsystems. Facades is the natural place to check on permissions and to do any kind of logging that describes the interaction (as in audit logging). Facades are the “adapter” between internal business logic and data definitions and the external interface (e.g. service or user interface).


It may well be that your code has a definition of a facade. For example, if you use a Model-View-Controller structure, a controller class would be part of the facade.

Essentially any kind of application needs some understanding and access to shared business data. This is for many reasons what should be modeled first when starting a development effort as

Data lasts longer than function, and function lasts longer than interface.

Investing in an effective and robust data model is much better invested money and time than polishing the last details of your user interface. We define all domain data type definition as well as access methods (query and update) to form the Repository layer.


We want our application to actually do something useful besides reading and updating data. What we really want is to solve a business problem and that means to implement some business logic that humans cannot or should not perform by hand.

Services implement business functions over the domain data model beyond data access and modification. Services are modeled in terms of a function domain, not a presentation or interaction and so services are the place to implement logic that is not specific to a facade but instead inherent to the business domain and may be re-used for other facades.

While facade changes are driven by external presentation requirements, while changes are driven by changes in the business workflows, which leads to the inverse formulation of what we had above:

Facades change more often than services and services change more often than the domain data model.


By introducing and sticking to an implementation pattern, which is what we are discussing here, we make the structure of code more readable, more maintainable, and more extensible because concepts repeat.

Note that the layering has very little to do with modularization or even deployment and distribution of microservices or even hexagonal architecture and the likes. We are still talking code structuring – micro-architecture if you will. The motivation and tasks in modularization are different and require deep solution specific abstraction to be done well:

That is, we are still on a rather fine-granular level. That will change when we discuss modularization.

Software Design – The Big Picture (Intro)

Most of my blog posts on software matters are about very specific, almost niche, subjects. I wanted to summarize a big picture however for a long time – some of the most important aspects at least.

Starting from a big picture is important – and slightly dangerous. Important because it helps avoid jumping to conclusions too early. Dangerous because we need to avoid getting trapped in astronaut diagram architecture. Let’s dive in and start with some high level but fundamental aspects of pretty much any non-trivial software system:

Structuring for Control Flow

Any kind of software system will have to process interactions (or requests) from users, or other systems, or from itself. Structuring for control flow is about how to structure your code as to most “usefully” check permissions, where to best implement data types of a given interface or protocol, where to implement the actual domain logic and how to update persistent state. This sounds bigger as it is and it can be nicely explained without going into implementation details.

Working with Persistent Data

While there are certainly applications that derive their value purely from solving some algorithmic problem, the vast majority of software systems we get in touch only exist to help us work with data (state) that represents some aspect of our reality and will live much longer that any specific system we use to access it. That is why data or domain modeling is hugely important and there is excellent literature abundantly available. So we will only look into how to be smart about accessing and updating persistent data.


Modularization is one, if not the key method for controlling complexity in software design. It is a mystery to me why this is – I think – absurdly underrepresented in publications. My pet subject.


Often abused as a mechanism of modularization, but in fact, a completely different subject. At some point you need to bring your code to execution. If you need to or want to run a distributed system, what are good reasons, not so good reason, and actually nonsense reason for accepting remote boundaries.

With the next posts we will look at each aspect in more details. Stay tuned!

The Bulletin Board Pattern

A rather common problem of software system design is to organize background work in a robust, reliable, and scalable way. For example incoming queries need to be processed, messages sent, or remote systems need to be called. Single work tasks emerge but are not to be done at the time and place they are generated, but instead work work is to performed in the background and asynchronously – possibly using a separate infrastructure from where it originated.

work rushing towards processing

Messaging for Work Distribution

Suitable orchestration of distributed work is not completely trivial though and there is a number of pitfalls. Driven to non-functional requirements such as reliability and robustness and asynchronicity, people often tend to messaging service systems, such as Apache Active MQ, as a convenient mechanism to announce work to the system and to distribute work to processing elements of the system.

However, message oriented middlewares do inherently not have an understanding of a message’s meaning. In the human analogy, the transmission of a message corresponds to the delivery of a letter via the mail service. Apart from quality of service aspects such as express delivery or the requirement to produce a return receipt the delivery is completely oblivious with respect to the letter’s content. Once the letter is on its way it has no relationship to other pending letters and once delivery is completed, the mail service is out of the picture and whatever must happen next is with the receiver.

Hence, using an approach like this for work assignment will inherently be ignorant of work details, pending work, as well as pretty much any particular state the designated processor is in.

How about Bulletin Boards?

Instead consider a bulletin board that holds a table of pending tasks. Instead of receiving isolated work tasks, an interested task processor may use a rule set to select one or multiple tasks depending on its state as well as the overall systems current workload (as seen on the bulletin board).

Considering the bulletin board is a design element of the solution, we may decide to note down highly specific business attributes with the tasks to allow sophisticated task selection rules. For example a worker may process similar tasks much more efficiently than random sequences of tasks. Or business rules may imply a time of day specific prioritization based related business data such as a customer status.

In other words: Messaging is stateless. A bulletin board can be arbitrarily stateful

But How?

So it seems there are some advantages in using a bulletin board and a “pick your work” approach rather than a generic work assignment. But how are we going to build that?

The correct answer is of course to use a relational database system (RDBMS). The whole setup asks for it! In its simplest incarnation, the bulletin board in its most simple incarnation just a database table that holds all pending tasks, some attributes we need for management and whatever business data we deem useful for smart work organization. How about reliability and robustness? After all we just decided to build ourselves.

Whatever RDBMS you are using, most likely there will be an approach for backup/restore and replication/fail-over available. Typically we will want to have a recovery feature: If there was an outage, the application crashed etc. we will want the application to retry whatever was running last. That is, tasks should be picked up “at least once”, possibly multiple times (and consequently task execution should be idempotent).

A simple recovery implementation would work like this: When picking one or a set of tasks the processor leaves a designation that identifies it with the “checked out” task. It does so again when finishing a task. In a recovery situation, these markers can be used by the processor to discover any previously started but not yet finished work to pick up and process first. It’s not complex, and in contrast to many other “advanced” approaches, it is highly transparent and simple to work with when things go bad.


Getting work done is the reason to built software systems. Knowing and organizing its work is a central aspect of its design and should not be delegated to external tools as if as an afterthough but should and can easily be implemented as a fundamental built-in feature.


Bad Software Architecture Doesn’t Matter When It Doesn’t Matter…

Lately ran into, a paper published in 1970. After 50 years, anybody in the field can perfectly relate to the problems described. Even the terminology has hardly changed. While we may have a slightly better grip on a pragmatic development process – the difference in sophistication is not really impressive while we are suffering from the very same problems today: Poor decision making, too little upfront analysis and design.

Yet there is a whole industry of people selling simple technology driven approaches to problems that are at most partially technological but first and foremost design questions.

As a developer one (unfortunately) rarely gets the chance of designing and being responsible for a system that grows to a large and vibrant organism. And so actually validated design experience is scarce out there.

Fortunately, singular and small solution can typically made to work anyway somehow, even if they are built with a mix of containerized node.js implemented microservices to store an order record in a non-transactional no-SQL database.

I just made a resolution to write about something positive in my next post. Stay healthy!

Z2-environment Version 2.8 is Available

Finally, version 2.8 is available for download and use. Version 2.8 comes with some useful improvements.

Please check out the wiki and online documentation.

Support for Java 13

Version 2.8 requires Java 9 and runs with Java up to Version 13 and supports a language level up to Java 13 based on the Eclipse Java Compiler ECJ 4.14 (#2035).

Upgraded to Jetty 9.4.24

While that was rather a necessity to run on Java 13, it was also kind of nice to be up-to-date again (#2052)

Follow HEAD!

Previously it was kind of cumbersome to change Git Component Repo declarations when working with feature branches, or to make a connected system switch branches when implementing a system local repo.

At this point, I probably lost you. Anyway, as z2 is self-serving its code and configuration, it would be really cool, if switching branches would be just that: Switching branches and (of course) synchronizing z2. And that is true now.

A Git Component Repository declaration may now use “HEAD” as a reference:

In that case, whatever is the current branch of the repo: Z2 will follow.

Remote Management Goodies

Z2 exposes metrics and basic operations via JMX. Via JMX or via the simple admin user interface, you can check on runtime health and trigger synchronization or reload of worker processes for example. Some things were – in practice – still rather user unfriendly:

  • Synchronizing a remote installation from the command line;
  • Accessing the main log remotely.

There is now a simple to use command line integrated with Z2 that can be used to do just that: Trigger some JMX implemented function and stream back the log. Or just simply continuously stream the log to a remote console.

Remote log streaming is also available from the admin user interface:


Check out the version page for more details. Go to download and getting started in five minutes or check out some samples.

Posted in z2

A Model for Distributed System-Centric Development

It’s been a while and fall has been very busy. I am working on z2 version 2.8 which will bring some very nice remote management additions to simplify managing a distributed application setup.That was the motivation behind this post.

This post is about a deployment approach for distributed software systems that is particularly useful for maintenance and debugging.

But let‘s start from the beginning – let‘s start from the development process.

Getting Started

The basic model of any but the most trivial software development is based on checking out code and configuration from some remotely managed version control system (or Software Configuration Management system, SCM) to a local file system, updating it as needed and testing it on a local execution environment:

At least for the kind of application I care about, various versions, for development, testing, and productive use are stored in version control. In whatever way, be it build and deploy or pull, the different execution environments get updated from changes in the shared SCM. Tagging and branching is used to make sure that latest changes are separated from released changes. Schematically, the real situation is more like this:

There are good reasons we want to have permanent deployments for testing and staging: In large and complex environment a pre-production staging system may consist of a complex distributed setup that integrates with surrounding legacy or mocked third-party systems and have corresponding configurations. In order to collaboratively test workflows, check system configurations, and test with historic data, it is not only convenient but really natural and to have a named installation to turn to. We call that a test system. But then:

How do you collaboratively debug and hotfix a distributed test system?

For compile-package-deployment technologies, you could setup a build pipeline and a distributed deployment mechanism that allows you to push changes you applied locally on your pc to the test system installation. But that would only be you. In order to share and collaborate with other developers on the test system, you need some collaborative change tracking. In other words, you should use an SCM for that.

Better yet, you should have an SCM as an integral part of the test system!

Using an SCM as Integral Part of the System

Here is one approach like that. We are assuming that our test system has a mechanism to either pull changes from an SCM or there is a custom build and deploy pipeline to update the test system from a named branch. Using the z2-Environment, we strongly prefer a pull approach – due to its inherently better robustness.

From a test system‘s perspective we would see this:

Here „test-system“ is the branch defining the current code and configuration of the test system deployment. We simply assume there is a master development branch and a release branch that is still in testing.

So, any push to „test-system“ and a following „pull“ by the test system leads to a consistently tracked system update.

Let‘s assume we are using a distributed version control system (DVCS) like Git. In that case, there is not only an SCM centrally and on the test system, but your development environment has just as capable an SCM. We are going to make use of that.

Overall we are here now:

What we added in this picture is a remote reference to the test-system branch of the test system’s SCM from our local development SCM. That will be important for the workflows we discuss next.

The essence of our approach is that a DVCS like Git provides us a common versioning graph spanning multiple repositories.

Example Workflows

Let‘s play through two main workflows:

  • Consistent and team-enabled update of the test system without polluting the main code line
  • Extracting fix commits from test commits and consolidating the test system

Assume we are in the following situation: In our initial setup, we have a main code line (master) and a release branch. Both have been pushed to our central repository (origin). The test system is supposed to run the release branch but received one extra commit (e.g. for configuration). We omitted the master branch from the test-system repository for clarity. In our development repository (local), we have the master branch, the release branch as well as the test-system branch. The latter two from different remotes respectively. We have remote branches origin/master, origin/release, test-system/test-system to reflect that. We will however not show those here unless that adds information:

In oder to test changes on the test system, we develop locally, push to the test system repo and have the test system be updated from there there. None of that affects the origin repository. Let‘s say we need two rounds:

We are done testing our change with the test system. We want to have the same change in the release and eventually in the master branch.

The most straightforward way of getting there would be to merge the changes back into release and then into master. We did not write particularly helpful commit messages during testing however. For the history of the release and the development branch we prefer some better commit log content. That is why we are squash-merging the test commits the release branch and merge the resulting good commit into release.

After that we can push the release branch and master changes to origin:

While this leads to a clean history centrally, it puts our test system into an unfortunate state. The downside of a squash-merge is that there is no relationship between the resulting commit and the originating history anymore. If we would now merge the „brown“ commit into the test-system branch we would most likely end up with merge conflicts. That may still be the best way forward as it gets you a consistent relationship with the release branch and includes testing information.

At times however, we may want to „reset“ the test-system into a clean state again. In that case, we can do something that we would not allow on the origin repository: Overwrite the test-system history with a new, clean history, starting at where we left off initially. That is, we reset the test-system branch, merge the release commit, and finally force push the new history.

Now after this, the test system has a clean history that shows a history as we would have it when updating with release branch updates normally. None of what we did had any impact on the origin repository until we decided for meaningful changes.


What looked rather complicated was actually not more then equipping a runtime environment with its own change history and using some ordinary Git versioning „trickery“ to walk through some code and configuration maintenance scenario. We turned an execution environment into a long-living system with a configuration history.

The crucial pre-requisite for any such scenario is the ability of the runtime environment to be updated automatically and easily from a defining configuration repository implemented over Git or a similar DVCS.

A capability that the z2-environment has. With version 2.8 we intend to introduce much better support for distributed update scenarios.

Docker is essentially a Linux Installation Format

When you are designing a software system and you start worrying about how to get it installed on a machine to run, it is time to think about places where to put your code, configuration, supporting resource.

In reality however, you will have thought about that already during development as, I presume, you ran and tested your software. You did just not call it installation.

And when you came up with a concept to keep the various artifacts that are required of your solution in a sound place – you most likely made sure that there is a cohesive whole: In most cases a folder structure that holds everything needed to run, configure, customize your software.

Wouldn’t it be nice if that was what installation was all about: Regardless of your hosting operating system, installation of your software would mean to unpack/copy/pull a folder structure that provides your software, adapt the configuration a little maybe and be done?

Application in folder

That of course is not all there is to it. In many cases you need other supplementary software. Third-party libraries that come with the operating system. Or a database system that should run on the same host OS. It is here that we find crucially different philosophies of re-use depending on what technology you use.

If you are Java developer and your dependencies are Java libraries, you will typically bring them all with your application. In that case, if you even include the Java Runtime, you are pretty much there already.

JAVA application in folder

If you are developing application on the LAMP stack, to go for the other extreme, you typically depend strongly on third party software packages that are (typically again) installed using the OS defined package manager. That is, you blend in with the OS way of installing software.

LAMP application “in” Linux

Going back to the Java case and one step further: Suppose you come up with an extension model to your solution. Additional modules that can deployed with your application. They would need configuration and to have that and be a good citizen, they should adhere to your installation layout.

That is exactly what Linux does. If you want to be a good citizen on your Linux distribution you use the software packaging style of your target distribution and install in /opt/ keep your data in /var/lib, and your configuration in /etc.

But should you? Think about it: This is probably not the structure you use during development as you want to have the freedom to use different versions and variations without switching the OS. More dramatically, if you want to support multiple Operating System distributions, styles of configuration and scripts may vary. In fact, unlike what the drawing of packages installed above suggests, the artifacts of packages are spread out in the file system structure – in sometimes distribution specific ways.

Everything can get messy easily.

Things get messy and complicated anyway, because in that approach you rely on 3rd party software packages that are not distributed with the application but are expected to be provided via the distribution.

From an end user perspective, using today’s Linux package managers is great. From a developer perspective it is the classical dependency hell:

Every to-be-supported distribution and version will require a different dependency graph to be qualified for your solution!

Application with dependencies in Linux

Docker as a Solution Container

Many people look at Docker from the perspective of virtualization – with a focus on isolation of runtimes. But it is actually the opposite. Docker is a means to share operating system managed resources for applications that are packaged packaged with their dependencies in a distribution independent way. From the packaged application’s perspective, its execution environment “looks” like a reduced installation of a Linux distribution, that, by means of building Docker files, was completely defined at development time:

Dockerized Applications on Linux

By providing means to map shared resources like ports from the Hosting OS to Docker containers, Docker even allows to “trick” internal configuration (e.g. of the database port) into a shared execution.

Looking at it from Higher

If we take one step back again, what we actually see is a way of deploying a statically linked solution that includes everything except for the actual OS kernel. That is great and it solves the dependency problems noted above at the expense of somewhat higher resource consumption.

However, if there was a better standardized Linux base layout and better defined ways of including rather than referencing libraries and well defined “extension points”, e. g. if the Apache Web Server could discover Web Applications in “Application Folders”, if databases would discover database schemas and organize storage within the deployment, if port mapping was a deployment descriptor feature and so on … we would need none of it and have much more flexibility. If we had it on the level of the OS, we would have a huge eco-system opportunity.

It is this extensibility problem that any application server environment needs to solve as well – but never does (see for example Modularization is more than cutting it into pieces, Extend me Maybe, and Dependency Management for Modular Applications)


Creating a Docker image is not as simple as building a folder hierarchy, however, in essence, Docker provides a way to have our own Solution Layout on a Linux system while having strong control over third-party dependencies and still be easily installable and runnable on a variety of hosting environments. It is a cross-platform installation medium.

That is great. But it is really the result of wrong turns in the past. Docker found a dry spot in a swamp.

If it was safely possible to reliably contain required dependencies and configuration – a simple folder based software installation mechanism would have saved the world a lot of trouble.