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.

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

Google App Engine(Google Cloud SQL) /ZK/Spring/Hibernate Integration (1)

Demo : doukkani.appspot.com

Google App Engine est une plateforme de conception et d'hébergement d'applications web basée sur les serveurs de Google.

Google Cloud SQL En octobre 2011, Google aperçus une base de données SQL sans entretien, qui supporte JDBC et DB-API². Ce service vous permet de créer, configurer et utiliser des bases de données relationnelles avec les applications App Engine. Moteur de base de données MySQL version 5.1.59 est la taille et la base de données ne doit pas être supérieure à 10 Go ³.

Contexte technologique Le service Google App Engine vient concurrencer ceux d'Amazon nommé Amazon Web Services (AWS) et de Microsoft nommé Windows Azure. Ce sont des lots de services applicatifs qui permettent à une application web de stocker des données et d'exécuter du code sur leurs serveurs respectifs.

Beaucoup d'analystes techniques avaient prédit l'arrivée de Google dans ce créneau. « Google finally realizes it needs to be the web platform » a écrit Mike Masnick, qui publie le blog Techdirt⁴. Source WikiPedia

Scrum : le mécanisme d’inspection et d’adaptation

 

j'ai pris le temps de lire le guide scrum de Ken Schwaber et Jeff Sutherland d'ou j'ai retenu les principes suivants :

Scrum comporte trois activités en ce qui concerne le mécanisme d’inspection et d’adaptation :

1- il y a la mêlée quotidienne (Daily Scrum), qui permet de vérifier l’avancement en regard à l’atteinte du but pour le sprint et d’adapter ce qu’il y a à
faire de manière à optimiser la valeur produite au jour le jour.( Adaptation, optimisation ).

2- La réunion de planification du sprint (Sprint Planning Meeting) et la réunion de revue du sprint (Sprint ReviewMeeting) sont utilisées pour valider l’état d’avancement quant à l’objectif de la livraison courante et pour faire les adaptations qui optimiseront le processus de réalisation du prochain sprint. ( inspection ).

3- La rétrospective du sprint (Sprint Retrospective) permet de passer en revue le sprint qui vient de se terminer et de déterminer les changements à apporter pour que le prochain sprint soit plus productif, enrichissant et agréable pour
toute l’équipe. ( inspection et adaptation ).