Devoxx Poland 2018 – our notes

We are not attending every IT event in Europe, but when we do, we try our best to take the most out of it. Here are notes of our Project Manager – Maciej Radzikowski after Devoxx Poland 2018.

De facto standards

Industry standards are not what is in titles of prelections list on events like Devoxx. It is what is assumed as obvious during those presentations. Spring leads the way as default Java framework. It was an engine for most demos during life coding sessions. Moreover, speakers often mentioned it on whatever topic they said. Contrary, JEE / Jakarta EE, main Spring rival, was mentioned or used as an example only occasionally. This isn’t surprising. Jakarta EE is a little bit behind after years of slow-down under Oracle management. It is also simply far less popular in our region.

Microservices

After being a buzzword for last year or two, microservices has transformed into actual architecture solution. Nowadays they are commonly used. We got much less “transform into microservices” or “common problems with microservices” topics. In comparison, last year those topics were extremely popular at various conferences. Rather then microservices were treated as a popular solution. A solution which should be considered on multiple occasions. Actual transition into microservices resulted in multiple speeches on how to test and improve this kind of architecture. Especially in terms of High Availability. More on that later.

Another two worth to mention technologies are Apache Kafka and Spock. Kafka is a scalable message broker. It is assumed to be the most popular solution for communication in multi-service environments. Probably, it is true. Several speeches were dedicated optimal use of it and new features, like KSQL.

The last one, and probably the smallest of all above, is Spock. Spock is a unit testing framework, that clearly gains the advantage over what was standard by many years, JUnit. Even Junit 5 release couldn’t help it get back to the first place. People used Spock for unit testing during multiple live coding sessions. This speaks for itself and it definitely makes Spock worth to check out technology for everyone still using good old JUnit.

This year buzzword: reactive services

Nowadays reactive programming is popular in all kinds of applications. It is what it is thanks to Java 9, libraries like ReactiveX and their integration with frameworks. Today, it’s time to take it one step further. Or at least that’s the conclusion from this year Devoxx Poland.

Usage and advantages of reactive web services was a topic of several speeches. Most popular implementation is, of course, Spring WebFlux. It allows transforming Spring application into a reactive one. It’s not the only available option, as, for example, Akka offers Akka Streams. But thanks to popularity of Spring, WebFlux was definitely most often mentioned.

The keyword here is “future”

Reactive services for sure offer great features. Non-blocking request handling with effective concurrency support is great. In fact, it may be a future standard for web services. Unfortunately, I believe the keyword here is “future”.

Right now support for reactive services seems limited.

Creating one requires some repetitive code on multiple layers of the application that feels a little bit like a boilerplate. It isn’t just “put your logic in this method, the framework will do the rest”, that we finally accomplished over last years. To convert our application into fully reactive one we need special operations in facade methods, database repository methods, and others. On the top of that, also clients must be “reactive” to support data incoming in parts, backpressure and so on. Transforming into reactive is not only some server-side concurrency optimization but rather change of service’s API.

All of that makes reactive services an interesting solution worth keeping an eye on. Yet, I advise you to get good knowledge before you would use it on production. You have to have strong reasons which overwhelm problems mentioned above.

Trending: Kotlin on the backend

Kotlin, the language that conquered the Android world. Its popularity grew thanks to the fact that it offers modern day advantages in programming for older JVM versions on mobile devices. Nowadays it starts showing up on server-side. Using Kotlin on backend was always possible thanks to it compatibility with Java. But now it’s actual movement in enterprise systems.

There may be several reasons for that. Shortened time of support for next Java versions by Oracle makes big companies nervous. On the other hand, developers appreciate new language features, that make Kotlin look like being one step ahead of good old Java. Even if Java’s development cycle recently fastened…

Ultimately, official support for Kotlin and embracing it features in Spring framework definitely makes it easy and profitable to switch.

I would not go as far as stating famous “Java is dead”. Nonetheless Kotlin is a language that makes stronger and stronger appearance on JVM scene. Thus it’s definitely worth checking out. But as always a decision to use it should not be taken hastily. Especially if you want to use it on the production. Trends appear and disappear. Even trends as strong as this one. So it will take some time until we will be able to say that Kotlin has the same leading position on servers as on Android.

Start doing: chaos engineering

No architecture talk this year could take place without at least mentioning chaos engineering. Since microservices become a standard in our industry, now it’s time to have it properly tested. When the most famous example of it, Netflix’s Chaos Monkey, was introduced publicly years ago, it was an interesting, but quite a fancy idea of streaming giant. Now it has to become a standard in out microservices world. As weird as it may sound at first, designing for failure looks like the best, and the only option we have. So everyone who’s not doing it already should really get familiar with Chaos Monkey and his friends from the Simian Army. Or at least everyone who wants to provide High Availability services in modern days.

Was attending Devoxx Poland worth it?

To sum up – it was worth attending Devoxx Poland in 2018. I would definitely be here next year. In my opinion, you don’t have to be on every IT event in Europe. If you do, you wouldn’t have time to work as a Project Manager, Developer or Tester. However, you should definitely choose a few to have an idea of the direction in which the industry is evolving. Devoxx Poland is one of those events.

Also read:  Tizen – what it’s like to develop for wearables made by Samsung