Cloud-Native Avec Payara Et Platform.sh

Qu'est-ce que le Cloud ?

Le software est partout. Peu importe où vous regardez, il y a des éléments logiciels. Dans l'histoire de l'humanité, nous avons vu le nombre de machines/logiciels augmenter avec le temps, passant d'une machine partagée par un groupe de personnes à une seule personne utilisant des milliers de programmes logiciels. Aujourd'hui, nous pouvons voir des logiciels interagir avec d'autres, comme lorsque vous achetez un billet d'avion : un système envoie un email, un autre le lit et déclenche un événement dans votre calendrier. Cette nouvelle approche ouvre à tous davantage de perspectives et de possibilités commerciales, y compris le machine learning. Ne vous méprenez pas, Skynet arrive bientôt.

La naissance de l'Agile

Ce n'est pas seulement la quantité de logiciels qui a augmenté, mais aussi le nombre d'interactions dans un même programme. Plus d'utilisateurs, plus d'exigences, plus de retours d'information. Il n'est pas logique d'attendre des années avant de lancer un produit, le délai de mise sur le marché et les commentaires des utilisateurs sont essentiels pour orienter le produit dans la bonne direction. C'est pourquoi en 2001, un petit groupe de personnes, fatiguées de l'approche traditionnelle de la gestion des projets de développement de logiciels, a conçu le Manifeste Agile, qui a donné naissance à le manifeste agile.

Une méthodologie agile aide les équipes à fournir des réponses rapides et imprévisibles au feedback qu'elles reçoivent sur leur projet. Elle permet d'évaluer l'orientation d'un projet au cours du cycle de développement. Les entreprises évaluent le projet lors de réunions régulières appelées sprints ou itérations. Dans un aspect plus technique s'alignant sur la méthode Agile, l'approche de la conception pilotée par le domaine pour le développement de logiciels pour des besoins complexes relie profondément la mise en œuvre à un modèle évolutif des concepts de base de l'entreprise. Des techniques telles que le langage ubiquitaire sont utilisées pour uniformiser le code de l'entreprise, ce qui réduit la barrière entre le développeur et l'utilisateur et, par conséquent, permet d'avoir plus d'interactions qu'avec le développement agile.

Les Microservices

De plus en plus d'entreprises ont compris que toutes les entreprises sont des entreprises de software. En raison de leur forte dépendance à l'égard des logiciels, les entreprises doivent souvent faire appel à des développeurs. La question de savoir comment gérer plusieurs personnes travaillant sur un seul projet se pose alors. Pour résoudre cette question moderne, nous pouvons nous inspirer d'une ancienne stratégie militaire romaine : diviser pour mieux régner. Oui, diviser une question très complexe en petits blocs de problèmes, diviser l'équipe en petits groupes et diviser le projet monolithique en plus petits. Le style architectural des micro-services est une approche qui consiste à développer une seule application en une suite de petits services, de sorte que, par exemple, au lieu qu'une société d'ecommerce travaille avec une seule base de code et une seule implémentation, elle puisse diviser les équipes/code en matière de finances, de stock de produits, de marketing, etc. Une chose à souligner, le contexte DDD est toujours là. En effet, il est parallèle à l'approche visant à créer des services utiles basés sur certains de ses concepts limités ; nous ne rejetons ni ne déprécions cette notion, mais nous l'agrégeons en micro-services.

Les micro-services, en plus de rendre l'équipe plus agile, apportent également plusieurs avantages tels que la mise à l'échelle indépendante et la publication de services sans grands impacts. Cependant, ils comportent plus de péripéties du côté des opérations. Le code finalisé ne suffit pas s'il n'est pas mis en production. Ainsi, les opérations doivent suivre l'équipe de développement pour libérer ce que le système doit déployer chaque jour. C'est là qu’intervient le DevOps : DevOps est un ensemble de pratiques de développement de logiciels qui combinent le développement de logiciels (Dev) et les opérations de technologie de l'information (Ops) pour raccourcir le cycle de vie du développement des systèmes tout en fournissant des fonctionnalités, des corrections et des mises à jour fréquentes en étroite concordance avec les objectifs commerciaux.

Les équipes de développement et d'exploitation étant intégrées et travaillant ensemble selon la méthodologie DevOps, nous sommes prêts à nous occuper des logiciels et des opérations. Mais qu'en est-il du hardware ? L'intégration de l'équipe signifie que le matériel n'existe pas. Que se passe-t-il lorsqu'une équipe a besoin de plus de puissance informatique ? Est-il logique que quelqu'un aille acheter un nouveau serveur ? Ce n'est pas assez rapide. Sur le marché mondial et avec la bataille des millisecondes pour obtenir un temps de réponse plus court, un serveur plus proche du client signifie moins de temps de traitement, mais comment acheter/maintenir des serveurs sur plusieurs continents ?

