Cyrille Le Clerc et Pablo Lopez ont le plaisir de vous inviter Jeudi 14 Avril à 19h00 pour une « Soirée Monitoring d’Applications Java avec le Fondateur et CTO d’AppDynamics » .
Nous avons profité du passage en Europe de Jyoti Bansal pour organiser avec les équipes d’AppDynamics un événement autour du monitoring de la « vraie vie » .
A l’heure où l’architecture des applications d’entreprise devient de plus en plus complexe et distribuée, l’outillage dans le domaine du monitoring et du troubleshooting est un élément clé du système d’information. Notre objectif est que chacun en retire des idées immédiatement applicables et se forge une vision des problématiques que les systèmes de monitoring gèrent aujourd’hui et traiteront demain.
Après avoir consulté des Dev et des Ops des secteurs Telcos, Finance, Retail et Voyage, nous avons établi un programme reprenant des cas de notre vie quotidienne illustrés dans une application transactionnelle de eCommerce « réaliste » (1) que nous avons déployée en cluster sur 5 serveurs Amazon EC2., que nous soumettrons à diverses déconvenues courantes.
Lire la suite de cet article »
Après avoir abordé la gestion des fichiers de logs, nous continuons aujourd’hui la série « Applications Java prêtes pour la Production » avec l’audit.
Par audit, nous entendons l’audit des actions importantes réalisées sur une application.
Pourquoi auditer ?
Est-il vraiment utile de générer des informations d’audit dans nos applications ? Sans explications de juriste, quelques exemples suffiront à nous en convaincre :
- Un site web de partage de photos doit pouvoir dire qui a uploadé quelle image, depuis quelle adresse IP et à quelle date.
- L’application d’administration d’un site de e-commerce doit tracer toutes les modifications de prix pour empêcher un employé astucieux de baisser à 1 euro le prix de son téléphone préféré le temps de passer commande.
Pour revenir à des explications plus théoriques, les logs d’audit nous apportent :
- les informations nécessaires à la justice en cas d’infraction,
- la détection d’intrusions,
- la reconstitution des événements en complément des logs d’exceptions pour aider au diagnostique de problèmes.
Nous nous placerons dans le cas le plus fréquent où nous ne développons pas d’outil pour consulter ces informations d’audit et où un accès direct au média de stockage (grep sur fichier texte, sql sur base de données, etc) suffit.
Lire la suite de cet article »
Tout a déjà été dit sur les logs. Pour preuve, ce n’est plus un sujet chaud, les équipes d’exploitation sont très contentes avec les logs de nos applications 
.
D’accord, l’envers du décor est moins reluisant et il reste une marge de progression. Nous avions proposé dans Les 10 commandements des logs applicatives des suggestions focalisées sur le contenu des fichiers de logs ; voici aujourd’hui des propositions pour gérer les fichiers eux-mêmes. Même si le sujet peut sembler trivial, ces bonnes pratiques peuvent grandement simplifier le quotidien des équipes de production et améliorer les relations tumultueuses entre exploitants et développeurs.
Au risque de surprendre certains, les exemples de ce billet utilisent Logback plutôt que le standard de-facto Log4j car certaines bonnes pratiques que je proposerai sont impossibles à mettre en oeuvre avec Log4j. Aujourd’hui, je préfère utiliser Logback à Log4j pour gérer les logs de mes applications … même si je suis nostalgique du format ‘.properties’ pour la configuration de ces dernières .
Bien que Logback ne soit pas le sujet de ce billet, j’ai ajouté à l’article initial un paragraphe « Pourquoi je préfère Logback à Log4j » pour expliquer ce choix.
Lire la suite de cet article »
Xebia a le plaisir d’accueillir le deuxième KawaCamp dans ses locaux jeudi 27 Mai 2010.
Qu’est ce qu’un KawaCamp ? C’est un BarCamp dédié aux sujets qui gravitent autour de l’écosystème Java ! Et qu’est-ce qu’un BarCamp alors ? Pour résumer voici la définition de Wikipedia. Nous allons nous retrouver entre passionnés pour discuter de sujets qui nous tiennent à coeur autour de tables rondes/ateliers durant lesquels chacun participe et donne son point de vue.
Les sujets sont choisis grâce aux centres d’intérêts que chacun exprime sur la page d’inscription. Cette session s’oriente vers les sujets d’actualité avec beaucoup de HTML5 et d’Android sans oublier NoSQL, TDD, Agilité, …
Si vous aimez les discussions passionnées autour d’un verre, le KawaCamp vous comblera en organisant nos débats !
Informations pratiques :
Ils en parlent :
Dans notre article sur l’utilisation de HTTPS avec Tomcat en production, nous avons étudié les solutions reposant sur la mise en place d’un reverse proxy HTTP. Nous n’avons pas oublié pour autant le protocole AJP. Ce protocole est né pour faciliter et accélérer les communications entre un serveur web frontal et le serveur d’application JServ en back-end d’Apache. Avec le temps, Tomcat a remplacé Apache JServ mais AJP est resté. Jusqu’en 2003, AJP était la seule solution viable permettant de placer le serveur d’application derrière un serveur Apache. Avec la maturation de la fonctionnalité Proxy dans Apache est née la solution tout HTTP. Nous avons donc décidé d’organiser un match opposant la solution AJP à la solution HTTP.
Lire la suite de cet article »
Suite à vos retours nombreux, aux différents articles touchant à la sécurisation par SSL de Tomcat en production (Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header HTTP X-Forwarded-For, Sécuriser Tomcat 5 derrière un proxy Apache 2 HTTPS), nous commençons une série sur Tomcat en production.
Dans ce premier article, nous abordons l’utilisation de SSL pour sécuriser les communications. Pourquoi utiliser SSL ? Comment SSL est-il intégré avec le moteur de Servlet ? Et surtout quelle configuration correspond à votre application, qu’elle soit hébergée sur un serveur Tomcat seul, avec un serveur Apache Httpd en frontal, avec un accélérateur SSL ou avec un load-balancer hardware.
Lire la suite de cet article »
Après Tomcat qui rentrait cet été de plain-pied dans l’univers du Java Platform as a Service avec le mariage de SpringSource à VMWare et à CloudFoundry, c’est au tour de l’autre moteur léger de servlets, Jetty/Webtide, de s’adosser à un acteur du Cloud Computing, Intalio, pour développer son offre.
Une reconnaissance méritée
C’est une très belle opportunité pour Jetty qui était jusqu’à présent beaucoup plus embarqué que Tomcat par des grands projets de Cloud Computing (Google App Engine, Hadoop, Gigaspace XAP, etc) mais n’avait pas constitué sa propre offre.
Sur les pas d’Amazon ?
Le mariage d’Intalio avec Webtide est assez différent de celui de SpringSource avec VMWare et Cloud Foundry. Alors que la deuxième union concerne des spécialistes de l’infrastructure, Intalio est lui issu de l’univers des applications CRM et s’étend vers les infrastructures de Cloud Computing comme l’a fait Amazon auparavant.
Des serveurs J2EE lourds absents
Nous remarquerons à l’occasion que les serveurs J2EE heavyweight se font très discrets dans cette période d’avalanche d’annonces sur Java Platform as a Service, on peut s’attendre à ce qu’ils répondent sur cette tendance qui va bouleverser les modes de fonctionnement dans les data centers et menacer leurs parts de marché.
Ils en parlent
SpringSource continue à dérouler son plan de Java Platform As A Service avec le rachat de Cloud Foundry, le spécialiste de plate-forme Apache / Tomcat / MySQL sur Amazon EC2.
Rod Johnson annonce dans SpringSource Launches Enterprise Java Cloud que SpringSource offrira à ses clients non seulement la possibilité de déployer sur le cloud public Amazon EC2 mais aussi et surtout sur des clouds privés.
Il s’agira vraisemblablement de la mutualisation de nos plates-formes Java actuelles avec un chef d’orchestre Hyperic et des serveurs tc Server (Tomcat augmenté de fonctionnalités d’administration) ; la JVM sera Sun HotSpot et l’OS de prédilection sera RehHat Enterprise Linux (RHEL) même si Windows, Solaris et MacOSX seront proposés (détails ici).
Il ne nous faudra que quelques minutes pour déployer de nouvelles applications web ou pour ajuster les ressources CPU et mémoire allouée à une application par l’ajout ou la suppression de nœuds dans un cluster.
Techniquement, il n’y a pas de rupture par rapport à ce qu’offrent depuis longtemps les serveurs JEE « lourds » (IBM WebSphere, Oracle/BEA Weblogic, RedHat JBoss App Server ou Sun Glassfish).
Cependant, les mentalités ont changé, les esprits sont marqués par la simplicité d’exploitation des Public Clouds. Les équipes d’exploitation sont en train de se transformer, les processus s’allègent et l’offre lightweight de SpringSource tombe à point nommé.
Et la virtualisation matérielle dans tout ça ? Rod Johnson nous dit que la Tomcat Platform As A Service s’exécutera « aussi sur vSphere », le produit phare de son récent acquéreur VMWare. La nuance est forte entre « aussi sur » et « principalement sur ».
Nous le verrons à l’usage, le duo RHEL / Sun JVM sera la couche d’abstraction suffisante pour exécuter la plupart de nos applications Java. Le renfort de la virtualisation matérielle ne se justifiera que dans un nombre limité de cas comme les serveurs J2EE s’avèrent rarement nécessaire face aux simples Tomcat, Jetty ou Glassfish V3 …
Pourquoi VMWare a racheté SpringSource dont le métier et la culture sont si différents ? Pourquoi un tel prix ?
Mon analyse est que VMWare a racheté SpringSource parce que le cloud computing de forme Platform As A Service (PaaS) à la Google App Engine va bientôt mieux répondre que la virtualisation matérielle aux besoins d’optimisation des data centers Java. Selon l’adage « Si quelqu’un scie la branche sur laquelle je suis assis, mieux vaut que ce soit moi », VMWare s’est dotée de l’expertise de SpringSource sur Tomcat et Hyperic.
Je parlerai des applications Java légères (Servlets, JDBC, JPA et JMS) qui sont aujourd’hui largement majoritaires dans nos data centers Java. Billy Newport, IBM WebSphere, reconnait qu’elles représentent 80% des cas, SpringSource aurait sûrement des chiffres plus élevés.
Lire la suite de cet article »
Depuis le rachat de Covalent en Janvier 2008, SpringSource est le premier contributeur au projet Apache Tomcat avec plus de 80% des commits ; Mark Thomas et Philip Thomas en sont les principaux acteurs.
Tomcat est la pierre angulaire de l’offre middleware de SpringSource aujourd’hui composée de tc Server, une version professionnelle Open Source de Tomcat et dm Server, un serveur OSGi (le format d’assemblage que SpringSource préfère aux classiques .war).
Mark Thomas a présenté lors de SpringOne 2009 : Securing Apache Tomcat For Your Environment les points essentiels sur ce sujet qui se décompose en trois thèmes : la confidentialité, l’intégrité et la disponibilité.
Lire la suite de cet article »
Complet
Twitter
