A Word About Microservices on Behalf of “Technology People”
“People writing and thinking about technology spend too much time thinking about pure technological innovation,” wrote The New Stack’s Joe Emison last week, “and almost no time on the strategic benefit that the technology delivers.”
In founding this publication, Alex Williams’ vision has been to encourage discussion and, where warranted, debate about the issues we face as technologists and even as a society in promoting yet another stack of technological newness. With all respect to Joe Emison, I believe that we, as technologists and as writers, don’t spend nearly enough time, and sometimes none at all, devoting neurons to pure technological innovation — otherwise it might have happened much sooner than it has.
Let’s be absolutely honest about this: From our vantage points, the rush towards microservices architecture and the systems of containerization that could bring it about, has seemed almost violently sudden.
As anyone standing next to a volcano once thought to be dormant will tell you, these pressures build over time, and their primary cause is usually an abundance of suppression.
But to much of the rest of the world, including those devoted to the technology space, what we in this publication have often characterized as a revolution, is not even happening. Huge segments of industry that are centered around information technology, particularly in the financial space, have never heard of containerization or Docker, and if we produced ten times the volume of articles we produce now, this fact would not change a scintilla.
The End Goal
Emison’s case, in summary, is this: The whole point of the cloud revolution in the first place has been the need for business agility. Agility should be the end goal of all technology, and cloud services achieve that through simplified, less expensive provisioning. Too much technology, microservices included, impedes this goal. The reason, Emison states, is that “technology people just want more technology.”
If the key to my ire were a combination lock, that sequence of assertions would reproduce every digit of it in the exact sequence.
Perhaps Emison and I live on opposite sides of the technology space where the proverbial elephant in the room resides. But the very fact that this can happen proves my point: If business agility were truly the goal of every technological advancement in computing, then the world would already have melded into a seamless nation-planet of like-minded, well-meaning traders of goods and services, all sharing a cohesive, all-encompassing, homogenous cloud platform of complete informational fairness: an amalgam between the NYSE, Twitter and Starfleet.
There is some other force at work here, and it is much stronger than anything purely technological. The end goal of business is not, and perhaps never been, “agility.” The word itself does prove convenient as a source for syllables for the names of institutions that sponsor Sunday morning politics shows, with names like “Agilment” or “Congility” or something equally horrid.
But the true end goal of all business has always been self-preservation.
Space Program
Cloud technology did not arise from the need for business agility. In fact, business interests might never have created it at all, if they were left to their own devices. The concept of cloud happened by accident, as a result of efforts to weld together platforms that insisted on remaining separate. As with the fluorescent light bulb, integrated circuits, smoke detectors, and memory foam, we largely have NASA to thank for cloud dynamics. The first truly self-provisioning cloud architectures were built inside shipping containers placed outside the Mission Control Center at Cape Canaveral.
Now, you could credit “technology people” with the advent of cloud architectures, but then you look at their motivation and their goals, and you realize that these people did not want more technology. They wanted less.
Microservices architectures (which are not really new, by the way, despite the title of this publication) are also the culmination of an ingenious effort to do more with less. All great technological efforts are about the creation of efficiency and the reduction of surface consumption. We cram more onto less space – it’s Gordon Moore’s seminal observation that folks promoted into a “Law.”
What microservices require, as is the case with all technological endeavors that are not driven solely by the need for self-preservation, is a deep dive into abstract reasoning. The microservices ideal is that both business and computing processes can be decomposed into the smallest units of work, and that those units can be made independent of any specific class of work. This way, like molecules in a solid substance, they can be reconfigured and repurposed for any class of work that can be conceived.
It requires a leap of logic that cannot presently be achieved — either by “technology people” or by “business people” — assuming that both camps can be successfully separated, like noble people from clever people at Hogwarts’ School.
At the last DockerCon in June, there was a general acknowledgment among developers that a pure microservices architecture was not practicable.
The reason is on account of technology, not the need for more of it. For any technology platform to be workable, it must be interoperable with what already exists.
Perhaps the greatest endeavor of our time, as long as we as a species are resigned to never having a real space program again, is to somehow fuse the efficiencies we envision for the future with the overstuffed surplus warehouse (with thanks to Bob & Ray) that all the technology we’ve afflicted ourselves with has grown to become.
“We”
At the risk of committing the same error I believe Emison did by declaring “technology people” a subspecies unto itself, there are businesspeople on the opposite side of the universe from us, somewhere, who instead of being joined with us via technology are being separated from us by it. The bulk of information technology, in the realm where more people use it than develop it, is a system devised by elders who have long since passed, being kept on life support by a scant few people crazy enough to care about how it works.
Microservices is just one culmination of the realization that, for us to progress as a society and as whatever kind of people we are, we have to digest this beast somehow: reduce it, deconstruct it, simplify it. If there truly are “technology people” in the world, then they are the ones who aim to do more with less.
Which should, I must concede, be the very definition of “agility.” Yet self-preservation, as any sociologist may observe at a middle-school cafeteria or a political party convention, goes hand-in-hand with fear of change.
When a minority suggests change as a means for efficiency, a majority may conspire to suppress the message, and the force with which volcanos are built begins to amass. This is where the realm subdivides itself into camps, separating the “technology people” from “us.”
“We got rid of the rote SysAdmins and network engineers,” wrote Emison, perhaps speaking from wishful thinking, “but now we need really hard-to-find DevOps engineers.” “We,” one would assume, are those responsible for originating the business strategies with which the goals of information technology are supposed to align themselves, through some sort of mindset shift that has never happened yet. The way he puts it, it sounds less like a thought-out strategy than a desperate ploy. “We” business strategists eliminated the turncoats, and now we could use some new allies. Business agility demands that “we” optimize information technology, he tells us, with the aim of enabling business managers to produce products with as minimum interference from designers or developers as possible.
It is a focus that is absent in the technology articles Emison says he reads, because it is a magnificent fiction.
Doing anything differently than yesterday has been the nightmare of established industries. Change requires an investment in uncertainty. Far more time and money have been invested in an endeavor to devise what technologies and methods are necessary to avoid change, than in any startup seeking to spark a revolution. The very people whom Emison would have cast out from our midst are actually in great abundance: the IT professionals whose daily efforts keep the unfathomable tangle of old technology functional every day, the people for whom we owe the health and existence of our information infrastructure.
Were it not for the continual need for upkeep, two or three “technology people” would have remade the world by now. We don’t read about these daily efforts of information professionals because Google News would score it too low for it to register in its daily lists.
But the suggestion was made that we who write and think about technology care nothing about the needs of business. Allow me to speak for all the millions of published pages, the tens of thousands of articles, the thousands of great debates, and the hundreds of great people who devoted the last scintilla of human effort to the betterment of technology. It is all we have ever thought about. If thinking were enough to benefit the world, we would have replenished it a few dozen times over already. The brightness of our hopes would have vanquished the sun.
The improvement of business mandates that we do more than think. Optimization will not whittle down the process of business improvement to simply thinking. But it can, with considerable guidance and perhaps a modicum of prayer, reduce the bulk of it down to a more manageable size.
Docker is a sponsor of The New Stack.
Feature image: “Message from a dying time traveler” by a.zalonis is licensed under CC BY 2.0.
