L’application cloud native consomme indifféremment ses services tiers (un bus de message, une base de données, ou un service). Quelle que soit leur implémentation (MySQL local, base RDS, Cloud SQL, …) et sans impact sur la base de code.

Tout comme pour la configuration, les services doivent être découverts à l'exécution et reposent sur le principe d’un couplage lâche.

L’application doit être exécutée comme un processus sans état. Elle ne doit pas maintenir d’état (étape de workflow, état du panier, …) en mémoire à l’intérieur du processus.

Il est possible de stocker des données de contexte dans un ou des services externes en cas de besoin. Ainsi l’application peut réellement supporter la scalabilité horizontale.

Vos applications doivent démarrer rapidement et supporter une extinction propre et rapide. C’est dans ces conditions qu’elles supporteront les arrêts/relances liés à la scalabilité.

Pensez à la fin de consommation des services externes par exemple. L'application doit refléter la nature éphémère du cloud.

Les services sont construits et pensés initialement comme des APIs. Toute tâche de développement commence donc par la définition des contrats d’interface et leur implémentation. Cela favorise la réutilisation des services ainsi que leur évolution. Les microservices, et les fonctions serverless en sont de bons exemples.