HATEOAS, nouvelle approche des APIs, nouveaux cas d’usage

HATEOAS, nouvelle approche des APIs, nouveaux cas d’usage

HATEOAS, nouvelle approche des APIs, nouveaux cas d’usage

Les APIs sont au centre du Système d’Information et du business des entreprises. Et qui dit API dit très souvent REST. Après avoir énoncé un bref récapitulatif de l’architecture REST et de ses contraintes, nous nous attarderons plus spécifiquement sur l’une d’entre elles, HATEOAS. Au travers de cet article, nous verrons que HATEOAS propose de nombreux avantages et cas d’usages pertinents, et que son implémentation améliore grandement la communication entre le client et le serveur. Cependant HATEOAS est encore peu répandu au sein des APIs REST, et ce pour plusieurs raisons que nous verrons également.

HATEOAS dans le modèle de Richardson

REST appliqué au protocole HTTP, ça donne quoi ?

Nous allons nous intéresser dans la suite de cet article aux APIs qui reposent sur le principe de l’architecture REST, que nous appelons les APIs REST.

Afin de juger du niveau de conformité d’une API aux contraintes de l’architecture REST, il existe un modèle appelé modèle de Richardson. Ce modèle est composé de 4 niveaux qui introduisent progressivement les grands principes REST (ressources, verbes et codes HTTP, contrôles hypermédias).

Le niveau 0 : RPC

A ce niveau, HTTP est uniquement utilisé comme protocole d’échange entre le client et le serveur. L’API exposée ne comporte qu’un unique endpoint, par exemple :
http://api.nexworld.fr/v1/services
L’objectif de la requête est contenu dans le flux envoyé (dans les headers ou directement dans le corps du message). Le verbe POST est systématiquement utilisé et la réponse envoyée par le serveur est toujours accompagnée du code HTTP 200, en cas de succès comme en cas d’erreur. Ce niveau RPC s’apparente au protocole SOAP. Requête du client :

POST http://api.nexworld.fr/v1/services
{
    « action » : « getCustomer »,
    « id » : « 1111 »
}

Réponse du serveur en cas de succès :

HTTP/1.1 200 Success
{
    « id » : « 1111 »,
    « lastname » : « Dupond »,
   « contracts » : [
        {« id » : « 123 »},
        {« id » : « 124 »}
    ]
}

Réponse du serveur en cas d’erreur :

HTTP/1.1 200 Success
{
    « error_code » : « INT_ERROR »,
    « error_reason » : « Internal server error »
}

Le niveau 1 : Les ressources

Au niveau 1 du modèle de Richardson, la notion de ressource est introduite. Une ressource est une représentation d’un objet métier. Chaque ressource est atteignable via une URI spécifique. Tout comme au niveau 0, le verbe POST est systématiquement utilisé et le serveur envoie toujours un code HTTP 200. Requête du client :

POST http://api.nexworld.fr/v1/customers/1234/contracts
{
    « action » : « GET »
}

Réponse du serveur en cas de succès :

HTTP/1.1 200 Success
{
    « id » : « 1111 »,
    « lastname » : « Dupond »,
    « contracts » : [
        {« id » : « 123 »},
        {« id » : « 124 »}
    ]
}

Réponse du serveur en cas d’erreur :

HTTP/1.1 200 Success
{
    « error_code » : « INT_ERROR »,
    « error_reason » : « Internal server error »
}

Le niveau 2 : Les verbes et les codes HTTP

Le niveau 2 du modèle de Richardson introduit la notion de verbes et de codes HTTP.

Dans le protocole HTTP, il existe une dizaine de verbes (ou méthodes) qui représentent les actions à effectuer sur les ressources. Les plus connus et utilisés sont GET, POST, PUT, DELETE et PATCH.

En fonction du traitement de la requête, le serveur répondra avec un code HTTP différent. Il existe 5 grandes familles de code HTTP :

  • 1XX : information
  • 2XX : succès
  • 3XX : redirection
  • 4XX : erreur côté client
  • 5XX : erreur côté serveur

Requête du client :

GET http://api.nexworld.fr/v1/customers/1234/contracts

Réponse du serveur en cas de succès :

HTTP/1.1 200 Success
{
    « id » : « 1111 »,
    « lastname » : « Dupond »,
    « contracts » : [
        {« id » : « 123 »},
        {« id » : « 124 »}
    ]
}

Réponse du serveur en cas d’erreur :

HTTP/1.1 500 Internal Server Error
{
   « error_code » : « INT_ERROR »,
   « error_reason » : « Internal server error »
}

Le niveau 3 : HATEOAS

Avec le niveau 3 du modèle de Richardson, nous allons commencer à parler de HATEOAS (Hypertext As The Engine Of Application State). Que se cache-t-il derrière ce nom barbare ? Le principe HATEOAS introduit tout simplement des transitions possibles entre les différents états d’une même ressource, ainsi qu’entre les ressources elles-mêmes.

Ainsi, les requêtes sont les mêmes qu’au niveau précédent, mais les réponses sont enrichies avec des liens hypermédias qui fournissent ces fameuses transitions.

Voici un exemple.

Requête du client :

GET http://api.nexworld.fr/v1/customers/1234/contracts

Réponse du serveur en cas de succès :

HTTP/1.1 200 Success

{
   « id » : « 1111 »,
   « lastname » : « Dupond »,
   « links » : [
      
{
           
« rel » : »contract »,
           
« method » : « GET »,
           
« href » : “/contracts/123″
       
},
       
{
           
« rel » : »contract »,
           
« method » : « GET »,
           
« href » : “/contracts/124″
        
}
    
]
}

Dans cette réponse, le client récupère des liens hypermédias qui lui permet d’accéder aux contrats du customer.

Réponse du serveur en cas d’erreur :

HTTP/1.1 500 Internal Server Error
{
   « error_code »: « INT_ERROR »,
   « error_reason » : « Internal server error »
}

HATEOAS, un niveau trop peu atteint

HATEOAS est le niveau de maturité le plus important du modèle de Richardson. D’après ce modèle, une API est mature sur les principes REST si elle répond à toutes ces conditions :

  • Utilisation des ressources
  • Utilisation des codes HTTP
  • Utilisation des verbes HTTP
  • HATEOAS

