6 min read

Learning Objectives

By the end of this module, you will be able to:

  • Apply the core mental model that IONOS composes capabilities from primitives rather than selling them as single managed features.
  • Recognise six capabilities you might expect as a managed product and name the native IONOS pattern that delivers each one.
  • Map each substitution to the later unit that builds it, so the rest of the course reads as filling in this model.

Unit 1.3: Designing Around Platform Boundaries: The Native-Substitution Model

Introduction

The single most common way an experienced architect goes wrong on IONOS is to look for a managed product that does not exist, find nothing, and conclude the platform is missing a feature. The more accurate reading is that the platform deliberately ships primitives and expects you to compose the capability. There is no managed API gateway, no read-replica feature, no managed failover product, no database change-data-capture service, no OVF/OVA import wizard, and no policy-language identity system. None of these is an oversight to apologise for; each is a capability the platform expects you to assemble from parts it does give you. This unit names the substitution for each, because once you hold the model, the apparent gaps stop being surprises and become known design patterns. Each substitution previews the module that builds it in full.

1. The Substitution Set

The pattern is always the same: a capability that a hyperscaler might sell as one managed knob is, on IONOS, a composition of two or three primitives you wire together. State the boundary honestly, then reach for the native pattern.

Content routing in place of a managed API gateway. There is no IONOS API Gateway product. The native pattern routes on content with Managed ALB forwarding rules at the edge (host- and path-based, since the ALB routes application-layer traffic on user-defined policies) and an in-cluster ingress controller for finer routing inside Kubernetes. The ALB does the coarse public routing; ingress does the fine internal routing. Bear in mind the ALB has no IP allowlisting and no security group, so request filtering belongs on the targets. This is built in Module 3 (Layer 7 load balancing).

Read scaling in place of read replicas. Managed databases on IONOS have no read replicas and no native replication to another managed instance. You scale reads with an In-Memory DB cache in front of the relational tier plus connection pooling to respect the database's RAM-derived connection ceiling. The cache absorbs the read-heavy traffic; the pooler keeps the connection count survivable. This is built in Module 5 (the relational and in-memory database units).

Automated failover in place of a managed failover product. There is no managed failover service. The native substitute combines load-balancer health checks, which steer traffic away from an unhealthy target within the load balancer's backend pool, with a customer-orchestrated, low-TTL Cloud DNS record that an external health check re-points for cross-zone failover. Cloud DNS itself is not health-aware; it serves whatever record you set. Because DNS steers only new connections and is bounded by the record TTL, the application tier must be stateless for this to be clean. This is built in Module 3 (DNS and failover) and revisited in Module 7 (resilience).

Application-level events in place of database change-data-capture. There is no managed change-data-capture stream off the databases. The native substitute is to publish events from the application itself, typically onto Managed Kafka, where a topic captures the change events and downstream consumers read them. The capture moves up into application code rather than tapping the database log. This is built in Module 5 (event streaming).

Image conversion in place of native OVF/OVA import. There is no native OVF/OVA import wizard. Migrating an existing virtual machine is an engineered step: convert and upload the disk image, with VirtIO drivers installed and a UEFI transition prepared, after which the image is usable in the region it was uploaded to (images are region-locked). This is built in Module 7 (migration and hybrid cutover).

Group-and-grant in place of policy-language IAM. There is no fine-grained, policy-based identity system. Access control is group-based with resource-level grants: you assign privileges to a group and grant that group access to specific resources, and there is no deny rule, so least privilege means simply not granting. This is built in Module 2 (identity and RBAC).

The following table is the model on one page; treat it as the index to the rest of the course.

Capability you might expect What IONOS does not sell The native substitution Built in
API gateway No API Gateway product ALB forwarding rules + in-cluster ingress Module 3
Read replicas No read replicas / managed DB replication In-Memory DB cache + connection pooling Module 5
Managed failover No managed failover product LB health checks + customer-orchestrated low-TTL DNS re-pointing Modules 3, 7
Database change-data-capture No managed DB change stream Application-level event publishing (e.g. Kafka) Module 5
OVF/OVA import No native import wizard Image conversion + upload (VirtIO, UEFI prep) Module 7
Policy-language IAM No fine-grained policy IAM Group-and-grant, resource-level grants, no deny rule Module 2

For FinCorp, the model reframes the whole engagement. Its regulated relational workload will not get a managed read replica, so the design already plans a cache-and-pooler read path. Its VMware estate will not import as OVF/OVA, so the migration plan already assumes image conversion (alongside the VMware-native paths covered later). Its access model will not enforce a deny policy, so governance is designed as deliberate, minimal granting. None of these is a workaround discovered late under pressure; each is a known pattern selected up front because the architect held the substitution model from the start.

Decision Summary

When a requirement names a capability you cannot find as a product, do not assume the platform lacks it. Run this check instead:

Step Action
1 Confirm against the facts matrix or current docs that no managed product delivers the capability directly.
2 Identify the native substitution: which two or three primitives compose it (routing rules + ingress, cache + pooling, LB health checks + low-TTL DNS re-pointing, app events, image conversion, group-and-grant).
3 Account for the substitution's constraint up front (ALB has no allowlist; DNS steers only new connections; images are region-locked; there is no deny rule).
4 Note which later module builds it, and carry the decision into the FinCorp design.

The discipline is to never infer a feature from a product name or a hyperscaler analogue. State the boundary plainly, then compose the pattern.

Summary

IONOS composes capabilities from primitives rather than selling them as single managed features, so several things an architect might expect as products, an API gateway, read replicas, managed failover, change-data-capture, OVF/OVA import, and policy IAM, are delivered as native substitutions: ALB rules plus ingress, cache plus pooling, LB health checks plus low-TTL DNS re-pointing, application-level events, image conversion, and group-and-grant. Holding this model converts apparent gaps into known patterns and turns the rest of the course into the place where each substitution is built.

Key Points:

  • The platform ships primitives and expects composition; an absent managed product is a design input, not a defect.
  • The six core substitutions are content routing (ALB + ingress), read scaling (cache + pooling), failover (LB health checks + customer-orchestrated DNS re-pointing), change-data-capture (app events), VM import (image conversion), and access control (group-and-grant).
  • Each substitution carries a constraint to plan for, and each previews the later module that builds it.
  • Never infer a capability from a product name or a hyperscaler analogue; confirm the boundary, then compose the native pattern.