Avec le cloud computing disponible à la demande pour les ressources du système informatique, en particulier le stockage des données et la puissance de calcul, sans gestion active directe par l'utilisateur, le cloud computing signifie que nous ne nous soucions pas du matériel lui-même. Ces services se divisent en trois grandes catégories : Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) et Software-as-a-Service (SaaS).

Ces catégories apportent un nouveau concept d'entreprise sur le marché. En outre, chaque service apporte de nouvelles facilités, principalement la livraison rapide.

Il existe un article fantastique qui explique les avantages du cloud computing avec comme exemple la nourriture la plus populaire et la plus délicieuse du monde : la pizza ! 

Les avantages de l'IaaS :

• Pas besoin d'investir dans votre propre hardware
• L'infrastructure s'adapte à la demande pour supporter des charges de travail dynamiques

Les avantages du PaaS :

• Développez des applications et mettez les sur le marché plus rapidement
• Réduisez la complexité grâce au middleware as a service

Les avantages du SaaS :

• Les applications et leurs données sont accessibles depuis n'importe quel ordinateur connecté
• Aucune donnée n'est perdue si votre ordinateur portable se casse parce que les informations sont dans le cloud

Un projet software qui a une livraison rapide a la meilleure approche stratégique.  La livraison rapide apporte plusieurs avantages, tels que la réception de feedback, la correction de bugs, et surtout l'orientation du produit dans la bonne direction en fonction des besoins de l'utilisateur. C'est pourquoi plusieurs méthodologies/technologies telles que l’Agile, les microservices, DevOps et le cloud sont nées. Aujourd'hui, il est difficile d'imaginer qu'il faille attendre un an pour lancer un projet, au risque de manquer le bon moment. La communauté de Java a décidé de publier une livraison tous les six mois, et Jakarta EE est en recherche de la même voie. Platform.sh a pour objectif de faciliter le passage de votre projet sur le cloud, vous permettant de le déployer n'importe où et n'importe quand, y compris un vendredi ensoleillé.

Qu'est-ce que le Cloud Native ?

Le cloud computing a apporté de nombreuses méthodologies et techniques qui ont révolutionné à la fois le monde des affaires et le monde technique. Parmi les termes qui sont apparus, il y a celui de "cloud native". Pour répondre et couvrir ces attentes dans l'univers Java, Jakarta EE a émergé.

Comme tout nouveau concept, il existe plusieurs concepts portant le même nom ; si vous lisez des livres ou des articles sur le "cloud native", vous ne trouverez peut-être pas de consensus à ce sujet. Par exemple :

• Le "cloud native" est une approche de création et d'exécution d'applications qui exploite les avantages du modèle de l'informatique cloud. -Pivotal
• Le terme "cloud native" désigne une façon différente de penser et de raisonner les systèmes software. Il incarne les concepts suivants : adopte et repose sur  une infrastructure jetable, avec des composants capables de monter en charge à l'échelle mondiale.  - Architecting Cloud Native Applications
• Dans l'usage général, le "cloud native" est une approche de la création et de l'exécution d'applications qui exploite les avantages du modèle de prestation de services du cloud computing. Le "cloud native" concerne la manière dont les applications sont créées et déployées, et non le lieu. - InfoWorld

Une approche que j'apprécie est celle que j'utilise sur la base de ces livres et articles : le cloud-native est un ensemble de bonnes pratiques pour optimiser une application dans le cloud à travers :

• La conteneurisation
• L’orchestration
• L’automatisation

Dans un consensus mutuel autour des définitions de plusieurs articles, on peut dire que le "cloud native" est un terme utilisé pour décrire les environnements basés sur des conteneurs. Le terme "cloud native" n'est donc pas lié à des langages de programmation ou à des frameworks de travail spécifiques, ni même à un fournisseur de services cloud, mais à des conteneurs.

Quelles sont les meilleures pratiques en matière de cloud-native ?

Lorsque nous apprenons un nouveau concept, nous courons généralement lire les meilleures pratiques pour éviter les erreurs et tout code smell. Avec la programmation orientée objet (POO), nous avons les design patterns du gang of four ; en Java nous avons l'Effective Java, et quand on parle d'architecture, nous avons à la fois le Clean code et la Clean architecture. La question est donc de savoir quelles sont les meilleures pratiques pour le cloud native ?

