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 (1) : NoSQL / Hibernate OGM (Object/Grid Mapper)

Road to the Cloud (1) : NoSQL / Hibernate OGM (Object/Grid Mapper)

Le 2015-02-27 a connu le lancement de la version stable du framework Hibernate pour les bases de données NoSQL appelé Hibernate OGM le but est de porté la facilité de développement JPA au monde NoSQL ainsi les développeurs familiarisés avec JPA n'aurons aucun problème à changer de cape.

Le pourquoi : une scalabilité horizontale et évolutivité.

- Un schéma flexible capable d'accepter les changements plus facilement (Evolution).

- Un système facilement distribué sur plusieurs serveurs. (le besoin supplémentaire en stockage ou en montée en charge se traduit simplement par l’ajout de nouveaux serveurs).

Donc si vous visez de porter votre application vers le cloud et d'avoir des milliers d'utilisateurs (Données) a moindre coût le choix du NoSQL est obligatoire.

L'architecture Hibernate OGM permet l'utilisation des requêtes JP-QL en les transformant en requêtes DataStore donc le développeur n'aura pas a écrire des requête NoSQL, donc même réutiliser l'existant.

La définition des beans avec annotations JPA/EJB3 reste la même sauf l'introduction de hibernate search qui pourra aussi être un autre moyen de recherche.

Exemple de requête JP-QL simple : 

                EntityManager emSearch = emf.createEntityManager();
Query query = emSearch.createQuery("from Data d where d.name like :name")
.setParameter("name", "XXX%");

Exemples de requête DataStore Ex: MongoDB: 

- Update du montant :
db.Data.update({ "_id" : NumberLong(351) },{ "$set" : { "montant" : "1" } },false, false )

- Delete par ID :
db.Data.remove({ "_id" : NumberLong(143) })

- Recherche Par ID : 
db.Data.find({ "_id" : NumberLong(143) })


- Insert des données :
db.Data.insert({"_id" : NumberLong(131300),"montant" : "0.16364626911022928101857587535050697624683380126953125","description" : "Description2134956245","name" : "Name170565634","date" : ISODate("2015-04-17T10:36:46.583Z"),"parent_id" : NumberLong(13118),"rows" : [NumberLong(13123),NumberLong(13122),NumberLong(13125),NumberLong(13124),NumberLong(13127),NumberLong(13126),NumberLong(13129),NumberLong(13128),NumberLong(13119),NumberLong(13121),NumberLong(13120)]})

- Recherche par champs Name :
db.Data.find({ '$query' : { "name" : "Name-414524582" ,  "_id" : NumberLong(13) }})

- Recherche ID >13 et ID < 130  :
db.Data.find({ '$query' : { "_id" : { $gt: NumberLong(13), $lt: NumberLong(130) } }})

- Recherche par objet incorporé :
db.Data.find({"location.y" : "Y-400967006"} )

Les bases de données suivantes sont supportées : couchDb, mongodb, ehcache, infinispan, neo4j.

Pour l'exemple nous allons utilisé la base données MongoDB :

- Installation MongoDB : http://docs.mongodb.org/manual/installation/

Pour la visualisation les données le plugin eclipse MonjaDB :

- Installation MonjaDB : http://marketplace.eclipse.org/content/monjadb

Le Fichier Persistence.xml : 

Télécharger l'exemple : Test APP

Websphere Application Server ( WAS 8.5 ) : Probléme d'upload (multipart/form-data)

L'erreur : FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Async operation timed out


Problème des timeouts (FileUpload) :

- Pour tester sur tomcat il faut changer les paramètres suivants car ils sont semblables aux paramètres WAS :
      
connectionUploadTimeout="XXXX" disableUploadTimeout="false"  connectionTimeout="XXX"
- Pour WAS il faut augmenter le Read timeout. (180)

Lien : Documentation WAS

L'organisation des réunions en Mode Agile.

Sauver vos réunions

Dans tout travail du groupe les réunions sont très importantes pour définir/réajuster les buts et motiver/sensibiliser les participants mais la question se pose pourquoi certaines réunions n'ont pas un effet bénéfique sur le groupe et peuvent au contraire avoir un effet négatif voir même démotivant.

En Mode Agile où les Groupes sont appelés "Équipes" et dans environnement Agile tel que Scrum ou KanBan, les réunions sont très utilisées pour synchroniser/motiver les coéquipiers donc elles sont très importantes voir critiques.





Quelques facteurs psychologiques et organisationnels qui freinent le bon déroulement des réunions :

• Le phénomène du GroupThink "La pensée du groupe".
• La mauvaise préparation, le manque de détail, l'obscurité des buts.
• Le manque de participation des membres d'équipe.
• La pression de la conformité.
• Le manque d'esprits critiques.
• Le manque d'imagination.

Les solutions possibles :

• Placez la décision finale dans la main d'une seule personne qui sera responsable du choix.
• Choisir un membre de l'équipe qui a un esprit critique et qui va critiquer et mettre en évidence toutes les idées présentées pendants la réunion ainsi permettre au autres de participer librement sans se soucier d'être le premier à critiquer.
• Mettre à la disposition un moyen anonyme (Boîte a idées ou commentaires online) pour réagir et critiquer ou mêmes voter pour des solutions.
• La préparation en avance de toutes les phases de la réunion.
• Avoir un but précis abordable dans la limite des moyens.
• Avoir un plan d'action.
• Essayer d'avoir une interaction physique des participants : des notes sur un tableau ...
• Avoir un temps précis pour chaque phase de la réunion.
• Sortir avec des solutions précises, définir le thème de la nouvelle réunion,et publier les résultats.

Pour conclure, les réunions sont la clé pour motiver vos troupes, et de ce re-concentrer sur les buts notamment le succès de votre équipe, donc soyez très sensible aux résultats de vos réunions.

"Quand vous entendez que des OUI de vos troupes Il faut savoir que l'échec est proche".

Article de Doukkani Amine, Visitez mon profile Viadeo.