Aujourd’hui, si beaucoup d’APIs respectent les 3 premiers niveaux du modèle de Richardson, une faible proportion ont atteint le dernier niveau HATEOAS. Il est intéressant de s’interroger pourquoi.

Nous allons voir dans la suite de cet article les cas d’usages où l’utilisation de HATEOAS est pertinente, ainsi que les avantages et les inconvénients à utiliser une telle implémentation dans les APIs REST.

Cas d’usages

Voici quelques exemples de cas d’usages de HATEOAS.

La pagination

Dans le cas d’une API permettant de remonter une liste d’objets, comme une liste de clients, l’utilisation d’une pagination peut s’avérer utile voir recommandée. En effet, il est possible que la liste remontée par le serveur comporte un très grand nombre d’éléments. Afin d’éviter par exemple une surcharge réseau, la pagination permet de réduire le nombre d’éléments remontés par l’API. Voici un exemple de réponse d’API mettant en place la pagination via HATEOAS.

{
    « total_items » : 166,
    « total_pages » : 83,
    « page » : 27,
    « page_size » : 2,
    « customers » : [
          {
                « id » : « 1234 »,
                « lastname » : « DUPOND »,
                « firstname » : « JEAN »
           },
          {
                « id » : « 5678 »,
                « lastname » : « DURAND »,
                « firstname » : « ANTOINE »
          }
       ],
      « links » : [
             {
                   « rel » : « first »,
                  « href » : « http://api.nexworld.fr/v1/customers?page_size={page_size}&page=1 »,
             {
                  « rel »: « next »,
                  « href »: « http://api.nexworld.fr/v1/customers?page_size={page_size}&page={page+1} »,

             {
                  « rel »: « prev »,
                  « href »: « http://api.nexworld.fr/v1/customers?page_size={page_size}&page={page-1} »,
             {
                  « rel »: « last »,
                  « href »: « http://api.nexworld.fr/v1/customers?page_size={page_size}&page={total_pages} »,
              }
        ]
}

Les liens hypermédias renvoyés dans la liste « links » permettent d’accéder au premier élément, au dernier élément, à la page suivante et la page précédente. Ces liens sont facilement utilisables par le consommateur de l’API pour naviguer dans la liste de clients.

La résolution des erreurs

En cas de requête en erreur, le serveur peut envoyer grâce à HATEOAS des informations complémentaires sur l’origine de l’erreur afin de la corriger. Imaginons une API permettant de gérer des utilisateurs. Une requête est envoyée afin de mettre à jour l’adresse de l’utilisateur 1234 :

PATCH http://api.nexworld.fr/v1/users/1234
{
          « address » : {
                   …
          }
}

Il se trouve que cet utilisateur n’est pas « activé ». Or d’un point de vue métier, il n’est pas possible de mettre à jour un utilisateur qui n’est pas encore « activé ». Le serveur, qui porte cette logique métier, va donc avertir le client de l’origine de l’erreur, et lui proposer via un lien hypermédia d’ « activer » l’utilisateur avant de mettre à jour son adresse :

{
       « error_name » : « INVALID_OPERATION »,
       « error_message » : « update to an inactive account is not         supported »,
              « links » : [
                     {
                            « href » : « http://api.nexworld.fr/v1/users/1234/activate »,
                            « rel » : « activate user »,
                            « method » : « POST »
                     }
              ]
}

Ainsi, le consommateur de l’API connaît la raison de l’erreur, et peut la corriger facilement en suivant les directives données dans les liens hypermédias.

Logique métier portée par le serveur

Dans certains contextes métiers compliqués, l’utilisation de HATEOAS permet d’éviter au consommateur de prendre en charge la logique et les processus métiers. Cela assure un couplage large entre le client et le serveur, ce qui est l’une des contraintes majeures de l’architecture REST. Prenons l’exemple d’une commande qui peut être annulée uniquement si elle est dans l’état « en cours » et non si elle est dans l’état « terminée ». Voici la requête pour récupérer les informations de la commande 1234 :

GET http://api.nexworld.fr/v1/orders/1234

Voici la réponse de l’API dans le cas où la commande 1234 est « en cours » :

HTTP/1.1 200 OK
{
            . . .
            « status » : « PENDING »,
            « links »: [
                    {
                            « rel » : « self »,
                            « href »: « http://api.nexworld.fr/v1/orders/1234 »,
                            « method » : « GET »
                    },
                    {
                            « rel » : « cancel »,
                            « href » :  » http://api.nexworld.fr/v1/orders/1234/cancel »,
                            « method » : « POST »
                    }
        ]
}

La commande 1234 est « en cours ». Conformément au processus métier, l’utilisateur peut donc la consulter ou l’annuler s’il le souhaite. Ces deux actions sont fournies par les liens hypermédias.

Voici la réponse de l’API dans le cas où la commande 1234 est « terminée » :

HTTP/1.1 200 OK
 {
            . . .
            « status » : « COMPLETED »,
            « links »: [
                    {
                            « rel » : « self »,
                            « href »: « http://api.nexworld.fr/v1/orders/1234 »,
                            « method » : « GET »
                    }
        ]
}

La commande 1234 est « terminée ». Conformément au processus métier, l’utilisateur ne peut plus l’annuler, mais il peut toujours la consulter. Le lien permettant l’annulation de la commande n’est donc plus envoyé par le serveur dans la réponse de l’API.


Traitement asynchrone

Certains traitements peuvent être traités de façon asynchrone, notamment afin d’éviter au client un temps d’attente trop long. Prenons l’exemple de l’envoi d’un mail traité de façon asynchrone :

POST http://api.nexworld.fr/v1/resources/1234/send_mail
{
    . . .
}

La réponse de l’API est la suivante :

HTTP/1.1 202 Accepted
{
    « links » : [
        {
                « href » : « http://api.nexworld.fr/v1SS/resources/1234/mail_status »,
                « rel » : « get the mail status »,
                « method » : « GET »
        }
    ]
}

Le traitement (ici l’envoi du mail) est asynchrone, mais le consommateur peut suivre le statut du traitement en appelant le lien renvoyé par l’API.


Avantages

L’utilisation du HATEOAS comporte de nombreux avantages.

Découplage client-serveur

En cas de refactorisation des URI de l’API côté serveur, les clients ne sont pas impactés, sous réserve bien entendu qu’ils utilisent les liens hypermédias fournis dans les réponses. Le client n’a plus à connaître l’ensemble des URI de l’API et les coder en « dur », mais peut les gérer de façon dynamique en utilisant les liens hypermédias. Cela permet de découpler le client du serveur.

Diminution des erreurs côté client

Le fait pour le client d’obtenir les URI de façon dynamique via des liens hypermédias permet de réduire drastiquement les erreurs de construction d’URI. En effet, beaucoup d’erreurs côté client sont dues à une mauvaise construction des URI (éléments manquants, dans le mauvaise ordre, etc…).

Logique métier portée par le serveur

Comme nous l’avons vu précédemment dans le cas d’usage de la commande qui ne peut être annulée que dans certains cas métiers, l’utilisation de HATEOAS permet au client de ne pas porter la logique métier, et laisse le serveur s’en charger.

Auto-documentation

HATEOAS permet également à l’API qui l’implémente de s’auto-documenter. Le consommateur peut découvrir les différentes possibilités de l’API en suivant les liens hypermédias. De plus, en cas de nouvelles fonctionnalités, le serveur met à jour les liens hypermédias. Toutefois, HATEOAS ne saurait en aucun cas remplacer une documentation claire et exhaustive de l’API.


Inconvénients

Toutefois, il existe également des inconvénients à l’utilisation de HATEOAS.

Un développement plus compliqué côté serveur et côté client

Intégrer des liens hypermédias dans la réponse d’une API rend son développement plus difficile. En effet, cela va dépasser la simple sérialisation/désérialisation des objets manipulés. Il va falloir prévoir toutes les transitions possibles (ou du moins le plus possible d’entre elles) entre les différents états des ressources, et avoir la capacité de les remonter au client en fonction du contexte métier.
De même, le client doit pouvoir interpréter les liens hypermédias envoyés par le serveur, en plus de la donnée utile.

Inadapté pour certaines méthodes

Nous avons vu précédemment plusieurs cas d’usages du HATEOAS. Dans ces exemples, un lien hypermédia est accompagné de trois informations :

  • Une URI (exemple : /v1/customers?page_size={page_size}&page={page+1})
  • Le verbe HTTP associé (exemple : GET)
  • Le nom de l’action (exemple : page suivante)

Il n’y a pas d’information concernant le body de la requête. En effet, renvoyer un body entraînerait un alourdissement conséquent de la réponse, tout en la rendant moins lisible.
HATEOAS est donc très adapté pour les transitions dont les requêtes ne possèdent pas de body, comme les GET par exemple. Mais avec ce type de liens hypermédias, le serveur ne peut pas remonter au client l’ensemble des transitions possibles, comme la création d’un objet par exemple, qui nécessite un body en entrée.

 

Conclusion

HATEOAS est le niveau le plus mature du modèle de Richardson. Il est indéniable que HATEOAS améliore le découplage entre le client et le serveur, et répond à de nombreux cas d’usages, comme nous l’avons vu précédemment. Il améliore également la documentation des APIs et facilite l’utilisation de l’API par le client. Pourtant malgré tous ces avantages certains, HATEOAS reste très peu répandu parmi les APIs REST.

Pourquoi un tel paradoxe ?
Premièrement, son utilisation n’est pas forcément adaptée à toutes les situations et la généraliser sans se poser de questions n’est pas forcément une bonne idée. Lors du design et de l’implémentation d’une API REST, il est nécessaire de se poser la question de la pertinence de l’utilisation de HATEOAS. Malgré ses avantages, HATEOAS doit répondre à un besoin métier, et ne pas être implémenté à tout prix.

Deuxièmement, HATEOAS augmente grandement la complexité de développement du client et du serveur. C’est ce coût supplémentaire qui reste le principal frein à sa généralisation au sein des APIs REST. Ainsi, même les géants du web comme Facebook, Google ou Amazon n’utilisent que très peu HATEOAS dans leurs APIs REST.

Nous sommes face à un cercle vicieux. Aujourd’hui, peu de clients sont capables de tirer pleinement profit d’une API REST HATEOAS. Cela implique que les développeurs d’APIs ne prennent pas nécessairement la peine d’implémenter HATEOAS, car cela a un coût (complication des développements) et ne sera sans doute pas utilisé. Mais si les clients ne sont pas adaptés au HATEOAS, c’est aussi car très peu d’APIs proposent cette fonctionnalité. Avec HATEOAS, nous sommes un peu face au serpent qui se mord la queue…

Quentin DUSSERRE

Quentin DUSSERRE

Consultant Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

Machine Learning : comment industrialiser vos modèles ?

La Data Science, domaine prometteur qui continue de séduire de plus en plus d’entreprises, peine à être intégré dans des processus d’industrialisation. La combinaison entre donnée, algorithme, mathématiques, infrastructure technique, devOps, API, entre autres, fait...

Le site Nexworld.fr fait sa mue

Si vous lisez ces lignes, c’est que vous avez sous les yeux la nouvelle version du site de Nexworld. En cette fin d’année 2019, Nexworld a pris le parti d’adopter une approche plus créative pour ne pas dire plus COMICS de la communication corporate. Ce site est...

RPA – Quelles sont les principales offres du marché ?

Pourquoi des acteurs d’origines souvent très diverses (ceux qui ne sont pas pure players) proposent-ils aujourd’hui des offres autour de la RPA ?

Les pure players d’envergure mondiale : Comme souvent, il y a les acteurs spécialisés qu’on qualifie souvent de « pure players » lorsqu’on veut parler anglais

Machine Learning : comment industrialiser vos modèles ?

Machine Learning : comment industrialiser vos modèles ?

Machine Learning : comment industrialiser vos modèles ?

La Data Science, domaine prometteur qui continue de séduire de plus en plus d’entreprises, peine à être intégré dans des processus d’industrialisation. La combinaison entre donnée, algorithme, mathématiques, infrastructure technique, devOps, API, entre autres, fait appel à de nouvelles compétences et au besoin d’une sensibilisation transverse, pour mener à bien la mise en production de modèles de Machine Learning. Nous allons aborder tous les points critiques pour industrialiser un modèle de Machine Learning.

Une phase d’expérimentation éprouvée

Ce n’est plus une surprise pour personne, la donnée va continuer à croître en volume dans les entreprises. Toutes ces données, véhiculant des informations toujours plus précises et toujours plus riches, sont un catalyseur aux champs des possibles, tant pour les Métiers que pour l’IT. De nouveaux besoins se font sentir. Parmi eux, un sujet se distingue comme une priorité pour tous types d’entreprises : l’exploitation des données avec des algorithmes de Machine Learning. Pour ne citer que quelques grands exemples :

  • La détection de fraude dans des signaux faibles
  • La gestion d’alertes corrélées à des changements d’état des données
  • La détection de changement de tendances et également de comportements suspects

Ce sont des sujets qui ont déjà été éprouvés dans un grand nombre d’entreprises ayant adopté ces approches très tôt. Cependant, pour les nouveaux entrants, beaucoup de projets restent à l’état de PoV (Proof of Value) et ce, malgré des retours d’expérience plus que positifs.

Alors, quels sont les principaux freins à la mise en production de ces techniques qui ont pourtant réussi à passer l’étape de l’expérimentation ?

Lorsque l’on s’intéresse davantage aux détails des expérimentations de Machine Learning, on s’aperçoit que celles-ci sont réalisées sur des données figées dans le temps. En effet, les données relatives à l’entrainement de modèles de Machine Learning sont souvent fixes. En d’autres termes, ces données n’évoluent pas ou très peu pendant la durée de l’expérimentation et ne sont parfois qu’un extrait de l’ensemble des données disponibles.

Néanmoins, une fois l’algorithme d’entraînement du modèle validé, deux enjeux principaux sont nécessaires pour assurer le passage de l’expérimentation à l’industrialisation :

  • La mise en production de modèles de Machine Learning
  • L’apport des données aux modèles

Au travers de notre expérience, nous constatons que ce sont les principaux points de difficulté dans la phase d’industrialisation de modèles de Machine Learning. Dans la continuité de l’article, nous ne parlerons que de la partie « mise en production de modèles de Machine Learning »

Vue d’ensemble de l’industrialisation d’un processus de Machine Learning

Pour bien comprendre ces enjeux relatifs à l’industrialisation d’un processus de Machine Learning, le schéma ci-dessous décrit le processus simplifié d’entraînement de modèle de Machine Learning et de prédiction. 

Ce schéma représente un modèle de Machine Learning déployé et accessible via une API avec un pipeline de traitement qui récupère les données et les injecte directement dans ce modèle pour en extraire les résultats.

Ce schéma représente un modèle de Machine Learning déployé et accessible via une API avec un pipeline de traitement qui récupère les données et les injecte directement dans ce modèle pour en extraire les résultats.

Dans ce processus, il faut distinguer deux grands axes de travail :

  1. Le déploiement et l’accessibilité des modèles de Machine Learning
  2. L’apport des données, en temps réel ou en batch, pour réaliser les prédictions à partir de ces modèles

Le déploiement des modèles de Machine Learning

Quels sont les inputs ?

Le processus de déploiement de modèles de Machine Learning requiert plusieurs entrées :

  • Un accès à l’ensemble des données brutes nécessaires à l’entraînement du modèle
  • Un script d’entraînement développé par des Data Scientists
  • Une plateforme pour réaliser l’entraînement de modèles (On-premise ou Cloud)
  • Un script pour déployer le modèle en production via une API
  • Une plateforme cible pour déployer le modèle (On-premise ou Cloud)

Il y a donc deux grandes étapes dans ce processus :

  • L’étape d’entraînement
  • L’étape de déploiement

Chacune de ces étapes relève davantage des équipes IT, que des Data Scientists eux-mêmes. Nous pourrions faire le parallèle avec le déploiement d’une application (web par exemple) en production. Il existe donc des processus pour automatiser et faciliter le déploiement.

Vers une approche DevOps pour garantir la pérennité des modèles

Comme des projets IT, le déploiement de modèle de Machine Learning peut être intégré dans un déploiement continu DevOps.

Contrairement à l’idée reçue, l’entraînement d’un modèle à un instant « T » ne garantit pas sa performance dans les jours/semaines/mois à venir. En effet, les performances d’un modèle de Machine Learning sont directement liées aux données avec lesquelles il a été entraîné. S’il reçoit des nouvelles données avec une nature différente de celles utilisées lors de son entraînement, alors, le modèle de Machine Learning fonctionnera très mal.

Au regard de cela, il est intéressant de pouvoir ré-entraîner un modèle facilement et rapidement sur de nouvelles données. Lorsque l’on parle de ré-entraînement de modèle, il s’agit de la création d’un nouveau modèle qui n’a plus les mêmes caractéristiques que l’ancien. Dès lors, pour pouvoir profiter des nouvelles caractéristiques de ce modèle, il faut être en mesure de le redéployer.

On pourra notamment citer cette entreprise française de ciblage publicitaire sur internet, prestigieuse et internationalement reconnue, qui réentraîne ses modèles toutes les 4 à 6 heures pour avoir la recommandation d’achat la plus précise possible à proposer aux internautes.

Le load balancing pour assurer la scalabilité

La scalabilité est un enjeu fort pour les applications. Une des méthodes les plus connues pour y répondre est le load balancing. Or, l’utilisation du Machine Learning apporte des contraintes supplémentaires par rapport à un « load balancing classique ». La contrainte principale découle directement du temps de traitement nécessaire pour charger le modèle en mémoire, par les différentes instances lors de leur démarrage : plus la taille du modèle est importante plus le temps de chargement en mémoire est long.

Par exemple, pour répondre à des cas d’usage présentant de forts pics de charge, il faut être en mesure de déployer de nouvelles instances à la demande. Néanmoins, déployer de nouvelles instances avec des modèles de plusieurs centaines de méga-octets voire plusieurs giga-octets peut s’avérer long, surtout lorsque l’on veut faire du traitement à la seconde (on parle ici de plusieurs minutes, voire dizaines de minutes de déploiement).

Pour pallier ce problème, une première solution est de créer des instances « dormantes » et de répartir la charge sur ces instances en cas de pic d’activité. Cependant, cette solution entraîne des coûts supplémentaires, d’autant plus si la facture est un produit du nombre de machines instanciées.

Une autre solution serait d’auto-scaler les instances en fonction de la charge, évitant ainsi d’avoir des machines utilisées uniquement en cas de pic de charge. Certaines solutions comme AWS Sagemaker proposent déjà ce type de service. Néanmoins, en cas de pics de charge brutaux, le temps que les nouvelles instances soient déployées, certains messages ne pourront pas être traités. L’article de blog sur l’apport des messages en temps réel décrit quel process adopter pour ne pas perdre de messages.

Gérer la dérive des modèles

Comme précisé précédemment, un modèle de Machine Learning ne reste pas performant éternellement. Il faut donc être en mesure de détecter quand un modèle ne l’est plus et mener des actions en conséquence. Il y a ainsi un intérêt à définir des seuils de validation basés sur des métriques mathématiques définies avec les Métiers.

Cependant, dans le cas d’un apprentissage supervisé, pour utiliser ces métriques, il est nécessaire d’avoir une « vérité » issue du terrain (ground truth). Or, il est courant que ces données ne soient pas générées en même temps que les prédictions. Il en découle une conséquence directe : ce seuil ne peut donc pas toujours être évalué en temps réel.

Quel processus pour le déploiement d’un nouveau modèle ?

Après avoir ré-entraîné un modèle et avant qu’il ne soit déployé en production en remplacement de la version précédente, il est important de vérifier qu’il fonctionne mieux que l’ancien. Pour cela, on utilise en général des méthodes d’A/B testing avant de dé-commissionner l’ancien modèle. Il est important de pouvoir intégrer ce type de test dans le pipeline DevOps.

Dégradation des données d’entraînement

L’utilisation d’algorithmes de Machine Learning n’est pas anodine sur le comportement des applications et notamment sur les données que les applications vont continuer à stocker. Par exemple : dans le cas de la détection de fraude, tous les faux positifs (personnes prédites comme fraudeuses alors qu’elles n’allaient pas frauder) seront bloqués avant la fin du parcours d’achat.

L’arrêt du parcours en cours (dû à la prédiction de la personne comme fraudeuse) empêchera le stockage de l’intégralité des données du parcours. Or, pour ne plus détecter ces faux positifs, il faudrait pouvoir ré-entraîner le modèle avec ces données qui auraient été mal classifiées.

Cependant, puisque ces données ne sont plus stockées, il devient impossible d’améliorer le modèle. Une solution parmi d’autres pour pallier ce problème : créer un flux qui ne passerait pas par le modèle et irait directement alimenter la base d’apprentissage.

Deal entre performance et taille du modèle

Lorsque l’on veut améliorer la performance d’un modèle, il n’est pas rare de lui fournir plus de données en entrée, ou de faire de l’apprentissage ensembliste (qui utilise plusieurs algorithmes d’apprentissage pour obtenir de meilleures prédictions).

Ces méthodes impactent directement la taille du modèle, le rendant certes plus performant mais aussi bien plus volumineux (le sujet sera abordé plus en détail dans un article dédié). Il arrive que ces méthodes n’apportent que de faibles améliorations par rapport au modèle de base.

Comme décrit dans le chapitre du load balancing, la taille du modèle impacte directement le temps de déploiement et le nombre de messages qui peuvent être prédis. Il est donc intéressant de faire une étude pour avoir le meilleur rapport entre la performance du modèle et sa taille. Dans cette démarche on pourra notamment citer Google qui a lancé des compétitions Kaggle, lors desquelles les compétiteurs avaient pour objectif de créer le modèle de prédiction d’image le plus performant, tout en gardant une taille inférieure à 1 Go.

Quelles plateformes pour déployer des modèles ?

Les grands fournisseurs Cloud proposent aujourd’hui des services clés en main pour le déploiement et l’exposition de modèles dans le Cloud. Ces services couvrent toutes les étapes depuis l’entraînement du modèle jusqu’à son exposition via APIs.

Les grands avantages de ces plateformes sont de :

  • Proposer un panel de machines avec des performances configurables pour entraîner des modèles et les déployer
  • Faciliter une intégration DevOps
  • Proposer une brique de sécurité pour l’exposition des modèles via APIs.

Cependant, pour une meilleure maîtrise des coûts et/ou la volonté de non-partage des données et de l’intelligence algorithmique d’une entreprise, l’option « On-premise » peut être favorisée. Il faudra alors mettre plus d’efforts pour l’automatisation du déploiement et la sécurisation du modèle.

Pluralité des compétences, facteur principal de réussite

En résumé, le déploiement de modèle de Machine Learning est un processus complexe qui demande de bien comprendre tous les enjeux relatifs à l’utilisation et à l’exploitation du modèle de Machine Learning pour pouvoir être correctement réalisé. Il est très rare qu’une seule personne regroupe toutes les compétences pour :

  • Comprendre le besoin Métier
  • Produire un ou plusieurs modèles de Machine Learning
  • Industrialiser le ou les modèles
  • Récupérer les données par batch ou en temps réel
  • Utiliser le modèle déployé sur les données

Il ne faut donc pas tomber dans le piège de croire que les Data Scientists seront capables de réaliser toutes ces étapes seuls. Il est donc nécessaire d’avoir une bonne communication et une réelle sensibilisation entre toutes les parties prenantes d’un projet de Data Science, des experts Métiers jusqu’aux Data engineer/software engineer en passant par les Data Scientists.

Pour conclure, le succès d’un projet de Data Science est très fortement conditionné par la pluralité des compétences requises et la bonne compréhension des enjeux par chacune des équipes.

Lucas Sterna,
Consultant Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

L’Intelligence Artificielle : 7 mythes mis à l’épreuve

L’Intelligence Artificielle (IA) est dans tous les discours : films, nouvelles technologies ou encore politique ; avec des visions parfois extrêmes. Souvent dystopiques en science-fiction ou utopiques selon les GAFAMI. Simple buzzword ou réelle disruption...

Le site Nexworld.fr fait sa mue

Le site Nexworld.fr fait sa mue

Le site Nexworld.fr fait sa mue

Si vous lisez ces lignes, c’est que vous avez sous les yeux la nouvelle version du site de Nexworld. En cette fin d’année 2019, Nexworld a pris le parti d’adopter une approche plus créative pour ne pas dire plus COMICS de la communication corporate. Ce site est d’abord le vôtre ! L’objectif de ce dernier est de mieux vous servir, de mieux vous orienter dans la définition de vos projets de transformation digitale.

Pour une meilleure expérience utilisateur

Le principe général de ce nouveau nexworld.fr : un site plus clair, qui reflète mieux les expertises et l’identité du cabinet de conseil et s’adapte au tempo de l’information digitale.

Le nouveau site de Nexworld incarne un double engagement éditorial que nous avons envers vous. Il s’agit d’abord de mieux vous éclairer sur les accélérateurs de croissances qui font la différence. Cela passe par une redéfinition et un reclassement thématique de nos domaines d’expertise, à savoir : l’Architecture d’Entreprise, les Microservices et Conteneurisation, l’API Management, l’Architecture Data et la Gouvernance, la Data Science, l’Enterprise Automation et enfin DevOps. Cette organisation se reflète particulièrement sur la nouvelle page d’accueil du site.

Notre second engagement éditorial sera de vous apporter l’essentiel de l’information digitale éclairée par nos experts en faisant le lien entre un monde qui bouge et vous. Être là où les autres ne sont pas, donner du sens à une innovation ou à une idée, valoriser l’essentiel et décrypter le monde abscons de certaines technologies dites disruptives, voilà les missions de notre support web : nexworld.fr.

Les esquisses du dessinateur de bande dessinée Christophe Alvès qui ont
précédé le lancement du projet du nouveau site de Nexworld

Nouvelle charte et immersion ludique sous le pinceau du dessinateur Christophe Alvès

Pour rendre tous ces contenus plus accessibles et améliorer votre confort de lecture, nous avons élaboré une nouvelle charte graphique pour l’ensemble de nos pages web. Celles-ci se veulent plus vives, plus dynamiques, plus ludiques et plus claires. Côté graphisme, le conseil façon Nexworld se pare de couleurs plus vives !

Sous les traits de pinceau du dessinateur de bandes dessinées Christophe Alvès, Nexworld vous propose une immersion ludique dans l’univers du Conseil. Les pages de Nexworld vous plongeront dans l’imaginaire du dessinateur au service de la marque Nexworld.

Un des crayonnés lors des étapes de recherche

Partez à la découverte de nexworld.fr

Ce site est d’abord le vôtre. Nous vous laissons désormais naviguer à la découverte de notre site. Si vous souhaitez développer votre Business numérique, déroulez le menu de nos expertises pour en savoir un peu plus sur l’API Management ou les Microservices par exemple. Jetez un œil sur notre blog pour découvrir les sujets innovants avec nos experts. Prenez le temps, si vous cherchez un emploi, de consulter nos offres d’emploi à la rubrique Carrière. Pour suivre des formations pointues qui vont à l’essentiel, cliquez tout simplement sur notre onglet Formation. Si vous souhaitez connaître l’histoire de Nexworld ou mettre un visage sur les membres fondateurs du cabinet de Conseil, faites un tour sur la page Corporate. Enfin, si vous souhaitez nous faire un retour, cliquez donc sur Contact, cela nous fera toujours plaisir.

Le département de communication de Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

Machine Learning : comment industrialiser vos modèles ?

La Data Science, domaine prometteur qui continue de séduire de plus en plus d’entreprises, peine à être intégré dans des processus d’industrialisation. La combinaison entre donnée, algorithme, mathématiques, infrastructure technique, devOps, API, entre autres, fait...

Le site Nexworld.fr fait sa mue

Si vous lisez ces lignes, c’est que vous avez sous les yeux la nouvelle version du site de Nexworld. En cette fin d’année 2019, Nexworld a pris le parti d’adopter une approche plus créative pour ne pas dire plus COMICS de la communication corporate. Ce site est...

RPA – Quelles sont les principales offres du marché ?

Pourquoi des acteurs d’origines souvent très diverses (ceux qui ne sont pas pure players) proposent-ils aujourd’hui des offres autour de la RPA ?

Les pure players d’envergure mondiale : Comme souvent, il y a les acteurs spécialisés qu’on qualifie souvent de « pure players » lorsqu’on veut parler anglais

RPA – Quelles sont les principales offres du marché ?

RPA – Quelles sont les principales offres du marché ?

RPA – Quelles sont les principales offres du marché ?

Pourquoi des acteurs d’origines souvent très diverses (ceux qui ne sont pas pure players) proposent-ils aujourd’hui des offres autour de la RPA ?

Les pure players d’envergure mondiale

Comme souvent, il y a les acteurs spécialisés qu’on qualifie souvent de « pure players » lorsqu’on veut parler anglais, même si ce terme est devenu trop commun pour être précis. Il s’agit tout simplement d’éditeurs ex nihilo qui se créent à partir de rien pour répondre à un besoin naissant. Ainsi s’est constitué le pionnier Blueprism en 1981, il y a plus de 18 ans maintenant – voilà pourquoi nous pouvons parler d’offre mature. Aujourd’hui, cette entreprise britannique est cotée, ce qui en fait certainement une exception dans son secteur.

Blueprism a été suivie en 2005 par UiPath, d’origine roumaine mais qui est devenue une entreprise américaine, puis par les Californiens d’Automation Anywhere en 2008, même si leur nom était différent à l’époque.

Les pure players régionaux

Les Français n’étaient pas en reste puisque – même si la genèse est un peu compliquée – on peut faire remonter les débuts de Contextor à 2003. Pour ceux qui l’ignoreraient, l’entreprise a été rachetée il y a moins d’un an par le géant SAP, autre signe si besoin était, de l’importance de ce marché de la RPA pour les éditeurs de solutions logicielles.

Pour autant, il ne faut pas négliger des acteurs plus « petits » qui ont une couverture géographique ou sectorielle plus restreinte, mais souvent fonctionnellement et techniquement intéressante. Cela peut correspondre aux besoins d’entreprises que ne rebutent ni l’absence d’une présence en France de l’éditeur, ni la difficulté de trouver des partenaires intégrateurs qualifiés. On citera notamment Another Monday et Servicetrace pour les germanophiles, Antworks installée à Singapour, AutomationEdge, DataMatics et EdgeVerve (filiale d’Infosys) en Inde, Jacada au Proche Orient. L’éditeur américain HelpSystems avec ses filiales européennes au Royaume-Uni et en Espagne est certainement le plus « gros » de ces « petits » acteurs.

Bien évidemment les « pure players » ne sont pas seuls et doivent cohabiter avec des acteurs, soit plus anciens et qui viennent « d’autres mondes », soit aussi jeunes qu’eux, installés sur d’autres niches, et qui viennent « jouer » dans leurs cours.

Les acteurs qui viennent d’autres « mondes »

Le « P » de l’acronyme RPA signifie : processus. Quoi donc de plus naturel que de retrouver des acteurs dont l’origine remonte à la modélisation des processus, j’ai cité le fameux BPM (Business Process Management). C’est de cet univers que viennent les américains Appian (créé en 1999) et Pegasystems dont l’origine remonte à 1983. En passant un accord poussé avec Blueprism, même si les intégrations avec les autres produits restent possibles, Appian propose ainsi une solution complète à ses clients en incluant de la RPA. En rachetant l’éditeur spécialisé OpenSpan en 2016,Pegasystems a eu une autre approche pour un résultat similaire : proposer des solutions d’automatisation de processus intégrées à une plateforme plus vaste et déjà bien implantée.

Mais le BPM n’est pas la seule étoile à briller au firmament de la RPA. Depuis sa création en 1985 autour des logiciels de capture, l’éditeur Kofax a eu une histoire mouvementée. Avec les rachats de ReadSoft (automatisation des processus financiers), de Top Image Systems (processus orientés contenus dans le Cloud), Kofax RPA est certainement une solution qui peut répondre à de nombreux besoins.

Ceux pour qui l’intégration entre RPA et Machine Learning a un sens seront intéressés par les produits de l’américain WorkFusion alors que d’autres, axant leur stratégie sur l’expérience client, regarderont de près ce que propose NICE dont le siège est dans le New Jersey.

Last but not least, ignorer les géants du Cloud qui approchent à grands pas serait plus qu’une faute. En proposant des solutions qui partent des flux de travail, Microsoft et Amazon, le premier avec Azure Logic Apps, le second avec Step Functions et SWF (Simple WorkFlow) ont plus que leur mot à dire, et ce n’est qu’un début !

Ce décor – qui ne prétend aucunement à l’exhaustivité – étant planté, reste à entrer dans les détails au travers de grilles de fonctionnalités. Ce sera l’objet du prochain épisode de cette série consacrée à la RPA.

Jean-Luc DARGENT

Jean-Luc DARGENT

Consultant Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

L’Intelligence Artificielle : 7 mythes mis à l’épreuve

L’Intelligence Artificielle (IA) est dans tous les discours : films, nouvelles technologies ou encore politique ; avec des visions parfois extrêmes. Souvent dystopiques en science-fiction ou utopiques selon les GAFAMI. Simple buzzword ou réelle disruption...

Kubernetes à la mode Edge

Kubernetes à la mode Edge

Kubernetes à la mode Edge

Les nouvelles sources d’événements telles que la voiture connectée dans l’automobile, le bâtiment et les bureaux intelligents ou encore l’industrie pour la surveillance des usines, nécessitent des capacités de calcul et de traitements en complément des infrastructures traditionnelles. Le Edge Computing est apparu pour éviter la transmission de données nombreuses et peu pertinentes vers les Data Centers ou le Cloud, apportant fluidité et rapidité de réaction.

Avant de continuer, qu’est-ce que le Edge Computing ?

Le Edge Computing peut être considéré comme un réseau de mini Data Centers (entre un serveur et moins d’une dizaine d’instances, généralement 2 ou 4 machines), qui stockent et traitent les données au plus près des infrastructures où les capteurs sont déployés.

Il est le plus souvent utilisé dans l’univers de l’IoT où la connectivité est faible et la latence importante. Les flux de données remontés par les capteurs sont traités localement, afin de réduire le trafic en direction des serveurs centraux (Data Centers et/ou Cloud) et ainsi permettre une analyse des données importantes et une réaction proche du temps réel.

A l’instar des Data Centers et du Cloud avec Kubernetes (sur Kubernetes, lire l’article Transformez votre architecture applicative avec Kubernetes), le Edge Computing doit répondre aux besoins d’automatisation, d’industrialisation, de standardisation, de fiabilisation et de sécurisation. Des distributions de Kubernetes dédiées au Edge sont apparues début 2019, telle KubeEdge et K3s.

Contrairement à un Data Center où provisionner les ressources nécessaires au bon fonctionnement de Kubernetes est relativement aisé, les ressources Edge sont en quantité finie et limitée. Déployer des serveurs nombreux et performants dans des champs ou en lisière d’autoroutes n’est pas quelque chose d’aisée !

La puissance de Kubernetes étendue à l’univers du Edge

KubeEdge est une plateforme open source qui permet d’étendre l’utilisation des conteneurs et leur gestion à l’univers du Edge sous forme de package. Elle fournit l’infrastructure de base pour le déploiement, la mise en réseau, la gestion des applications conteneurisées et la synchronisation des métadata des devices avec le serveur central.
Elle intègre Kubernetes pour la partie orchestration, un broker MQTT pour gérer la communication entre les objets IoT et le Edge, et un hub pour la communication Edge/Cloud.

KubEdge est une initiative de Huawei Cloud IEF. La version 0.1 était conçue pour fonctionner uniquement avec le service Cloud IEF de Huawei mais son utilisation a été étendue à l’ensemble des fournisseurs de Cloud avec la version 0.2 (mars 2019).

K3s quant à lui, est une version allégée de Kubernetes proposée par Rancher. La volonté est de permettre l’utilisation de Kubernetes sur des infrastructures limitées, Edge server, Raspberry Pi, IoT, etc…

K3s est une distribution de Kubernetes, associée à une distribution linux légère (K3OS), en un binaire dont l’empreinte est inférieure à 40 MB de disque et 512 Mo de RAM. Ceci lui permet d’être déployée sur des serveurs à faible capacité. Cette configuration permet de profiter de la puissance de gestion d’applications proposée Kubernetes dans les configurations les plus limitées.

Conclusion

KubeEdge et K3s sont conçus pour les charges de travail de production dans des emplacements distants sans surveillance, à ressources limitées, ou dans des appliances IoT.
Ces initiatives n’en sont qu’à leurs débuts et ne sont pas encore « prod ready », mais reste des initiatives très prometteuses avec des Roadmaps à suivre de près.

Ahmad TOHAMI

Ahmad TOHAMI

Consultant Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

SOA versus Microservices : quelles différences ?

Entre les architectures SOA et microservices, les similitudes sont nombreuses. Alors comment distinguer ces deux types d’architectures ? Comment gérer la transition de l’une à l’autre ? Explications.

Service Mesh, pour une intégration optimale des Microservices

Service Mesh, pour une intégration optimale des Microservices

Service Mesh, pour une intégration optimale des Microservices

Sécurisation transparente des communications inter-Microservices, fiabilité des communications, gestion efficace des accès pour un utilisateur final, résilience des systèmes, le Service Mesh permet de simplifier au maximum la conception des Microservices.

A l’heure où la mise en œuvre des Architectures Microservices se multiplie dans les DSI, le panel des solutions techniques ne cessent de s’enrichir. Complément aux plateformes de conteneurisation basées sur Kubernetes, les Services Mesh proposent une vision innovante de l’intégration des Microservices.

Les plateformes de conteneurisation laissent beaucoup de points techniques ouverts lors de la mise en œuvre d’une Architecture Microservices :

  • Comment sécuriser les communications inter-Microservices ?
  • Comment fiabiliser ces communications ?
  • Comment identifier et autoriser l’utilisateur final ?

Il est évidemment possible de traiter tous ces points manuellement dans le code source, mais n’est-ce pas l’un des objectifs premiers d’éliminer toute problématique technique du Microservice ? C’est là que rentrent en jeu les Services Mesh : apporter une solution clé en main répondant à toutes ces questions, sans polluer le code applicatif.

Sans Services Mesh, chaque Microservice embarque une lourde charge technique

Netflix est l’un des grands précurseurs des Architectures Microservices. Sa suite Netflix OSS a dès sa publication été considérée comme une référence pour mettre en œuvre une telle Architecture. Eureka, Zuul ou Hystrix sont effectivement des solutions intéressantes mais se présentent sous forme de librairies à incorporer et à utiliser dans les sources des applications.

Les développeurs sont contraints d’utiliser des librairies particulières et de respecter certaines règles de développement. Progressivement ces particularités prennent l’aspect d’un anti-pattern, alourdissant le code source et complexifiant sa maintenabilité, tout en augmentant la quantité de bonnes pratiques techniques à tester et valider.

Le sidecar : la simplification des Services Mesh

Service mesh : side car Après quelques tentatives passées (notamment par Linkerd dans sa première version), les Services Mesh ont aujourd’hui construit une solution élégante pour contourner ces écueils : externaliser l’ensemble des configurations et du runtime des échanges interapplicatifs dans une brique appelée « sidecar ». Ce sidecar se trouve placé en front de chaque Microservice et s’impose en passage obligé pour l’ensemble des appels entrants et sortants de ce service. Une brique centrale se charge de diffuser la configuration du cluster à travers tous les sidecars, tout en centralisant leurs statistiques et logs.

Conteneurisation Orientée Microservices

Grâce aux Services Mesh et au concept de sidecar, le développement d’un microservice se fait sans se préoccuper d’un certain nombre de sujets clefs :

  • L’authentification des appels reçus par les Microservices 
  • La gestion des droits des utilisateurs 
  • La gestion des quotas d’accès 
  • La télémétrie et la surveillance des échanges

En prenant la responsabilité de la gestion des échanges, le Services Mesh permet de déplacer les questions d’accès – authentification et gestion du trafic – de l’applicatif vers la configuration. C’est un gain en souplesse ; les Microservices en eux-mêmes ne sont plus impactés par les évolutions de Gouvernance.

Dans les Services Mesh basés sur Kubernetes, le sidecar est un conteneur instancié automatiquement avec le conteneur applicatif dans un pod qui leur est dédié. L’isolation du Microservice est assurée par le passage obligatoire de toute communication entrante ou sortante du pod par le sidecar. Le dialogue entre le sidecar et le Microservice s’effectue à l’intérieur du pod.

Au sein du Service Mesh, l’identification et l’authentification sont laissés au soin d’un serveur compatible OAuth2 et/ou OpenID Connect, ce qui permet de réutiliser les systèmes de sécurité déjà en place au sein d’un SI.

De par leur position centrale dans la communication inter-Microservices, les Services Mesh offrent tout un panel d’outils et de fonctionnalités particulièrement précieux. On peut citer :

  • la mise en place d’un système de « circuit-breaker » permettant d’isoler des services en défaut le temps de leur correction ;
  • la « fault-injection », allant du retour aléatoire d’un code d’erreur à l’injection de temps de latence, qui permet aux développeurs et aux concepteurs de s’assurer du bon fonctionnement en mode dégradé de leurs Microservices dès les phases de test.

Services Mesh et Microservices : un couple gagnant

Aujourd’hui l’utilisation des Services Mesh se généralise. En atteste l’usage fait par les solutions d’API Management dans l’implémentation du concept de microgateway (sécurisation au plus près des APIs exploitées par les applications Microservices).

Simples à intégrer dans un SI, respectueux des pratiques, des tendances et technologies actuelles, les Services Mesh font figure de solutions particulièrement crédibles aux problématiques soulevées par la mise en place d’une Architecture Microservice.

Stéphane Chaillon

Stéphane Chaillon

Manager Nexworld

Tom Lechaux

Tom Lechaux

Consultant Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

Kubernetes à la mode Edge

Les nouvelles sources d’événements telles que la voiture connectée dans l’automobile, le bâtiment et les bureaux intelligents ou encore l’industrie pour la surveillance des usines, nécessitent des capacités de calcul et de traitements en complément des infrastructures...

SOA versus Microservices : quelles différences ?

Entre les architectures SOA et microservices, les similitudes sont nombreuses. Alors comment distinguer ces deux types d’architectures ? Comment gérer la transition de l’une à l’autre ? Explications.