Aetherize pillar
Platform
The platform absorbs individual failures and puts every change on record.
Back to the overall concept
You run a platform as a regulated company and have high demands on stability and security. An outage costs revenue, a missing record costs you the audit.
We offer support that secures both: operations and the audit.
We build your foundation for high availability and fault tolerance and put every change on record. What depends on individual people today becomes a documented, automated procedure your team can repeat at any time without us.
What changes for you
The platform absorbs component failures on its own, your users notice nothing
A report answers an auditor’s question about a change, no digging through tickets
Access runs centrally through your directory service, when someone leaves it ends at once
Teams work in separate areas, no one crowds out another, no one sees another team’s data
Standard duration
2 to 8 weeks
Deployment scenarios
Build the platform greenfield and hand it over
2 weeks
Integrate modules into an existing platform with few applications and adapt the applications
4 weeks
The duration scales mainly with the number of running applications
One single path into production. The target state sits versioned in the repository, nobody writes past the system. Every change carries author, approval and timestamp, and a rollback runs back down the same path.
Attempt 1
- Submission
- Signature
- Policy
- Production
rejected
The gate held. Unsigned artifact, the rollout aborts after four seconds. The attempt stays in the record, even though it never reached production.
Attempt 2
- Submission
- Signature
- Policy
- Production
rolled out
The same change, signed. Approved by a second person, rollback verified in 90 seconds, live at 14:12. Author, approval and timestamp sit in the change record, nobody hunts for a ticket.
Example values from a rollout record. The rejected attempt is the point: what fails the signature check never reaches your production. The result is the change record, versioned out of the live system.
Who was the last person to deploy past the system at your site?
Book an intro call
M1: Foundation and network
Recommended start
Redundant control plane across separate failure domains, single failures do not interrupt operation
Platform state store on storage with guaranteed write latency, backed up regularly with verified restore
A network layer that scales with the number of services instead of slowing down as rules grow
Redundant ingress layer, certificates issue and renew themselves
Integration with your storage including snapshots, separate classes per requirement
Nodes as replaceable units, updates by replacement instead of patching in place
Version upgrades as a documented, plannable procedure
M2: Tenancy and identity
Module
Team separation at the level your protection needs demand, from logical down to dedicated hardware
Integration with your existing identity provider, no second user directory
A small set of roles instead of grown individual permissions
Every network connection is denied until approved, every approval documented
Guaranteed capacity shares and prioritization, no team crowds out another
Rules as code, violations fail at deployment
Self-service interfaces that make teams independent and faster
Least privilege as the default, not as an exception
M3: Automated delivery
Module
One single and traceable path into production, the target state lives versioned in the repository
Connects to your existing Git system, or to several at once
Every change carries author, approval and timestamp, rollback uses the same path
Signed artifacts, unsigned ones are rejected
A bill of materials per artifact as the basis for vulnerability assessment
Credentials managed centrally and short-lived, not stored in local config files
Pipelines without elevated privileges, separated per tenant
M4: Monitoring and alerting
Module
Metrics and logs centralized, retained per your schedules
Separated per tenant, security events stored tamper-proof
Availability targets per tenant, alerts derived from them
Alerts without an action attached get deleted
Escalation and on-call wired into your ticket system
Two views: one for operations, one for the business
Monthly cost and capacity report per tenant
Technology base: We build on Kubernetes and the CNCF ecosystem, and we also take into account what already runs at your site. We pick the concrete tools in the audit or workshop.
You provide: compute, IP ranges, DNS, access to storage, load balancing and your identity provider.
Adapting your business applications: on request.
Changes and access on record
Auditors ask who changed what when, and who was allowed to access it.
A single path into production, every change with author, approval and timestamp.
Reliable operation, sufficient capacity
DORA Article 7 requires reliable, resilient systems, § 30 BSIG the protection of availability.
Redundant nodes absorb failures, the platform scales on its own and reports the bottleneck before it hits.
A current inventory of all systems
DORA Article 8 requires a register of all systems and their dependencies, kept current.
Every workload, configuration and permission is described as code and versioned, deviations from the target state show up at once.
The full comparison