Strong words, but there’s more than a grain of truth in them: “Why Kubernetes is The New Application Server“. “Classic” application servers like those for Java are no longer sufficient by themselves to build a platform that can serve big internet-applications with a large, world-wide audience. And in the world of “containers” Kubernetes seems to be king, as far as I can tell.
(Photo by GPA Photo Archive – Original on Flickr)
In order for containerisation to work, applications must be properly “documented” – in fact, the bulk of the “configuration documentation” will somehow be part of what is needed to get those containers up and running. Around the time I read up on Kubernetes I stumbled onto something called “The Twelve-Factor App” – can’t remember who pointed me there. This methodology (it’s not an app!) describes a well-documented way to build, configure and run a cloud application – a laudable objective.
At work, we have tried to describe our applications in order to migrate them to another (Windows) domain with new (better) rules about access control, database access, etc. But things aren’t working out as they should. We do have documentation, although I’m not sure how useful it is outside of the context of passing relevant information from the developers to an external partner that will implement parts of the configuration. Additionally, we have described lots of “what“s, but almost no “why“s – which might be essential in the coming months and years as the applications continue to evolve…
Ideally, I would have loved to have a decent ‘methodology’ for documenting application essentials when we were building our applications. Trying to figure out what has to be done to get things up and running again on new servers has become something of a nightmare. That is even more so when the application you’re handling was developed by someone who’s no longer available for questioning!
The Twelve-Factor app may turn out to be very useful, although I suspect it is incomplete. I don’t think there is a single method for completely describing and documenting applications and systems that extend beyond the most simple cases. Any ‘methodology’ to build software is bound to need more or less tweaking to fit your (or your company’s) way of working. Getting to know methodologies other than the one you’re using is a good way of discovering what you need to get better!
