Quarkus adoption by APHP (Assistance Publique des Hôpitaux de Paris)

L’Assistance Publique - Hôpitaux de Paris, AP-HP is an internationally oriented university hospital center.

Some numbers (2020) :

Direction des Services Numériques/DEVeloppement

The DSN/DEV  is in charge of developing and maintaining various apps and specific tools. The IT department is as vast as the APHP itself. Dealing with every single medical specialty, it is sometimes difficult to find every needed tool on the market. That’s where the DSN/DEV intervene, creating ultra specialized micro apps. With all these heterogeneous apps, the APHP faces multiple challenges in terms of communication. Once again it is the DSN/DEV job to ensure that every single part is able to communicate properly with each other, regardless of their nature and function. In doing so their job naturally requires mastery over the data stream and the ability to manipulate it in real time.

Historically a vast panel of technologies were used. In the last 10 years, our efforts were oriented toward unification. Today we are currently using only two languages : some PHP development projects for historical reasons and for the rest we are working with Java EE/Angular.

For that last part, our choices leaned toward WildFly/JBoss. We chose to package our applications in a single deliverable containing front end and back end due to the small size and to facilitate deployment. Our front end is rarely evolving, or to be more exact it evolves only when the back end is doing so. This allows our teams to quickly deploy new features. The size of our Information Network (hundreds of major apps and thousands of working instances) makes it so its global evolution is slow paced.

Using containers made us revise our choices. A key point in our decision was to keep working with technologies already mastered by our teams, and thus ensuring that any deployment or development of an app wouldn’t imply a total start from scratch, but rather the use of pre-existing mods. We wanted an evolution and not a revolution.

The DSN/DEV kept close attention to Quarkus while researching other technologies as well. With the release 1.x of Quarkus, it became evident that it would become the tool that would take us in the right direction.

To manage the data stream between our apps, a stream supervisor tool was created, long before we chose to work with Java EE. This tool was based on the servlet specification, and over its 10 years of existence a heavy stratification took place. As it’s still performing properly, this app was chosen as our Quarkus test subject. We could try to develop a replacement and if we encountered any unexpected obstacle we could go back to the existing app.

Our wish was to capitalize on recurring elements. From experience, our teams are able to know what can be reused and where. For a long time, we developed in a modular fashion. Each project being an assembly of mods. We are used to externalizing these mods to independent projects.

We rapidly managed to produce a prototype. Then a partner school was tasked to translate the two basic functions of this app from servlet to Java EE/Angular. Once it was done, we needed to go from Java EE/Angular to Quarkus/Angular. Which took only one week for one person, outside of their regular duties. Quarkus was indeed the perfect tool for the job.

Based on this experience, the project started. The supervising app was nothing more than a big mod cluster. Each mods providing its own function, it became simple to add any needed function by adding a new mod.

We were forced to overcome some limitations such as the Hibernate ORM with Panache extension preventing us from correctly accessing some of our Oracle database. But we managed quite easily to follow Quarkus evolutions and adapt our code to take these evolutions into account.

Regarding Quarkus-Quinoa, which resembles our Angular approach: Because our 10-year-old packaging is still performing perfectly and totally automatized, we chose to not use Quinoa.

One app is good, but the more the better. With all the experience accumulated, we created ready-to-be-used mods and methodologies. As of today we are able to fully develop and deploy an app within 2 weeks.

That experience was the result of the work of the team in charge of supervising apps. The only thing left to do was to share this experience and use it as a base for all. This was done during 2022. And to our satisfaction our Java EE/Angular team adopted this new technology without any difficulty.

Quarkus revealed itself as the perfect tool for our need and the future foreseen by the DSN/DEV. Our team capitalizes on it and wishes to expand its use to other projects. Quarkus is now a core tool for APHP and will continue to be so for the foreseeable future.