Bulletin 1 February 2019. On Terminology Refresh from OO to Microservices
Old Wine In New Skins?
And then, I read a recent interview which talked about Rapid Application Development, Object Orientation, 3-Tier Architecture and Test-Driven Development. Of these only the latter appeared as a term this side of Y2K, and no doubt its origins are from before it. And, as I told the author and interviewee, “having been steeped in the DevOps and platform-based world for the last couple of years, it’s quite refreshing to read something which uses (let’s say) more ‘mature’ terminology.”
There’s a strange phenomenon going on in everything around DevOps, CI/CD, microservices, Kubernetes etc, which is that it is framed as something new at the same time as re-inventing the wheel — the challenge is to work out what really is new, in this case it’s probably mostly about dynamic orchestration into scalable cloud-based architectures using a modular approach.
Earlier this week I gave a talk on all things digital, not least the notion of Fail Fast which, done right, can trace its origins to Barry Boehm’s spirals of the Eighties. Meanwhile, architectural practices around Kubernetes/containers/microservices etc harks back to Yourdon and Constantine’s principles from 1975, as well as prior work around Modula etc.
Meanwhile the current “Shift Left” and “By Design” rhetoric (two sides up the same smaller peak) align with Test-Driven Development, which fits with best practices around writing unit and integration tests I was taught in the Nineties (not that many were that disciplined, in my experience).
Two thoughts on this. First that it’s unnecessary to rub anyone’s noses in it, more that such principles clearly still apply. But second, this isn’t just about doing that “I’ve seen this all before” thing, because this isn’t a simple case of re-inventing the terminological wheel. Rather, it’s important to spend a bit of time to work out what has changed in the current context; then, them old principles can be applied back.
For example, the point at which Moore’s law + “industry standard” x86 architecture outgrew a single machine and made the idea of multiple emulators on a single machine viable, that changed some things (we call it virtualisation) but didn’t affect basic notions of modularity, nor how to keep on top of complexity.
Meanwhile however, this latter point is why I tend to give short shrift to people who talk about ’serverless’, ’no-ops’ or ‘functions as a service’ in terms of doing away with everything that went before: the economic arguments about “one day you’ll just write lines of code and the environment will take care of the rest“ make swathing assumptions about architectural complexity, modularity, testability and so on.
It’s not that we need hard boundaries around our code (which of course don’t exist anyway, as per Turing, everything is a Turing Machine, the rest is about representation of choice) but more that, we need theoretical constructs that make it easier to control and validate the software-based complexity that we create. Objects, modules, microservices, virtual network functions, it doesn’t matter what we call them but they all fit into that goldilocksian category of not too big, not too small.
The bottom line is that BS can be both “new and improved” and “it’s all the same” - both are wrong. I could go on — I’ve been watching with interest activity around Kanban, that lean/agile change management approach, and thinking about how it overlaps with DevOps and other philosophies (the answer is, by quite a lot). Definition, it would appear, is largely in the eye of the beholder: perhaps that should be the subject for another newsletter.
Thanks for reading, Jon