"""
(...)
Recently, Microsoft started using the pets versus cattle analogy, symbolizing the difference between how an administrator optimally treats a virtual machine image, and how she treats a container image. At DockerCon, advocates of a complete wave of change for the data center argued that administrators should learn to treat containers as ephemeral, that they should stop bestowing them with reverence and pet names, and instead see them as temporary delivery units for small quantities of functionality.

HashiCorp has a more contextual view of the ecosytem. For example, it may make sense to keep the database running, keeping it a pet, while the application itself might be abstracted into multiple services and be more ephemeral, like cattle.

“We believe that VMs and containers should be treated the same,” says Fishner. “The way we’ve built our tools, we are completely infrastructure- as well as technology-agnostic, in the way you get your application from development code to running in production.”

(...)

“We certainly agree with the transition from pets to cattle,” he says. “I think there’s going to be some things that, for the near future, aren’t realistic, like treating databases as cattle — that isn’t a problem that’s going to be solved any time in the near future. But treating stateless things as cattle is very well-adopted, so I think that we try to accommodate both.”

(...)
"""

Une approche hybride car ça n'a pas de sens de tout containeriser:
Traiter tout ce qui est stateless comme du bétail* (un serveur d'appli par ex) => containeriser, rendre ephémère
Traiter ce qui n'est pas stateless (une base de donnée par exemple) comme un animal de compagnie => VM ou bare-metal

Réalisable avec du Packer (création d'images ec2 (mais pas seulement)), Consul (service discovery/monitoring), Terraform (provisionning), Docker, Atlas (solution proprio de management packer/consul/terraform).

• Ooops, je vais m'attirer les foudres de certains shaarlistes >< Je ne fais que citer.

Je cite JMLRT:
"""
Méthodologie pour construire des applications faites pour une utilisation de type cloud:

• 1 application = 1 repository de code et 1 seul
• toutes les dépendances doivent-être explicites et fournies avec l'application
• la configuration doit-être gérée dans des variables d'environnements
• tous les services externes (api, database, smtp, cache, messaging...) doivent-être gérés comme des ressources accessibles via une URL
• les étapes de build (compilation + dépendances), release (application configuration) et run (lancement de l'application) doivent être strictement séparées
• l'application doit-être stateless et "share-nothing" (aucune donnée en local)
• l'application doit gérer sa couche réseau sans dépendre d'un logiciel externe (ex: webserver embarqué pour ne pas dépendre d'apache)
• l'application doit-être composés de process instanciables sur le même serveur ou sur différents serveurs (scalabilité)
• les process ne doivent pas être démarrés en taches de font (démon) par l'application. la gestion des process (arrêt/relance, gestion logs et stdout, ...) doit être délégués à un process manager (systemd, runit, foreman, ...)
• les tâches administratives (ex: migration db, ...) doivent être traitées par des process séparées (scripts) mais fournis avec le code applicatif et lancé dans le même environnement applicatif
  """