Développement cloud-native

Le développement cloud-native consiste à concevoir et à construire des logiciels destinés à s'exécuter sur des services cloud managés, en utilisant des conteneurs et des frontières de services là où la conception l'exige. SEYA Group construit de nouveaux produits de cette façon et y refond des applications existantes, pour les équipes dont le logiciel fonctionne mais est devenu trop lent ou trop risqué à faire évoluer.

À qui s'adresse ce service

Aux CTO et VP ingénierie qui possèdent une application génératrice de revenus et considèrent chaque mise en production comme un risque. Aux architectes solutions à qui l'on a demandé de découper un monolithe et qui veulent un second avis sur l'emplacement des coutures. Aux responsables informatiques dont l'application a été transférée telle quelle dans le cloud et porte encore ses hypothèses de centre de données, si bien que la facture cloud a augmenté et que la cadence de livraison n'a pas changé.

Si vous devez migrer de nombreuses charges de travail avec un minimum de changements, c'est plateforme cloud et migration. Cette page concerne l'application dont la conception doit changer.

Les problèmes que nous résolvons

• Un produit impossible à modifier en toute sécurité parce que chaque partie dépend de toutes les autres.
• Une base de code façonnée autour de serveurs fixes, de disques partagés ou d'une base de données unique qui ne peut pas monter en charge.
• Un chemin de mise en production qui suppose un seul livrable, un seul environnement et une fenêtre de maintenance.
• Un nouveau service à construire, sans schéma convenu sur la façon dont les services sont construits chez vous.
• Des intégrations câblées à la main qui cassent dès qu'un des deux côtés change.

Ce que vous obtenez

• Conception cible. Comment l'application se découpe en services, où les conteneurs, Kubernetes, les fonctions serverless ou un runtime plus simple trouvent leur place, et quels services managés remplacent ce que vous exploitez vous-même.
• Du logiciel qui fonctionne. Le nouveau produit ou l'application refondue, construit avec vos ingénieurs, dans vos dépôts, sur vos comptes cloud.
• Chemin de livraison. Le pipeline de build, de test et de mise en production de ces services, pour que chacun soit livré indépendamment.
• Interfaces. Des frontières d'API et d'intégration que les autres systèmes peuvent appeler de façon cohérente, documentées pour les équipes qui les consomment.
• Plan de bascule. Pour une refonte, un énoncé écrit des comportements qui doivent continuer à fonctionner et de la façon dont le trafic passe de l'ancien au nouveau.

Déroulement d'une mission

• Appel d'architecture. Vous nous présentez l'application, la contrainte qu'elle crée et le comportement qui ne doit pas casser.
• Conception. Nous lisons le code et l'historique d'exploitation avec votre équipe, proposons des frontières de services et un runtime, et convenons du premier incrément.
• Construction par incréments. Les services sont construits, testés et mis en production un à la fois, vos ingénieurs travaillant en binôme sur le sujet pour que les pratiques s'ancrent.
• Bascule et passation. Le trafic bascule selon le plan, l'ancien chemin est retiré quand vous le décidez, et votre équipe est propriétaire de ce qui tourne.

Périmètre technique

SEYA a construit et refondu des applications sur AWS, Microsoft Azure et Google Cloud. Les travaux sur conteneurs ont utilisé Docker, Kubernetes (dont Amazon EKS et Google Kubernetes Engine), Istio et OpenShift ; les travaux serverless ont utilisé AWS Lambda. Le code applicatif a inclus Java avec Spring Boot et Spring Cloud, Node.js et Python. Les pipelines de livraison ont utilisé Jenkins et GitHub Actions, avec Terraform pour l'infrastructure sur laquelle les services s'exécutent. Kubernetes est recommandé lorsque l'architecture l'exige, et un runtime plus simple dans le cas contraire.

Ce dont vous avez besoin au départ

Un product owner capable de hiérarchiser les comportements qui comptent le plus, des ingénieurs qui travailleront avec nous et reprendront le résultat, et un compte cloud dans lequel les services peuvent s'exécuter. S'il n'existe pas encore de fondation, la partie landing zone de plateforme cloud et migration vient en premier. Les vérifications de sécurité dans le pipeline sont conçues dans le cadre de sécurité et DevSecOps, et les changements dans l'organisation de vos équipes relèvent de la transformation d'entreprise.

Hors périmètre ici : un programme de modernisation de tout un portefeuille en un seul brief (la mission couvre l'application qui y est nommée), le travail de marque ou de marketing, et l'exploitation de vos clusters Kubernetes pour votre compte après la passation.

Sécurité

Les vérifications de pipeline, la gestion des secrets et les règles d'admission de l'application sont conçues dans le cadre du DevSecOps. Cette page couvre la construction de l'application. Elle ne remplace pas cette revue et ne certifie pas le résultat.

Réalisations associées

• Clearly : refonte d'une plateforme e-commerce sur AWS avec autoscaling, découverte de services et un pipeline as code
• LiveRamp : conception GKE et VPC partagé pour un premier environnement Google Cloud

Questions fréquentes

Devons-nous utiliser Kubernetes ?

Non. Kubernetes est une option parmi d'autres, et elle a un coût d'exploitation. La phase de conception recommande le runtime adapté à l'application et à l'équipe qui l'exploitera, ce qui est parfois un service de conteneurs managé ou des fonctions serverless.

À qui appartient le code ?

À vous. Le travail se fait dans vos dépôts, sous vos licences, dès le premier commit. Il n'y a pas de framework SEYA dont vous deviendriez dépendants.

Comment travaillez-vous avec nos ingénieurs ?

Comme une seule équipe. Les ingénieurs SEYA travaillent en binôme avec les vôtres sur la conception et l'implémentation, et les revues passent par votre processus habituel. L'objectif est que votre équipe puisse continuer sans nous.

L'ancienne application peut-elle continuer à tourner pendant la refonte ?

C'est l'approche normale. Le plan de bascule précise quels comportements doivent continuer à fonctionner et déplace le trafic par étapes, pour que l'activité se poursuive pendant que les nouveaux services prennent le relais.

Combien de temps dure la phase de conception ?

Cela dépend de la taille de l'application et de la part de son comportement documentée ou couverte par des tests. Nous convenons du périmètre de la phase de conception lors de l'appel d'architecture et vous prévenons s'il doit s'élargir.

Si une seule application freine toute votre feuille de route produit, réservez un appel d'architecture applicative et nous vous dirons par où nous commencerions.