Over a million developers have joined DZone.

Timing technological change: creation vs. consumption

· Java Zone

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

In any space, there is a very small vocal minority. Most people lack the time, interest, or even confidence to say what they think in public. So we are left with a vocal few who drive the conversation. In networking, the vocal minority consists mainly of the vanguards for change. For these people, the network is more than just some connective tissue inside a nebulous infrastructure. It is their life. They live and breathe it. Accordingly, they have strong opinions about how things work and, more importantly, how they ought to work.

But what is happening now is that we are at some risk of the luminaries creating an impassable distance between their vision and the on-the-ground reality in many IT shops today.

Most people nod their heads when there is talk about programmability, APIs, and massive automation frameworks. But head-nodding should not be mistaken for agreement and support. It simply shows an understanding of the argument. It can mean anything from “Oh my god! Let’s start right now. Where do I sign the PO?” to “Your logic is sound. You are really smart. Where did I put my Cat6k?”

When you look at the large, web-scale properties, the need for customization and the desire for a DIY environment is huge. These guys simply cannot operate in an environment that is as costly or difficult to manage as what most companies have today. This is why companies like Google have embraced SDN and white box switching from the outset. They stand up in front of conference crowds and talk about what they have done.

And everyone nods their heads.

But let’s be clear: not everyone is Google. Even if their needs were the same, they aren’t printing enough money to make hiring a whole new team feasible. They live in a different reality.

The truth is that there is no inherent nobility in what we build. Whether your environment is massive and complex, or small and simple, all any of us is really trying to do is support our business. If our business requires that we build something sophisticated, we will go and build it. But there are a precious few jobs where sophistication itself is the goal. So barring the work done in professional labs or academia, the vast majority of our market consists of people whose objective is really straightforward: make my business work.

This creates an interesting dynamic. The industry dialogue is dominated by the newest and most sophisticated technologies while the industry buying motions are dominated by the same legacy solutions that have been popular for several decades. I don’t mean to suggest that legacy players can rest on their laurels, but the transition from an aging environment to a newfangled one is not so easy (or even a priority) for many companies. And the further out ahead of demand that vendors go, the more difficult it is to bring customers along.

Make no mistake about it: there will be vendors who overshoot. They will reach too far, convinced that the future is changing. They will be right. But they will be early. The question for these vendors is whether they have the funds to wait for the market to catch up.

This means that vendors in this space have to be worried about more than just getting the technology right – they must also get the timing right. Show up too late, and you are obsolete before you hit the market. Show up too early, and you end up going out of business before the market adopts the technology.

Ultimately, for companies to be successful, they need to be a part of important technology trends while not creating too much distance between themselves and the market. But how do you thread that needle?

The key is in creating a solid technological foundation (you cannot risk obsolescence) from which you can apply an intuitive approach (make it easily adoptable). There is just as much skill in making technology consumable as there is in willing it into existence. Innovation is more than just exposing a bunch of capabilities through APIs and configuration knobs. You need to make those capabilities relevant and easy-to-use in context.

This is partly why OpenFlow has an adoption problem. Tons of capability, but very difficult to use. And it’s not just OpenFlow. If you look at a lot of the edge policy features popular in service provider environments, or complex traffic engineering setups, or even elaborate QoS schemes… they all suffer from a general lack of intuitiveness. Unless the network is your business, you don’t have the time or desire to sift through it all and figure out the arcane bits and pieces.

This should be instructive. As new companies attack the network, they need to be emphasizing more than just functionality. Those that address both the creation and consumption of technology will be uniquely positioned to take advantage of the vocal minority while servicing the buying majority.

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.

Topics:

Published at DZone with permission of Mike Bushong, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}