I expect that I have said this before but it is a frustrating fact that a lot of marketing material acts as an obstacle to an understanding of what is on offer. Imagine if you had been invited to learn about a wonderful new device that would save you thousands on car maintenance. You sign up for the webinar and listed to someone laboriously explaining a) what a car is, b) why you need one, c) how they are expensive to keep on the road, d) how important it is to ‘optimize’ the repair and maintenance supply chain and so on. Sometimes the marketing folks’ manage to filibuster along for so long that the whole time slot is filled with an explanation of what you already knew. Politicians play a similar game when speaking of a national problem - terrorism or unemployment. They then drone on about the risks without suggesting anything like a solution.
The reason they avoid coming out with an explanation of how they are going to solve the word’s problems may be because these are difficult or intractable. But it is also because a solution inevitably comes with an agenda, tax more, tax less, cut benefits or broaden the safety net. Once the agenda/cat is out of the bag, the politicos know that right away that they are a) going to piss off those who do not share their views and b) expose themselves to honed arguments as to why what they are proposing cannot possibly work. Best to spend one’s allotted time with a recap of the problem set, to share folks’ concern and leave the details to the imagination.
A similar approach is sometimes used by those who sell IT solutions. Reading through the Docker marketing literature one sees that the container approach is about ‘transforming business through software’ and that today, with Docker, ‘everything has changed,’ ‘software is the critical IP that defines your company - even if the actual product you are selling may be a T-shirt or a car.’ Docker can moreover ‘empower your enterprise to leverage big data analytics.’ Marvelous stuff!
As this month sees our second Docker story (from Safe Software on page 4, the first was from Software AG in 2015/9) I thought we should take a look behind the hype. According to Docker, which has just rebranded its offering as a ‘container as a service,’ the idea is to bundle a complete IT stack of application software, libraries and operating system into a single container that can be deployed ‘anywhere.’ Docker claims that this avoids the common problem of deploying software on a third party system and finding out that OS and library versions are different and that the system needs much tender loving care to make it work. So far so good.
The next question is, what happens if you deploy more than one container-shipped applications, each with its own dependencies. This does not really help with interoperability which still, unsurprisingly, depends on what the software in the containers is actually doing. Enter Docker’s marketing hype viz… ‘today’s software is going bespoke as small pieces of loosely-coupled software provide microservices.’
Now this is rather a different proposition and one that limits Dockers immediate usefulness. To achieve enterprise scale interoperability, all you have to do is recode all your apps to provide microservices. Quite a tall order! Until you have done this, Docker’s usefulness is probably more for developers like Safe Software who are using it in the typical service/ETL role of FME. It may be a while before the world comes around to seeing the merits of microservices. Meanwhile, Docker could just as easily be used to build a soup-to-nuts proprietary closed software infrastructure. It depends on what you (or you vendors) are trying to achieve. Docker per se, despite its open source origins does not mean it naturally leads to interoperability – whether by microservices, API calls or anything you care to name.
Docker’s grand claims remind me of an issue we used to have back in the days of dumb terminals and Unix. A dumb terminal is actually far from dumb and not all that standard. Unix provided a special place in the filesystem where you could keep ‘termcap’ files that you could edit and tune every terminal in your organization so that it performed more or less perfectly. Software could read the termcap files and interact appropriately with the user’s GUI. Well that was OK so long as you had control of both the terminals and the software. Things went awry when we began buying software from third parties. Vendors would be loading up all their libraries and I would proudly point them to our termcap files in the expectation that they would leverage all the good work that had gone into them. Err… no that was not how it worked. Vendors came along with their own set of termcaps and their software ignored ours completely. Soon we had as many termcap directories as we had applications. I expect that Docker users run a similar risk of ending up with a hodge-podge of different versions of OS and libraries scattered around a bunch of more or less isolated containers. The problem is that interoperability is really orthogonal to deployment.
The microservices spiel, the notion of software that provides ‘loosely coupled’ services is as old as… well the earliest reference in Oil IT Journal was in 1999 and lip service has been paid steadily to the loose coupling nirvana ever since. You may be wondering what got me off on this rather long ramble. It actually started with the realization that GE’s Predix leverages a containerized approach with a cloud-enabling solution from Pivotal. But more of that next month.
@neilmcn© Oil IT Journal - all rights reserved.