Peer pressure is real, it turns out.
Instead of particular subject areas, however, the focus here will be on questions. Some broad and industry-wide, others more narrow in scope. What are some of the big picture questions facing the industry, both questions that are asked of RedMonk and that RedMonk asks of the market itself?
How will application development and infrastructure evolve?
If there has been one constant to the industry in both the application development side and the infrastructure those applications run on over the years, it has been change. The upcoming year will be no exception; if anything, the evidence suggests that change is arriving more quickly every year.
The question, therefore, isn’t whether application development or infrastructure will change, but how?
There are many different threads to follow here. The rise of the term coined by my colleague, “Progressive Delivery,” is one such as articulated in his 2020 outlook and elsewhere. It’s a term with a tremendous amount of industry currency at the bleeding edge at the moment; to what degree will that begin to trickle back into the mainstream?
The accelerating transition to infrastructure as composable services, or the “servicification” of the industry from application development through to production, is another. RedMonk has long argued that large portions of application development today are packaging exercises more than anything; this trend has only become more ubiquitous since. What impact will this have on application development in the year ahead?
Similarly, given how dramatically the process of application development has changed over the years as encapsulated in DevOps, it’s natural to expect similar – or at a minimum, some – transformation on the data side of the house. There is movement here, specifically in the DataOps push, but the question in 2020 will be degree of traction.
What’s going to happen this year with open source licensing?
The least unpopular if oft commented on subject in this space, questions are swirling around open source licensing in ways they have not in years past. Just as the push towards so-called “non-compete” licenses – primarily from open source or formerly open source database authors – seemed to plateau, a new challenge to the status quo arrived in the form of “ethical licensing.”
There are a variety of economic, legal and logistical reasons that suggest that the parties behind both ethical and non-compete licensing should look to mechanisms other than licensing – even if one agrees with one or both motives.
Increasingly the loudest voices behind these movements, however, seem indifferent, unaware or both to the practical implications not only of how open source licenses operate but why they work in practical terms, as content to dismiss those who raise legitimate objections with the equivalent of an “ok, boomer” as those on the obstructionist side are to claim that no change ever is necessary.
While there are thoughtful actors respectful of the history and cognitive of the deliberative pace that is appropriate for directional shift reasonably advocating for change, they are, regrettably, the exception rather than the norm.
In 2020, then, the questions will be whether those who seek to responsibly protect open source from poorly thought out change with long term implications – those whose work, often purely on a volunteer basis, is sneered at as “out of touch” and dismissed as “pointless” – can hold the line. If they can’t, the meaning of open source, and thus the role of open source, will be lost with consequences those without an understanding of the history cannot presently comprehend.
Will DIY give ground to more integrated solutions?
For many years now, as new technologies have arrived ever more quickly in ever more accessible forms, the problem of fragmentation has been growing. Fragmentation manifests itself differently to buyer and developer, but is unmistakably a problem for both.
One obvious question as a result of this has been how the industry responds, and if history is any guide the answer is equally obvious: consolidation and tighter integrations. Thanks in large part to the runaway success of Amazon Web Services, we live in an age of DIY platforms sold to DIY buyers.
What is not obvious is whether, or perhaps when, DIY will begin to give ground to integrated solutions. Is GitHub Actions, for example, suggestive of the shape of things to come, and if so, what does that mean for Amazon? We’ll know more about the answer to this question a year from now than we do today.
What is the atomic unit of computing?
Much thought has been put in in this space to considerations of the atomic unit of computing. In the beginning, it was physical hardware. Later, after people realized it was not in fact a toy, it became virtualization. More recently, that abstraction gave way to containers to the extent that the company who owned the virtual machine business has been hard at work refashioning itself into a container company on the fly.
Before the dust had even settled on that transition, however, canaries began to sing sweetly of new and emerging technologies from Isolates to MicroVMs to WASM.
Like my colleague, then, one of the questions to be explored here in the year ahead is which if any of these technologies will make a bid – successful or otherwise – for mainstream traction as the new atomic unit of computing. MicroVMs made a huge splash on entry, but recent chatter has pointed increasingly towards WASM and there are certain contextual market factors that may assist it. What 2020 holds for all of these technologies, then, will be something to watch.
Is a Kubernetes backlash coming?
It’s difficult to remember now, but in 2014 Kubernetes was a science project released by a company more famous for releasing details on how to build technologies than code for the technologies themselves. The most common initial reaction was that it was a poor man’s knock off of Borg, and therefore unworthy of real attention – particularly given that there were multiple competitive projects. The most common analysis, meanwhile, was that it was a hail mary attempt to insert an abstraction between workloads and AWS such that the former wouldn’t be welded to the latter in a permanent way.
What a difference a few years can make.
These days it’s more of a “Kubernetes, Kubernetes, Kubernetes” situation, in that it’s Kubernetes’ world and we’re all just living in it. Which is an interesting state of affairs for a technology that even its developers admit is complicated and not all that developer friendly. Regardless, Kubernetes has hit that rarefied level of success in which even vendors that have nothing to do with the project insert mentions of it in their messaging in an attempt to attach to its momentum. It’s so successful that people who have worked on it have to write pieces telling you that you might not need it.
Even long term successful technologies, however, go through periods of disillusionment, and there are whispers here and there of frustration with Kubernetes – and, it should be noted, the communities around it. Which should perhaps be unsurprising, since so many enterprises are buying Kubernetes solutions first, and asking about the problem to be solved second.
Is it possible that 2020 will be the year of the Kubernetes backlash, or as our colleagues from Gartner might term it, the “Trough of Disillusionment?”
Certainly seems that way. Given its foundational role within so many enterprises and enterprise-targeted offerings – not to mention the tens of billions of dollars that have been invested in and around it organically and inorganically – it’s not going anywhere. But if there is a backlash this year, it’s worth considering what that might open a door for.
As always, at RedMonk, we’re interested in and will be talking about a very wide array of topics, and the above list is obviously non-exhaustive. If anything on there is of particular interest, however, feel free to reach out, and otherwise let’s see what the year ahead holds.
Disclosure: Amazon and GitHub are RedMonk customers.