1 - Vous réconcilier avec Spring

Je travaille depuis plusieurs semaines avec Spring Boot. Je dois avouer que l’idée de mettre en place ce nouvel outil ne m’enchantait gère. Bien sûr j’avais eu de bons retours mais après plusieurs années, je m'étais lassé de l'écosystème Spring : trop lourd, trop de librairies, trop JEE …​ Je continuais à utiliser Spring dans mes projets plus par habitude que par conviction.

Je dois admettre que Spring Boot est aujourd’hui une évidence pour moi ; c’est le projet qui a rendu à Spring sa simplicité d’origine (et sans XML s’il vous plait).

Prenons l’application REST suivante :

Classe principale
@Configuration
@EnableAutoConfiguration
@ComponentScan
public class Application {

	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);
	}

}
Services REST
@RestController
@RequestMapping("/api")
public class RestServices {

	@RequestMapping(method = RequestMethod.GET)
	public
	@ResponseBody
	String ping() {
    	return "{\"status\":\"OK\",\"timestamp\":\"" + System.currentTimeMillis() + "\"}";
	}

}

Voilà, c’est tout !

En effet, plus de configuration XML, plus de déclaration de beans à rallonge, plus de web.xml. Tout n’est pas nouveau bien sûr (configuration Java notamment) mais Spring Boot à pousser la logique de simplification entamée par Spring depuis plusieurs années à son maximum.

En effet, nous avons ici une application web complète qu’il est possible de lancer dans la foulée (oui sans serveur d’application…​en apparence, nous y reviendrons) :

...
2015-05-27 14:28:49.114  INFO 50883 --- [ost-startStop-1] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 2102 ms

avec le test correspondant :

~$ curl http://localhost:8080/api
{"status":"OK","timestamp":"1432733392861"}

2 - KISS ("Keep It Simple, Stupid")

S’il fallait résumer Spring Boot par un seul mot, ce serait "Simplicité". Spring Boot a été conçu pour rendre la vie du développeur plus simple et lui permettre de se concentrer sur le coeur de l’application et non pas sur les aspects annexes : configuration, tests, sécurité, déploiement…​

L’ensemble de ces problématiques techniques sont bien sûr prise en charge par Spring Boot mais sont réduites à leur strict minimum. Quand on débute avec Spring Boot, on le ressent tout de suite et cela continue également jusqu'à la mise en production qui est également simplifiée comme nous le verrons plus loin (déploiement, profils …​).

Prenons la configuration ; la configuration complète par défaut de l’application se résume à l’annotation @EnableAutoConfiguration. Cette annotation va alors s’appuyer sur l’ensemble des dépendances de l’application (MVC, Tomcat, …​) pour configurer l’application.

Dans un second temps, il est possible d’amender cette configuration par défaut. Prenons par exemple le port HTTP ; par défaut, celui-ci est associé à la valeur 8080. Pour affecter un port différent, il suffit d’ajouter un fichier application.yml (ou .properties) à l’application avec le contenu suivant :

server:
  port: 9090

Cette nouvelle configuration est prise en compte lors du prochain démarrage :

2015-05-27 16:39:32.236  INFO 51056 --- [main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port(s): <strong>9090</strong> (http)
2015-05-27 16:39:32.426  INFO 51056 --- [main] o.apache.catalina.core.StandardService   : Starting service Tomcat
2015-05-27 16:39:32.428  INFO 51056 --- [main] org.apache.catalina.core.StandardEngine  : Starting Servlet Engine: Apache Tomcat/8.0.20

3 - Parler Micro-Services c’est bien, en faire c’est mieux

Je ne ferai pas de présentation des Micro-Services ici mais constatons que ces derniers ont cette facheuse tendance à faire parler les gens plutôt qu'à les faire coder (ben oui, "coder, c’est sale"). Il partage d’ailleurs ce biais avec son lointain ancêtre/collègue/"mettez ce que vous voulez" SOA. Il faut dire qu'à l'époque SOA (il y a 5-10 ans donc), il fallait faire avec SOAP, les ESB (EAI rebrandés) et autre Messaging préhistoriques ; il valait mieux en parler qu’en faire.

Mais maintenant tout n’a pas changé mais nous avons enfin les technologies nous permettant de mettre en place l’ensemble des architectures/solutions rêvées il y a quelques années (relisez <a href="http://shop.oreilly.com/product/9780596006754.do">Entreprise Service Bus</a> : le livre a plus de 10 ans, si c’est pas du MicroServices, ça y ressemble).

Plus d’excuse pour ne plus en faire : Spring Boot est un très bon point d’entrée pour mettre en oeuvre une architecture MicroServices : simplicité, légèreté …​

4 - Plus besoin de script de gestion des environnements

Oui vous savez cette saleté de script que vous maintenez depuis plusieurs années qui copie/colle des propriétés dans des templates de configuration, ces templates pas à jour.

Spring Boot reprend bien entendu le principe de profils apparu il y a plusieurs années dans Spring mais le rend plus simple à mettre en oeuvre (on se répète).

Il est ainsi possible d’amender n’importe quel composant (@Component) ou configuration (@Configuration) afin de les associer à un ou plusieurs profils et ainsi de les "activer" ou non selon le profil actif. Celapeut-être notamment utile pour activer des services "mockés" pour les profils de test.

Il est également possible de "superposer" au fichier de configuration par défaut un fichier de configuration par profil afin d’ajouter ou de surcharger des propriétés.

Par exemple, prenons la configuration par défaut suivante (application.yml) :

server:
    port: 9090

et le configuration de test suivante (application-test.yml) :

server:
    port: 9292
logging:
    level:
        org.springframework: DEBUG

Si nous lançons l’application sans paramètre supplémentaire, la première configuration sera appliquée : port HTTP = 9090 et level log = INFO (valeur par défaut de Spring Boot) ; par contre, si nous lançons l’application avec le paramètre suivant --spring.profiles.active=test, alors la configuration suivante sera appliqué : port HTTP = 9292 et level log = DEBUG.

5 - Plus de serveur d’application…​ou presque

Finie la galère du déploiement avec Spring Boot. En effet, bien qu’il soit possible de packager de manière classique votre application dans un fichier war pour le déployer au sein de votre serveur d’application imposé chéri, le packaging par défaut un jar "self-contained" (jar exécutable contenant l’ensemble des dépendances de l’application).

Ce jar contient notamment l’ensemble des librairies Tomcat (ou Jetty - ce sont les seuls containeurs gérés par défaut) permettant de lancer le serveur d’application nécessaire à l’exécution de l’application.

Bien sûr, il n’est pas évident de se faire à cette idée après plusieurs années de déploiement lourd sous containeur mais cela à de nombreux avantages :

  • Simplicité de déploiement (le seul prérequis est Java).

  • Cloud-ready.

  • Contournement des référentiels système - il est courant que l’on vous impose un serveur d’application (pas le plus léger normalement), il est plus rare que l’on vous empêche de lancer un simple processus Java.