Thoughts for 2018

It's always interesting to look at the year ahead in technology! Herein some thoughts about 2018. I won't call these predictions, more extrapolations of what's already happening and what the second order effects might be.

Machine learning as a general software skill. AI hype will continue to generate more heat than light, but  in 2018 software engineers will come to see machine learning as a general skill to acquire, not just a specialist discipline to support. And by this, I don't mean, "builds and runs the machine learning clusters for the PhDs", though that will continue to be an onramp. I mean machine learning will be viewed as search, databases, or networking have in the past, something you end up using to do your job. This is a gradual, inevitable shift that will happen over the next decade, and while I don't expect interviewers en-masse to swap out two's complement questions for matrix elimination any time this year, I do expect engineers to start looking at machine learning as a useful, and eventually necessary, engineering skill pretty soon. It helps that machine learning is suited to augment or eliminate classes of work for software engineers and that the frameworks (like Keras and TensorFlow) are becoming very good.

Serverless becomes acceptable, kind of. Discussion around serverless (or FaaS) computing has sometimes been too-focused on the term (serverless systems do not in fact get rid of servers any more than clouds get rid of datacenters - ok). This isn't just well-founded scepticism - I suspect the server-side community may be apprehensive about serverless for various reasons such as lock in and distributed event spaghetti, but also as a technology that takes more heavy lifting away than perhaps we're comfortable with right now. Like machine learning, serverless is potentially disruptive over time to server side job functions. Regardless, in 2018 I think we'll see more acceptance of serverless as a valid approach, one in particular that lets people move quickly. It also adjusts the value proposition of the all-important orchestration layer, which leads to... 

An orchestration winner won't settle down the cloud. Kubernetes, through smart community management and collaboration has won a ton of mindshare. All the major cloud providers now embrace it and offer a managed option (though it will be ironic if AWS ends up providing the best in class managed Kubernetes offering). Rather than settle things down, Kubernetes will accelerate change in adjacent layers. The commercial ecosystem around it is quickly moving up the stack to service meshes, CI/CD pipelines, and hygienic/ergonomic configurations, as Kubernetes itself isn't differentiating. However all roads seem to lead to event driven microservices and of course, serverless, where AWS have a strong start. It's interesting to wonder whether overlay technology like service meshes are strategic for those trying to catch AWS versus establishing a serverless gateway interface standard for application development, or whether the major cloud vendors continue to compete in the serverless area using differentiated offerings. 

Events driven microservices get adopted, but with a pioneer tax. In Zalando, where I work, we decided some time ago that events should be a first class element of a microservice interface at the same level as the orthodox REST-like or RPC/synchronous APIs. We get benefit from this approach, not just technically, but operationally - publishing events for pickup produces a very different set of oncall/fault domains and service level objectives versus the deep activation paths that characterise synchronous microservices. An awful lot of what businesses need to get done for their customers can get done out of band, and as a result many, many "real-world" business processes can be modelled as asynchronous event flows. However you can't abstract away the communication style of a system and this has implications from design through to operations. Also, the tooling, practices and patterns are not as mature as traditional microservices or LAMP systems where there is plenty of codified, hard-earned knowledge. So while the benefits to using events in microservices exist and are important, there is a pioneer tax to adopting them right now. There will be plenty of learning by doing as people figure out what works for them, and some teams may decide to jump straight to a serverless style.

Kotlin goes mainstream as a better Java. There's a lot going on in the JVM world - Java 9 will start getting rolled out, Java 10 is on the way, JEE went to the Eclipse foundation. Despite the rise of Go for service infrastructure there's still a ton of application infrastructure being built on the JVM especially for data intensive workloads like stream processing. All that said, Kotlin is for me one of the most interesting thing happening on the JVM at the moment and the tooling support from JetBrains is excellent. Now that it's been blessed for Android, developers will be willing to consider it as a better Java and a good stepping stone towards typed functional programming. This reflects a broader pattern where mobile technology increasingly influences server side decisions.

Designers start to establish new interface principles. Efforts like Google's Material Design and Apple's Flat Design, or, process models like IBM's Design Thinking Field Guide, don't really cater for voice experience, free form text, or augmented/mixed reality, where you are either interacting with nothing (a voice) or something (an object) but neither of which is a functional artefact designed to enable interaction (like a button or a scrollbar). There's nothing in Material for example to cue the system is paying attention to you after the wake word. Designers to their credit are already dealing with this and the technology limitations - witness chatbots, which are best conceived of as guidebots at this point. I suspect in 2018 there'll be more thinking from first principles around these kinds of interactions. Voice in particular is crossing the chasm from a novelty; people will eventually expect their devices, apps and websites respond in the same way.