Contact us

4 learnings from Spring I/O 2019


August 01, 2019

Spring I/O is ”a two-day conference full of Spring and Cloud awesomeness” - as its Twitter bio states. This year in Barcelona, for two days in May, our colleagues were there to bring some fresh perspectives home.

We asked each of our colleagues what they learned at the conference, which are the main ideas to remember from the experience. In doing so we started to notice a few patterns. In this article you will read all about the most memorable concepts presented at Spring I/O 2019 from Laszlo Miklosik - IAM Consultant, Lucian Moldovan and Vlad Mureșan - Technical Leads at COERA.


Reactive programming builds non-blocking applications that are more resilient to high loads of data, managing asynchronous data flows more efficiently for real-time applications.

LASZLO MIKLOSIK: Reactive Programming is already used in mainstream by many companies, so in order to scale in the Cloud, to support millions of users you really need an architecture which can scale and that’ s precisily what Reactive does.

We saw many real life examples of how this is being used in production; sometimes in combination with Kafka from Confluent and Sometimes simply via Reactive Spring.

I saw some nice examples and I think using it together with Kotlin is really elegant. This is something which we will probably try out in the near future.

LUCIAN MOLDOVAN: Reactive programming is going to pick up. It was the same case as a couple of years ago with microservices that were presented and had a lot of support, so people moved to that type of architecture. I'm guessing it's the same with Reactive programming.

They announced that starting with Spring Boot 2.2 you could have a sort of hybrid application whereby you can mix in the same project reactive and non-reactive. Until now it had to be either one. It's not the same as having only a reactive application, but you can have the benefits of gradually switching from one to the other.


Cloud Foundry is an open source ecosystem which makes building, testing, deploying, and scaling applications easy, fast and elegant. It saves time and other resources, it is portable and automates everything.

LASZLO MIKLOSIK: It is more productive to deploy on such an environment than on an infrastructure service, but of course it comes with trade-offs. And again maybe not everyone should use it, but people developing Spring applications should definitely try it, because they will have better time to market.

I already tried out a few things out of curiosity and my plan is that the next application we deploy that cannot be hosted on premise, will be hosted on Cloud Foundry.

When I will need to build an access management system, then I will consider building on top of the components from Spring security instead of using an off-the-shelf access manager application, like the community edition of OpenAM, which has an uncertain licensing future. Now I see that most of the features offered by such tools are already there in Spring Security. I prefer to build our own using those components. It will be productive enough and it will not depend on other vendors. At the conference we saw CloudFoundry's UAA (User Account and Authentication) Server in action. Its sources contain many useful examples on how to use Spring Security features to build an OAuth2.0 Authorization Server/OpenIDConnect Provider. We can also use the open source UAA server to mock such applications during the development/configuration of SSO scenarios. Joe Grandja's presentation on this topic was impressive and was connecting cloud, microservice and security topics.


Kafka is a distributed streaming platform. It is used to build real-time streaming applications receiving and sending data from and to multitude of systems.

LUCIAN MOLDOVAN: We were considering Kafka before going to the conference as one of our messaging options. The conference gave us the opportunity to listen to how other people are using it, what they think the benefits are, what were the challenges, all while trying to gain more knowledge about the subject before implementing it ourselves.

Prior to the event we did research online on our possibilities and Kafka came out as a solution, based on a couple of factors like how easy it is to set up, which companies are using it, if it has good support or not, if it has a good documentation or not, scalability, performance and so on.

In one of the case studies presented at Spring I/O, the challenge they had was related to a notification system they were trying to implement. The solution was a custom approach to the problem which allowed them to have messages streaming through Kafka at really high throughput.

They decided to have a custom set of metadata that Kafka supports and they were keeping this metadata in KTables. Instead of going out and fetching the metadata to associate to your data, it is already there. By having fast access to both data and metadata really good performance is achieved.

For one of our customers we have a similar use case and using Kafka is a serious option.


RSocket is an application protocol that supports Reactive Streams and Reactive Extensions.

VLAD MUREȘAN: RSocket is a protocol for asynchronous communication between several parties. It makes use of the new Reactive model implemented in Spring. Now you can also communicate with other systems - like other servers or clients. This protocol is used by Netflix for example, for delivering massive streams of data.

It was a light introduction on this protocol. In one hour you don't have enough time to go very deep into the subject. This is usually the case at a conference. Some present theories, some present experiments. You have the opportunity to ask questions based on your previous experiences as well as what they presented. It is very effective. For a couple of days you are completely separated from work, going into the appropriate mindset to process a lot of information. You just recharge your batteries, come home and do the follow-up research.


LASZLO MIKLOSIK: A lot of people did live coding. They were improvising like jazz musicians. They didn't know what was going to happen. Sometimes they asked the audience - if there were any ideas for what they should do. The guys knew each other, but I'm not sure how much they worked together before. When they were on stage each of them did its own part and they worked well together. They also managed to do it on time.

I think this type of events are really useful for people who are in charge of architecture and design decisions. Besides, this shows you a good overview on what the Spring framework offers< and what changes (features and breaking changes) to expect in future versions. You also have the chance to understand a bit the history of the framework and the decisions taken as the framework evolved. And how you can do things very efficiently.

LUCIAN MOLDOVAN: Because it's a good place to interact with people who are creating the tools that you are using. If you have a question, you can ask someone that is working on that tool, you can ask them for advice or present them with a problem that you have. They are honestly open in trying to help you.

I talked with one of them and he literally pulled out his laptop from his backpack and started showing me an example of how to create a reactive websocket connection. Basically, it was a 15 minutes demo. His name was Josh Long. He works at Pivotal.

I think he has been to all the Spring conferences that I went to and he's one of the most highly rated speakers. He is presenting his talks in such a way that you are really focused the whole time. This makes it even more attractive when a new technology is introduced.

VLAD MUREȘAN: A couple of years ago at the same conference, they only started the conversation about these new technologies. Now they did it with some experience.

It is quite difficult to just play around at home because you do not have sufficient time. That's why it is important to be able to apply this learning into your day-to-day job. Even if you do not have the chance to experiment at work, I would recommend attending a conference like this. They pointed us into the right direction, but there is still research we have to do.