Pourquoi Atlassian utilise un PaaS interne pour gérer l’accès des employés à AWS

Plus de 1000 services sont hébergés via un PaaS appelé Micros.

Cela va du code créé lors de hackathons jusqu’aux véritables produits phares.

C’est un service extrêmement important, mais sa configuration est en réalité simple.

• Image Docker : logique du service

• YAML contenant la description du service

== définition des ressources nécessaires, comme la base de données, la file de messages, le cache, etc.

== divers paramètres comme les caractéristiques d’autoscaling

Tout le reste est pris en charge par Micros

= agrégation des logs, monitoring, alertes

= multi-AZ, paramètres de sauvegarde/restauration/rétention, etc.

Peu de choses ont été développées en interne, et la plupart reposent sur les fonctionnalités d’AWS.

** Pourquoi structurer ce PaaS de cette manière

• L’intégration avec les outils et processus standards de l’entreprise facilite le développement

• Les changements devant être appliqués largement aux services sont simplifiés et deviennent prévisibles

• L’expertise d’un petit nombre d’ingénieurs est démultipliée

  ( il n’y a pas beaucoup de spécialistes PostgreSQL en interne, mais s’il suffit d’appliquer cela à Micros, toute l’entreprise en profite )

• Même de petites tentatives d’amélioration de la plateforme finissent par avoir un impact sur toute l’entreprise

• Les nouvelles fonctionnalités d’AWS peuvent aussi être ajoutées progressivement tout en respectant la sécurité et les règles existantes.

Bien sûr, cette approche n’a pas que des avantages : il peut être difficile d’expérimenter de nouvelles fonctionnalités AWS, et certains outils tiers peuvent aussi ne pas bien s’intégrer à Micros. C’est pourquoi un processus interne a été mis en place pour ajouter des fonctionnalités au PaaS.

Ce PaaS n’est pas une barrière entre les ingénieurs internes et AWS ; au contraire, il permet de rendre l’infrastructure AWS plus visible. Il continuera à évoluer

[xguru]

L’article est très long, donc je n’en ai repris que quelques extraits.

Si vous exploitez AWS dans une organisation un peu importante, je vous recommande de le lire tranquillement.

Je crois savoir qu’autrefois KTH et Daum avaient eux aussi mis en place et utilisé un cloud interne similaire (si je me souviens bien, c’était basé sur OpenStack).

Cette approche consistant à ajouter une fine couche par-dessus AWS me semble également assez bonne.