À notre connaissance, il n'existe pas de meilleures pratiques concernant spécifiquement le cloud-native. Mais comme le cloud est proche de la méthodologie Agile, il existe plusieurs pratiques que nous pouvons exploiter pour avoir une application saine et qui fonctionne :

• Le Manifeste pour le développement software agile
• L’intégration continue
• La livraison continue
• La conception axée sur le domaine

Les pratiques les plus connues liées à toute application incluant du cloud computing sont inspirées de l'ouvrage de Martin Fowler intitulé Patterns of Enterprise Application Architecture and Refactoring.

L'application à douze facteurs

1. Base de code : une base de code suivie dans le cadre du contrôle des révisions, plusieurs déploiements
2. Dépendances : déclarer explicitement et isoler les dépendances
3. Config : stocker la configuration dans l'environnement
4. Services externes : Traiter les services externes comme des ressources annexes
5. Construire, livrer, exécuter : des étapes de construction et d'exécution strictement séparées
6. Les processus: exécuter l'application comme un ou plusieurs processus sans état (stateless)
7. Association de ports : exporter des services via des associations de ports
8. Concurrence : mise à l'échelle via le modèle de processus
9. Jetable : Maximiser la robustesse avec un démarrage rapide et un arrêt gracieux
10. Parité dév/prod : Garder le développement, le staging et la production aussi homogènes que possible
11. Les logs: Traiter les logs comme des flux d'événements
12. Processus administratifs: Exécution de tâches administratives/de gestion sous forme de processus ponctuels

En résumé, il n'existe pas encore de meilleures pratiques spécifiques pour le cloud native, mais il existe des modèles issus de l'Agile, des microservices et de l'application à douze facteurs qu'il est utile de suivre.

Hello World avec Payara Micro et Platform.sh

Dans cette section, nous verrons comment créer votre premier projet REST avec Payara Micro, et le transférer sur Platform.sh en utilisant un archétype Maven, qui est une boîte à outils de modélisation du projet Maven. Un archétype est défini comme un modèle original à partir duquel toutes les autres choses du même genre sont fabriquées. Vous pouvez le générer avec la commande suivante :

mvn archetype:generate -DarchetypeGroupId=sh.platform.archetype -DarchetypeArtifactId=payara -DarchetypeVersion=0.0.1 -DgroupId=my.company -DartifactId=hello -Dversion=0.0.1 -DinteractiveMode=false

L'étape suivante consiste à le convertir en un projet Git, donc :

cd hello
git init
git add .
git commit -m "hello world with Payara"

Enfin, créez un nouveau projet sur Platform.sh, liez le à votre dépôt Git et publiez votre code dans le master. Dès que vous aurez publié ce code dans le master, il générera les conteneurs dont vous avez besoin pour rendre votre application disponible.

git remote add cloud <platform.sh-git-address>
git push cloud master

Dès que nous publierons le code à supprimer, il créera la construction Maven et déploiera l'application. À la fin, il générera l'adresse IP, prendra cette adresse et fera une requête sur le serveur.

curl <ip_server>
 hello from Platform.sh

L'archétype Maven que nous allons générer comprend les dépendances de Maven et les trois fichiers dont Platform.sh a besoin pour déplacer cette application vers le cloud. Maintenant, approfondissons ce fichier et parlons de ces composants un par un. Pour détailler, ces fichiers représentent le concept d'infrastructure as code - le processus de gestion et d'approvisionnement des data centers par le biais de fichiers de définition utilisables par  la machine.

name: app
type: "java:8"
disk: 1024
hooks:
 build:  mvn -DskipTests clean package payara-micro:bundle
web:
 commands:
    start: java -jar -Xmx512m target/microprofile-microbundle.jar --port $PORT

Le fichier de l'application a la configuration nécessaire pour créer son conteneur. Le build est défini par une commande Maven qui crée un uberjar. Pour créer le conteneur d'application, le fichier possède les attributs suivants :

• nom (obligatoire) : définit le nom unique du conteneur de l'application.
• type (obligatoire) : définit l'image de base du conteneur à utiliser, y compris la langue de l'application et sa version.
• disk et mounts (obligatoire) : définit les répertoires de fichiers pour l'application.
• build, dépendances, et hooks : contrôle la façon dont l'application est compilée. Notez que cette compilation a lieu avant que l'application ne soit copiée dans différentes instances, donc toutes les étapes ici s'appliqueront à toutes les instances du web et du worker.
• web : contrôle la façon dont l'application web est servie.

Platform.sh et Payara ont créé un guide utile pour parler de Jakarta EE et du cloud.