High availability
The platform is designed to keep running through everyday failures
without manual intervention.
Self-healing
Thanks to orchestration on Kubernetes, every component is continuously
monitored. If one stops responding or fails:
- The platform restarts or replaces it automatically.
- Traffic is redirected to healthy instances in the meantime.
- The goal is to restore service within 2 minutes of the failure being
detected.
- If automatic recovery does not achieve it after 3 consecutive attempts, the
system escalates the alert to our operations team.
No operator needs to be on standby to recover from an isolated component
failure. Detection and self-healing run automatically and permanently, outside
support hours too: see Monitoring and
Support channels and levels.
Redundancy: what self-healing rests on
Replacing a component only helps if there is somewhere to put it and someone
to keep serving in the meantime. Hence the service's four layers of
redundancy:
- Several servers. The cluster running the environments is made up of
several machines. Losing one does not take the service down: its
components are rescheduled onto the others.
- Several instances of your application. An environment can run with
more than one copy of the application serving in parallel, so losing
one does not interrupt the service.
- Database with a replica. The database can be deployed with a
synchronized secondary copy and automatic failover: if the primary
instance fails, the replica takes over with no manual intervention and
without restoring a backup.
- Redundant entry gateway. Traffic enters through a gateway that
always runs with several instances and adjusts their number according
to traffic.
What is standard and what gets enabled
Cluster and entry-gateway redundancy belong to the platform: you have
them simply by being on it. Additional instances of your application and
the database replica are available capabilities that we enable at
your request, or on our recommendation when what we measure calls for it.
Details in Scaling and capacity.
Staying up through a failure and staying responsive through a peak are two
different problems. The second one — deployment models, sizing, capacity
levels, and what happens during a month-end close or a bulk integration —
has its own page: Scaling and capacity.
Zero-downtime deployments
Changes and updates are applied via progressive replacement: new
versions roll out gradually while previous ones keep serving traffic, so
there's no perceptible cutover. See
Deployments and changes.
How far it goes, and where something else begins
The high availability described here operates within the site where your
environment runs. A contingency affecting the entire site is answered
through disaster recovery, based on separate backups and reproducible
rebuilding.
The availability commitments (uptime percentage) applicable to your
service are set out in your service contract.