Road to the Cloud (3) : Monolith Vs Microservices Applications (1)

Road to the Cloud (3) : Monolith Vs Microservices Applications

Monolithic architecture (monolithic architecture pattern)

"une seule brique avec tout les services ... et un seul WAR"

Avantages :

- Simple

- La scalabilité est obtenue à travers un cluster / load balancer

Inconvenants : 

- Le code source devient énorme a travers le temps donc difficile a lire et a comprendre ... le développement devient lent, l’environnement de développement aussi.
- Comme l'application devient énorme l’intégration continue doit être moins fréquente car il faut compilé et déployé tout le code.
- La scalabilité devient difficile car elle peut ce faire uniquement en verticale donc achat des serveurs plus performants.
- A long terme l'entreprise va être forcé à utiliser les mêmes technologies car puisque l'application devient énorme le coût du changement de technologie devient grand.

Microservices architecture (microservices architecture pattern)

"plusieurs briques indépendantes avec un système de communication entre eux ... plusieurs WARs"

Avantages :

- Une scalabilité horizontale et verticale (déploiement sur un ou plusieurs serveurs/JVMs.)
- Facile à comprendre et à gérer car chaque partie du code est presque indépendante.
- Le développement devient plus rapide car l'utilisation de l’environnement de développement et déploiements/tests deviendrons plus rapides.
- Chaque application peut être développé/amélioré et déployé indépendamment des autres.
- Les problèmes rencontrés en "run-time" sur une brique n'affecterons pas tout le système donc ça augmente la disponibilité.
- L'obligation de garder la même technologie au fil du temps n'est plus d'actualité.

Inconvenants :

- Nécessite une bonne coordination entre les équipes qui travaillent sur différentes briques.
- Il faut développer et gérer un système de communication entre les briques.
- Des scénarios de tests plus complexe.
- La transformation des transactions distribuées en use cases est assez difficile.
- Complexité de gérer et déployé des briques avec peut être différentes technologies.


Une solution pour l'existant

Pour les applications existantes qui souffrent de problèmes de scalabilité et lenteur ce qu"on peut retenir c'est que à un moment le coût de la scalabilité verticale va explosé (upgrade des serveurs pour gérer la demande qui augmente avec le "computing everywere" ...)


La solution est de faire sortir la ou les briques qui consomment le plus de ressources a fin de pouvoir les déployées séparément.

La séparation doit se faire au niveau du code aussi a fin de pouvoir l'améliorer et changer les technologies utilisées pour augmenter la performance.

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Le pourquoi: Assurer l’intégration, la performance, et la qualité du code avec les outils suivants : 

Jenkins (un "fork" open source de hudson / outil d'intégration continue).
JUnit (tests unitaires).
JMeter (test de charges).
PMD (la définition de nombreux règles qui assurent la qualité de code).

Maven (La gestion des dépendances et automatisation de la production).

A chaque "build" l'application est compilée, analysée ,testée (JUnit), déployée et re-testée (JMeter).

Les résultats des analyses sont disponible juste après :

PMD :

JMeter :

JUnit :

Maven permet d'automatiser le tout en définissant un ou plusieurs fichiers POM (pom.xml) qui contient le nom du projet, le numéro de version, les dépendances vers d'autres projets, les bibliothèques nécessaires à la compilation, les noms des contributeurs etc.

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>spring</artifactId>
<version>0.0.2-SNAPSHOT</version>
<packaging>war</packaging>
<name>test</name>

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.1.6.RELEASE</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>WebContent\WEB-INF\web.xml</webXml>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat6-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<url>http://localhost:8090/manager</url>
<server>TomcatServer</server>
<path>/SpringMavenCLITest</path>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<targetJdk>1.6</targetJdk>
<linkXref>false</linkXref>
<failOnViolation>false</failOnViolation>
<failurePriority>1</failurePriority>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
<goal>cpd-check</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>1.10.1</version>
<executions>
<execution>
<id>jmeter-tests</id>
<phase>verify</phase>
<goals>
<goal>jmeter</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.11</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>2.12</version>
</dependency>
</dependencies>
<configuration>
<includes>
<include>**/*.class</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>2.3</version>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<linkXRef>false</linkXRef>
<targetJdk>1.6</targetJdk>
<rulesets>
<ruleset>/rulesets/basic.xml</ruleset>
</rulesets>
</configuration>
</plugin>
</plugins>
</reporting>

</project>

 Pour finir il faut configurer jenkins pour démarrer notre intégration continue.

Road to the Cloud (2) : Twelve-Factor Applications

Road to the Cloud (2) : Twelve-Factor APP

Le "Twelve-Factor App" est un ensemble de design patterns qui déterminent si une application à une architecture "cloud-native" donc architecturalement destiné à profité des avantages que propose le cloud c-a-d rapidité robustesse et scalabilité.

Codebase

Un dépôt centralisé et unique avec gestion de version et multiples déploiement (plusieurs versions peuvent être déployées au même temps).


Dependencies

La gestion des dépendances via un outil approprié ex: Maven, NPM ...

Config

La configuration, ou tout ce qui est susceptible de différer entre
des environnements de déploiement est injecté via des variables d'environnement au niveau du système d'exploitation.

Backing services

Les services de sauvegarde (ex : base de données ...) doivent être considérés comme ressources attachées et consommées dans tous les environnements de la même façon.

Build, release, run

Les processus "Build/release/run" doivent être séparés et indépendants.

Processes

L'application doit s'exécuté comme un ou plusieurs "stateless process" qui ne partagent absolument rien entre eux. toute relation possible doit être externalisée (ex cache, base de données).

Port binding

L'application doit être "self-contained" (tout les composants nécessaires doivent être packagés/emballés dans même installation)  et expose tous ces services via "port binding".

Concurrency

Les processus doivent être "mis à l’échelle" horizontalement à fin de résoudre les problèmes de concurrences.

Disposability

La robustesse est garanti à travers des processus qui redémarre rapidement et se termine correctement.

Dev/prod parity

Les environnements Dev, Pré Prod  et Production doivent être très proche voir similaire.

Logs

Au lieu de gérer des fichiers logs, il faut gérer les logs autant qu'événements stocker centralement pour indexation et analyse.

Admin processes

Les tâches administratives ou de gestions, tels que les migrations de bases de données, sont exécutés en tant que processus ponctuels "one-off" dans des environnements identiques.