Vodafone Greece replaces Spring Boot with Quarkus

The main criteria for their selection process to find a replacement for Spring Boot were developer efficiency, lower cloud resource consumption and shorter applications boot-up times. They considered the latter to be of great impact on cloud resource consumption costs as well as user experience improvement.

They looked and evaluated other technologies and frameworks, such as other natively-compilable frameworks, Node.js and Vert.x. They decided that Node.js would not be a good option for them because of the burden that they would put on their Java developers to learn and migrate Java applications to Javascript. Some frameworks didn’t make the cut either because of their desire for big solid backers and sponsors. Another native-compilable framework wasn’t selected because it would fail to compile the MongoDB driver - using the MongoDB driver in native mode was not supported at that time and there was no way to skip the portions of MongoDB driver that would not compile to native. They nearly selected Vert.x because of its excellent context propagation capabilities and its outstanding performance. However, when they learned about Quarkus in April of 2019, and that it included Vert.x in its stack and provided memory and start-up time optimizations, they decided to go with Quarkus. According to Christos Sotiriou, DXL technical lead at Vodafone Greece, Quarkus “seemed to provide the performance boost we needed while at the same time having a good backer (Red Hat) and relying on battle-tested technologies”. In June 2019, Vodafone Greece had its first successful microservices deployment that relied on a limited set of their rewritten common libraries in Quarkus.

Another reason Quarkus was selected over competing technologies was the ability for developers to write their own extensions. In addition, the project’s high activity characteristics, such as number of community members, project stars, quick turnaround to replies and fixes by Quarkus developers to community issues, and number of Red Hat developers thoroughly answering technical questions via the project communication channels were positive indicators for them to select Quarkus. Lastly, their trust of Red Hat combined with its credibility in the software market gave them the assurance that they were making the right choice by selecting Quarkus, whose sponsor is Red Hat.

Once they decided on the path forward, Vodafone Greece first started migrating their common internal libraries from Spring Boot to Quarkus. Their common libraries cover cross-cutting concerns, such as:

According to Christos, “implementing distributed logging would have been very difficult to accomplish with Spring Boot, whereas with Quarkus, creating this new common library was viable and feasible. The methodology of setting up header propagation and perform actions on a microservice’s inbound-outbound requests in Quarkus allows for better reusability compared to Spring Boot, at least in our use cases, and allowed us to have a simpler setup for this for our cross-country team”.

As of today, they have about 15 Quarkus microservices, 5 of which went into production at the end of September 2019. With respect to effort, 2 developers were dedicated to work on these first 5 microservices that are now in production running in JVM mode. Presently, their team is working on delivering 20 microservices in the next 3 months. It is worth mentioning that, in their experience, it was very easy for their Spring developers to pick up the Quarkus Java stack because “migrating from Spring Boot to a CDI-based framework didn’t require a lot of effort”, as per Christos.

Although Quarkus includes Spring API compatibility, Vodafone Greece has no plans to use it because “it doesn’t make sense to mix the two programming models in a microservice” according to Christos. In order to keep the code clean, Vodafone Greece is “using only Quarkus constructs without muddying the waters with Spring syntax” as specified by Christos. For their requirements, the Quarkus stack already offers everything they need, so there is no need for any Spring Boot at all.

Vodafone Greece has seen many benefits using Quarkus. One of them is that memory resource consumption was cut in half in JVM mode. In addition, start-up times have been reduced to almost a quarter without any optimization. It is worth mentioning that many of these microservices are complex in that they “have a lot of Kafka and database connections” as described by Christos.

Their logging system, which uses Kafka, utilizes a lot of memory because it handles messages that are large in size and transforms them to JSON. As an example, some microservices required 1 GB of RAM when using Spring Boot. In comparison, for production they can now deploy a Quarkus microservice with 512 MB of RAM. “For 80 microservices, this is big savings!” Christos emphasized and added that “what Quarkus offers by default (without trying to optimize it) is 50%-60% more lightweight (in JVM mode) that what Spring offers after optimizations (taking care of dependencies, playing with JVM options, etc)”. With respect to start-up time, a significant portion of it is spent waiting for message brokers and databases to accept connections, which was making Spring Boot microservices boot up in about 50 seconds. But with Quarkus microservices, boot up in less than a quarter of that time (14 seconds).

The large magnitude of the developer efficiency benefit they experienced was unexpected and a pleasant surprise. First, they realized that migrating from Spring Boot to a CDI-based framework didn’t require a lot of effort for their Spring developers, resulting in a small learning curve. Second, the use of the Quarkus live coding capability (a.k.a. dev mode) resulted in an increase of developer productivity, which Christos described as “a very good thing to have”. For example, each development cycle consists of 1 to 2 sprints (1 sprint = 2-week period) depending on the complexity of the logic being developed, and with Quarkus they saw a “30 to 40% better developer productivity vis-a-vis Spring Boot, and this is for an ex-Spring Boot developer”, according to Christos.

Another Quarkus feature that impressed them was the effectiveness of the way Quarkus uses enterprise Java, e.g. the concise way to use CDI in combination with context propagation for asynchronous methods. It’s not uncommon for a microservice to make calls to other microservices to then aggregate the returned information by other microservices and this worked with Quarkus effortlessly, via the MicroProfile Context Propagation and MicroProfile Reactive Messaging extensions. In fact, “MicroProfile is a good reason why we like Quarkus as a development tool” stated Christos.

As far as next steps, the number of microservices Vodafone Greece has now only covers a small fraction of what they intend to do. They want to double what they have now, in other words, double the number of microservices and the number of developers dedicated to this initiative. To this end, they plan to release 20 Quarkus microservices in the next three months. According to Christos, as they grow, “orchestration and developer productivity will become even more important for the resources they consume”.

Presently, they run Quarkus in JVM mode when interfacing to MongoDB but they are considering using native compilation with MongoDB in the future. When Vodafone Greece started using Quarkus a few months ago, it didn’t include an extension for MongoDB but Quarkus does include a MongoDB client extension now that they could leverage. In addition, they plan to use more Quarkus extensions, like circuit breakers from MicroProfile Fault Tolerance, and more broadly adopt MicroProfile reactive messaging specifications.

Furthermore, notwithstanding that with Quarkus, they have already cut their memory consumption and start-up times in more than half running it in JVM mode, they plan to run their Quarkus microservices in native mode in the future to get even better memory consumption and start-up times.

For more information on Quarkus: