This Year in Spring - December 25th, 2018

Engineering | Josh Long | December 25, 2018 | ...

Hi Spring fans! And welcome to another, very special installment of This Week in Spring where we look not only at the last week's news but also the highlights of the year behind us. 2018 was one of incredible turmult on the technology landscape, one that the Spring community has been able to deftly navigate. In this special year-end wrapup we'll do what we always do - look at the latest and greatest in the ecosystem, but we'll also revisit the things that I, your friendly neighborhood @starbuxman, feel most positively impacted the Spring developer in 2018.

First, of course, let me get the obvious out of the way. As this is published it is Christmas day, the 25th of December. So, if you celebrate: Merry Christmas!

Now, let's get through our usual weekly roundup - and there's tons to look at! - then we'll review the year in Spring.

This year was an interesting year, one that saw existing practices refined in remarkable new ways. Here are the things I'll remember from the year that was 2018.

  • Reactive Programming We touch on specific aspects of this in other items on this list, but 2018 was if nothing else the year of reactive. In 2018 we delivered the GA versions of all of our reactive integrations, where it makes sense. 2018 saw us release, among other things, Spring Boot 2 and Spring Cloud Finchley which aggregate other projects like Spring Data Kay, Spring Security 5 and of course Spring Framework 5. These releases brought parity, where appropriate, to existing usecases in the blocking and synchronous world. It was also the year that saw us begin the work of providing options that are reactive-only; things that go beyond what was possible ad that are better for their basis on reactive programming, like R2DBC and RSocket.
  • RSocket Systems integration is hard. Integration is hard. HTTP is a strong protocol for document retreival, but it lacks application-level semantics that each developer must re-imagine on top of the HTTP verbs (REST). It is geared towards request-response architectures but lacks the ability to handle other message-exchange patterns like request-response, fire-and-forget, and streams (in either the request, the response or both). We know that the reactive streams specification provides a nice mental model for dealing with integration. In it, boundaries are assumed asynchronous and decoupled. Components support flow-control through the notion of backpressure. Additionally, HTTP is text-encoded. Sure, you can conduct binary data, but you need to encode it as such. RSocket is a new, binary protocol with built-in support for the reactive streams specification from the minds of folks from Netflix and Facebook. It supports all the above message-exchanged patterns. As it's a protocol, there are different client libraries supporting different platforms and languages including JavaScript, C++, and Java. The Java implementation is based, naturally, on Project Reactor. We announced formal support for RSocket in the upcoming Spring Framework 5.2 release train at our tentpole SpringOne Platform 2018 conference.
  • R2DBC A question we always get when people look at reactive programming is "should I use JDBC?" or "Can I use JDBC?" Or, more bluntly, if there is no reactive JDBC option, "should I even bother with reactive programming?" And the answer was always, distressingly, fairly pessimistic: you're not going to get the vaunted scale benefits of reactive programming if at any point in the stream you need to block to handle the scale. If you end up spinning up new threads to scale out the interaction with JDBC, then you've limited your systems scale potential. But this isn't to say that there's no way to achieve reactive SQL. It's just not JDBC. There are options on the horizon that might make for a very interesting alternatives to JDBC for those database vendors whose drivers natively support asynchronous IO and reactive programming. One option is R2DBC which we announced at our tentpole conference SpringOne Platform 2018. The integration is three tiered: first there's the lower-level R2DBC SPI, on top of which are built database bindings. At this point there are bindings for H2, Microsoft SQL Server, and PostgreSQL. At this level you'll find a DatabaseClient, more or less equivalent to JdbcTemplate, which makes using low-level R2DBC as convenient as it gets. Then, finally, at the top of the proverbial stack is Spring Data R2DBC. I look at all of this and more in last week's Spring Tips installment, too!
  • KNative Serverless, a term that is in of itself almost meaningless these days, is all the rage. It describes this idea that we should let the platform handle increasingly more of the work of moving software into production. In a function-as-a-service platform the unit of currency is a function. It's something that the platform invokes on a request. Everything else -routing, dispatch, scale up and out - is handled by the platform. The output of one function can be the input to another function. This composition means that interesting things can happen. Functions can be connected ad-hoc one to another to yeild results. In addition, functions can be attached to event sources, responding to events in the ecosystem of functions on whatever platform the functions happen to be running. Here, their prowess as integration code becomes evident. We at Pivotal announced Project Riff in 2017. It was, as we originally envisaged it, a function-as-a-service platform built on Kubernetes. But this was only the first step. A few months after we introduced it at SpringOne Platform 2017 event, the Riff team started work with Google in developing KNative. KNative is a further abstractification of Kubernetes. It provides built-in primitives that something like a Project Riff could conceivably be built on. Which is exactly what we did. In 2018, Google and Pivotal announced KNative at Google NEXT, and I became the first non-Google employee to do a KNative demo in my joint-presentation with Ray Tsang at Google Next. KNative is a big deal not just for Project Riff, but for the Kubernetes ecosystem in general and I'm excited to see where it goes.
  • Spring Cloud Supremacy This year cemented Spring Cloud's role in the distributed systems toolkit for developers. Spring Cloud core itself became reactive. It introduced new oft-asked for features like Spring Cloud Gateway. It also saw the release of GA versions of Spring Cloud for Google Cloud, and Spring Cloud for Microsoft Azure. It also saw the debut of Spring Cloud for Alibaba (that's tomorrow's Spring Tips installment!) This year more than ever we saw large organizations make the move to microservices and even vanguard technology companies like Netflix, which were already integrating Spring Cloud, doubled-down on Spring Cloud this year.

What a year indeed! And next year is already looking to be bigger and better! That's a wrap for 2019. We'll see you next year, 1 January 2019.

Happy New Year from all of us to all of you!

Get the Spring newsletter

Thank you!

Get ahead

VMware offers training and certification to turbo-charge your progress.

Learn more

Get support

Spring Runtime offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.

Learn more

Upcoming events

Check out all the upcoming events in the Spring community.

View all