Managed HCI Private Cloud
One way we build it. The design follows the workload.
You get a private cloud designed to your performance, capacity and cost targets.
The compute and storage are sized for your workloads.
We install and operate the platform.
Monitoring, maintenance, security and capacity management are part of the service.
Hyperconverged. That is what the HCI in the name means. Server, storage and network resources are unified into one platform and managed as one system. That is what lets us size the platform to your workload, and grow it in steps you can plan for.
The operations team comes with it. Running a private cloud well takes senior sysadmin, network, storage and DevOps experience. That experience is expensive to build in-house and harder to keep. Here it is part of the service, and our engineering and network operations teams are the ones who run it.
lower cloud costs
In most cases we provide capacity from hardware we already own and operate. There is no setup fee and no hardware investment. You pay monthly, without a large upfront investment.
Where your workload needs dedicated hardware, that is established during design, before you commit. The usual reasons are a fully isolated environment, or a rule that names dedicated hardware. It can also be a capacity profile our inventory does not hold.
We compare the total cost of ownership against your current bill over an agreed term. For workloads that suit it, the result is up to 50% lower cloud costs. We do not publish a price list, because we design capacity for a specific workload and then operate it.
Threshold
The threshold is $10,000 a month of public cloud spend. Below that, the numbers usually do not work, and we say so rather than take the work.
An application that is inefficient in public cloud is inefficient in private cloud too, and moving it relocates the cost. Where we find that, the analysis says fix first.
Good fit
Migrations run without interrupting your business. Workloads move in groups, in the order their dependencies allow. Each group runs in parallel with your existing systems and is validated before anything is switched, and a rollback path stays available through the switch.
A few systems have to be switched inside a short window you agree in advance. We identify them before the schedule is built. The usual ones:
You do not need to decide anything about architecture to find out whether this is worth doing.
Send one recent cloud bill and a short description of what runs on it. We start from your actual bill, and we go through seven things:
Compute. Your instances, their sizes, and the utilisation they actually run at rather than what they were provisioned for.
Storage. Volumes, tiers, IOPS provisioning, snapshot policies, and how much of it is backup of backups.
Traffic. Egress, inter-zone and inter-region transfer. This line surprises people. It is invisible at design time and permanent afterwards.
Managed-service premiums. What you pay above raw resource for managed databases, load balancers, NAT and backup, and whether that premium is worth it.
Licensing and support. Software licences on top of the infrastructure, plus the support plan that grows with the bill.
Commitments. Reserved instances, savings plans and committed-use discounts, and the dates they end. This decides the timing, so we look at it early.
Operational load. Who is on call, what breaks, and how much engineering time keeps the current setup running. It is not on the invoice and it is often the largest line.
You get back:
If nothing is worth moving, we say so.
"Managed" has been diluted to the point of meaninglessness. In most contracts it describes a portal, a queue, and a first-line team reading a runbook written by someone who has left.
Managed infrastructure should be something you stop thinking about. That is the standard we hold this service to.
Where a layer could belong to either side, we name the owner in a responsibility matrix at the start.
And the schedule it runs on
Your systems run in Zurich, Frankfurt, Istanbul, or a combination of them.
You choose at design time. It is written into the agreement, including which sites hold replicas, backups and logs.
Our team does not see customer data, does not access application content and does not enter the services.
Our responsibility is uptime, performance, security, capacity, network and operational continuity.
Administrative access is granted to named individuals.
It is controlled with authorisation, MFA, VPN, logging and security policies. Every administrative action is attributable.
That is the access model for this service. Where a customer asks us to operate an application as well, the access model is different. It is written into that agreement.
Physical isolation.
Dedicated hardware, dedicated network equipment and dedicated firewall. No part of the path from the network to the disk is shared. Choose this where a regulator, an auditor or a customer contract requires physical separation. It costs more. Capacity is added in larger steps, because it can mean adding devices.
Logical isolation.
Your capacity is dedicated and reserved. Separation is enforced in the network and firewall configuration. We settle which parts of the platform are shared during design, and we write it down. It costs less, and maintenance on a shared device is scheduled with notice.
Your capacity is dedicated and reserved in both models. Security and access isolation are preserved in both.
A mixed design is possible. A regulated system can use physical isolation while everything else uses logical isolation.
Six design inputs
Sizing starts from measurement. We measure what your workloads consume at peak and across a normal week. We size memory separately from CPU. A shortage of memory causes a harder failure than CPU contention. Headroom for node failure and for rolling maintenance is designed in.
We design against three properties per workload: total data, active data, and access pattern. Flash tiers hold the working set. Capacity tiers are sized to the growth curve and the retention policy you set. Replication is synchronous or asynchronous per system, chosen against the recovery point you set.
This is a low-latency network and latency is a design input, not a result you measure afterwards. Application traffic, storage replication traffic and management traffic are separated. Every node has redundant uplinks to separate switches. Failure domains are aligned so that one failure cannot remove both parts of a redundant pair.
For a failed disk, node, power feed, switch, uplink or rack, the architecture document states what happens and what you notice. Clustered compute and storage absorb these without interrupting service, provided the cluster has enough spare capacity. We reserve capacity for node failure. Your usable capacity figure excludes it.
The locations you choose share no power grid, no city and no jurisdiction, which is what gives you geographic redundancy and a disaster recovery position.
Zero Trust. Being inside the network grants no access on its own. Administrative access is identity-based, authenticated with MFA, reached over VPN, and logged per action. We build isolated, auditable environments that take requirements such as PCI-DSS into account.
We reply within 2 business days.
We do not publish client names. Ask, and we will share relevant references under NDA.
Part of Cloud & Infrastructure. See also Private AI GPU Cloud and DevOps-as-a-Service. More about how we work.
