The reason I've put up with Java's deficiencies so long (ok, now with Lambda's it is finally starting to become a real language) is that I truly believe in the 'Write once, run anywhere' mantra. I've never understood why you want to write software that is not reusable and thus portable. Java achieved its portability by creating an abstract API for the interaction with the host Operating System (OS). I am duly impressed with Sun's engineers of how close they got to this goal, the Java VM is amazing piece of technology.
However, in practice, writing portable software still required effort from the developer. Despite the abstractions (alas, if only they had stayed close to POSIX), there are many subtle, and some not so subtle differences, that must be handled by the developer. Just like the differences in the configuration of an OS or the way its file system is used (i.e. hard coded path names).
The dreaded 'But it works for me!' frustration drove the idea of virtualization, where the software runs on a standard (Linux) OS that is virtualized on each developer's machine, which is then bitwise identical in test & production. The cost of this model was that it required schlepping around large images of many Gigabytes whenever the tiniest detail changed. Docker is, however, removing this disadvantage by making it very efficient to create, manage, and deploy these custom images.
So it looks like that the majority of Java applications in the future will run on Linux even if they run on MacOS or Windows, voiding the unique selling point of Java: portability. From now on, Java will be on par with every other language in the world regarding portability.
So what is left?
Java's greatest asset is that it allows you develop very large applications with sizable teams and stay sane. Though its type safety and long name feel cumbersome for small applications it becomes a necessity when the code base grows, which it inevitably will for any successful product. Type safety gives you confidence that all the different parts are actually compatible; the long names prevent conflicts. Even more important, it gives you navigability in the IDE, crucial when you maintain a large code base. This is of course exactly the area where OSGi provides it benefits: extending the type system with private Java namespaces, a time dimension (semantic versioning), dependency model, and into the runtime. There is no competitor on the horizon here.
So though Java/OSGi seems still have some unique selling points, it is the programmer in me that is a bit sad because the Docker revolution is another win for the sloppy programmer. There is something fundamentally wrong in our software industry if our software is so brittle and fragile that we can only make it run in a rigidly defined bitwise identical world, it points at a fundamental failure in the way we develop software. Sadly, we have so far been unable to learn from nature. In nature, systems survive and evolve because they are dynamic, adaptable, and resilient, often even anti-fragile. The Docker revolution will actually make our systems even sloppier since now many bad practices will go unpunished and this will have a price tag. These now unpunished bad practices will make maintenance and evolution of the code base much harder, aggravating the situation down the line.
Then again, who cares what happens in the next quarter? This Docker development model will likely lower the use of the excuse: 'But it works for me!' in this quarter.
Peter Kriens
Follow me on Twitter @pkriens
Thanks for the nice and extensive write-up, Peter.
ReplyDeleteOf course, you're right, that a brittle and fragile software could benefit from docker, thus sloppy development would have more chances to survive a little longer under these circumstances ;-)
on the other hand, sloppy developers tend to discover tools like docker later or never and if they do they tend to adopt them at a lower rate, that's at least my (subjective) observation.
Also, docker reduces developers and testers overhead of managing their developing and testing environments. This also means, that they can focus more on the essential parts of their work, which in turn can help improving quality of work delivered.
Maybe, it's even quite the opposite? I was even wondering, whether it takes well organized and careful developers and teams to implement productivity enhancing tools like docker into their development process. It might even go so far, that the sloppy ones fail to do so. ;-)
The connection between sloppy programmers and Dockrer seems tenuous to me. The are many ways to help improve code quality. What Docker and it's ilk are assisting with is removing surprises on the way to production. I've seen good programmers tripped up by inconsistent environments. Sounds like a win for everyone here.
ReplyDeleteHi Peter. For what it's worth, one design decision in Docker is to make it as accessible as possible to developers and organizations of all types and all skill levels. This means that, yes, you can "dockerize" a development stack that is not flawless. Docker is tolerant of eg. non-repeatable builds, hacky shell scripts gluing things together, and of course it does not care which language you use. The downside is that using Docker will not magically solve all your problems. The upside is that, once you use Docker, your environment is much easier to share and express in its entirety. As a result, the imperfections in your environment are exposed and made explicit, which is a first step towards improving them. When you use Docker, switching frameworks, build tools or even programming languages becomes much more approachable because your fundamental tooling doesn't need to change. And because more developers were allowed to use Docker in the first place, any incremental improvement to best practices down the road will have a wider impact on the overall state of the art.
ReplyDeleteOur thesis at Docker is that by making fundamental tooling approachable for more developers, and taking a gradual (as opposed to intransigeant) approach to encouraging best practices, you end up having a larger positive impact on software quality as a whole.
A far-fetched analogy would be public health campaigns in Portugal and France, where the Red Cross distributed clean needles and tests illegal drugs for free to limit the spread of disease and overdoses, and take the opportunity to give counsel, advertise rehab services etc. It's easy to argue that the Red Cross is encouraging poor life choices. But these campaigns have proven hugely successful in reducing drug usage and drug-related deaths and crime. By accepting the world as it is, they were able to make a bigger difference. Hopefully you won't find my metapor too crazy :)