IX. Zbywalność
Zwiększ elastyczność aplikacji przez szybki start i bezproblemowe zamknięcie
Procesy aplikacji 12factor są jednorazowe, znaczy to, że mogą być wystartowane lub zatrzymane w dowolnym momencie. Ułatwia to elastyczne skalowanie i szybkie wdrożenia kodu, zmianę konfiguracji oraz zapewnia większą stabilność wdrożeń produkcyjnych.
Procesy powinny dążyć do minimalizowania czasu swojego rozruchu. W idealnej sytuacji proces powinien potrzebować kilku sekund na to aby wystartować i być gotowym na przyjmowanie zapytań. Dzięki krótkiemu czasowi startu można szybciej wykonywać kolejne wdrożenia oraz łatwiej skalować aplikację. Zwiększa to również zdolność aplikacji do radzenia sobie z problemami, ponieważ process manager może bezproblemowo przenieść je na nową maszynę fizyczną, gdy zajdzie taka potrzeba.
Procesy zamykają się gdy otrzymają sygnał SIGTERM od managera procesów. Dla procesów sieciowych poprawne zamknięcie polega na zakończeniu nasłuchiwania na porcie usługi (skutkiem czego jest odrzucanie nowych zapytań), zakończenie obecnych, a ostatecznie zaprzestaniu działania. Ten model zakłada, że zapytania HTTP są krótkie (trwają nie więcej niż kilka sekund), lub w przypadku long pollingu i utraty połączenia klient powinien bezproblemowo spróbować połączyć się ponownie.
Dla procesów roboczych poprawnym zamknięciem jest zwrot obecnie wykonywanego zadania do kolejki. Dla przykładu w RabbitMQ działający proces może wysłać wiadomość NACK; w Beanstalkd, zadanie jest zwracane do kolejki automatycznie, gdy tylko proces się rozłączy. Systemy bazujące na blokadach zasobów jak Delayed Job muszą upewnić się, że odblokowały zajmowany wcześniej zasób. W tym modelu ważne jest to, że wszystkie zadania są wielobieżne, co zazwyczaj jest osiągane przez zebranie wyników w transakcję lub uczynienie operacji idempotentną.
Architektura aplikacji 12factor jest również zaprojektowana tak, by działające procesy zostały poprawnie zakończone w razie awarii sprzętu. Podczas gdy taka sytuacja jest o wiele rzadsza niż otrzymanie sygnału SIGTERM, wciąż może mieć miejsce. Zalecanym podejściem w takich przypadkach jest stosowanie serwerowego systemu kolejkowania zadań, jak Beanstalkd, który zwróci zadanie do kolejki, gdy klient się rozłączy, bądź minie maksymalny czas obsługi pojedynczego zapytania. Architektura “crash-only” jest więc rozwinięciem takiego konceptu.