The Infrastructure Illusion: Why Low-Code-No-Code, Public Cloud and 'Rented Compliance' Are Failing the Enterprise
How abstraction masks distributed system complexity, creates compliance blind spots under DORA/CRA, and accumulates compounding technical debt.
Table of Contents
The Marketing Myth vs. Architectural Reality
When I joined the IT industry years ago, I entered directly into the “cloud era.” I was only exposed to on-premises infrastructure for a brief period before working as a consultant focused on cloud-based Low-Code/No-Code (LCNC) platforms. Looking back, I would rephrase several answers I gave to customers based on what I know today.
Technology vendors have spent decades selling a specific narrative: Stop building from scratch. Let abstraction save you. Complexity is hidden behind Service Level Agreements (SLAs)—for instance, a Cloud CRM boasting 99.95% uptime. Whether it is LCNC promising “citizen development” or hyperscale public clouds promising elastic, serverless utility computing, the core pitch is identical: velocity without technical debt and speed without engineering overhead.
Recent years have proven a fundamental truth: Abstraction does not eliminate complexity; it merely relocates and hides it.
Hiding system architecture behind visual node builders, multi-tenant cloud control planes, or simple API endpoints does not suspend the laws of distributed systems. Instead, it accumulates compounding technical debt until the organization hits a hard performance or compliance ceiling.
Excuses like “Our cloud provider is responsible” no longer hold up under tighter European regulations. Designing a secure, scalable system in the cloud that satisfies compliance requirements in a regulated industry is more complex than ever. I have seen cloud environments where core principles like encryption at rest, Zero Trust, and security event logging were ignored—sometimes confused entirely with basic application performance monitoring.
The Necessity of the ADD (Architectural Design Document)
Every project must begin with a clear view of its core business processes and regulatory constraints, followed by cloud design patterns that address those requirements. Only then should a software stack be chosen inside a structured Architectural Design Document (ADD).
In multinational enterprise projects spanning thousands of users across dozens of country organizations, I have seen millions of euros invested into systems lacking an ADD, documentation, or established design patterns. Ownership drifts, security is sidelined, and the implementation eventually hits a complexity trap. The result is “over-customization”—building continuously without a map until budget and velocity are completely exhausted.
The Complexity Ceiling: Two Sides of the Abstraction Trap
Public cloud and LCNC platforms allow teams to configure software components visually. While visual tools offer initial speed, building enterprise production systems without Infrastructure as Code (IaC) or APIs creates long-term operational friction.
The Failure of Ungoverned “Citizen Development”
Early trends heavily promoted “citizen development”—the idea that business users would build their own production applications. In enterprise environments, this approach failed as projects grew in scale and complexity. It rapidly became unclear who held operational responsibility for application security, compliance, maintenance, and lifecycle management. In far too many cases, the answer was nobody.
Lock-in vs. Strategic Trade-offs
Public cloud and LCNC stacks introduce deep vendor lock-in. Chapter IV of the EU Data Act attempts to mitigate unfair contractual terms related to cloud switching, but lock-in remains an architectural reality.
Lock-in is not inherently negative, but it must be an explicit, conscious architectural decision balancing clear trade-offs:
Speed · Scalability · AI capabilities ⇄ Cost exposure · Geo-redundancy · Architectural complexity
Abstraction increases delivery speed only if the workload remains within the platform’s intended boundaries. When handling sensitive data in regulated environments, compliance and integration demands quickly outgrow the platform’s native abstractions.
The Financial and Operational Reckoning
Cloud computing was originally positioned to replace capital expenditure (CapEx) for physical hardware with flexible operational expenditure (OpEx) that scales on demand. While elastic scaling holds true for competent engineering teams, unmonitored cloud environments frequently lead to spiraling operational costs.
The Rise of FinOps and AI Consumption Costs
Modern AI usage-based pricing adds unpredictable variable expenditure. Token consumption, API invocations, and GPU workloads grow independently from traditional compute infrastructure demand. Unmonitored consumption models create unforecastable costs that challenge annual budgeting.
- In-Platform Cost Controls: Architecture decisions directly dictate OpEx. Cost controls must be designed into the landing zone from day one using resource tagging, subscription budgets, and automated shutdown policies.
- Dedicated On-Prem/Private Compute: For continuous, high-volume AI workloads, purchasing dedicated GPU hardware represents a higher initial CapEx but delivers predictable, lower long-term operational costs.
Major cloud providers offer mature security, compliance, and cost governance tools. The primary issue is rarely tool availability, but whether enterprise teams configure and enforce them according to documented standards.
The Sovereignty Illusion: Encryption vs. Jurisdiction
When cloud computing emerged, vendors promised legal compliance simply by selecting a local datacenter region. Stating “As long as the datacenter is in Europe, we are fully compliant” is factually incomplete.
Customer-Managed Keys (CMKs) and the US CLOUD Act
When challenged on extraterritorial regulations like the US CLOUD Act, vendors often point to Customer-Managed Keys (CMKs) to demonstrate that customer data is encrypted. However, if those keys are stored and managed inside the vendor’s own cloud Key Vault, the control plane remains within that vendor’s ecosystem.
Marketing campaigns stating “Switch to European providers or face CLOUD Act enforcement” oversimplify complex legal realities. However, organizations must be realistic: if a legally binding order is served in a provider’s jurisdiction, data access could technically occur.
Data Residency vs. Digital Sovereignty
- Data Residency: Answers where data rests geographically (e.g., an Azure region in Frankfurt or Zurich).
- Digital Sovereignty: Answers who legally controls the management control plane, who deploys backend software updates, who holds administrative access, and who owns the physical infrastructure.
If an organization’s regulatory framework requires that no external entity or foreign jurisdiction can access workloads without explicit cooperation, key material, control planes, and infrastructure ownership must be evaluated together. High-compliance workloads may require private clouds, sovereign EU datacenters, or hybrid architectures.
The Compliance Blindspot: DORA, CRA, and Auditability
The primary compliance challenge in cloud and LCNC environments is not the absence of technical security controls, but the lack of complete architectural visibility.
Over time, organizations accumulate thousands of unmanaged Logic Apps, Power Automate flows, custom connectors, service accounts, and API integrations without clear ownership or technical documentation. High-level PowerPoint diagrams showing boxes and arrows do not constitute an Architectural Design Document.
The Shift to Architectural Accountability
During an audit (e.g., Big Four, ISO, or state regulatory bodies), explicit operational questions are asked:
- Who owns this specific integration flow?
- Which third-party APIs process data from this table?
- Who authorized the latest deployment, and where is the change record?
- Where are the immutable logs feeding your SOC alerts?
- What is the disaster recovery plan if the cloud provider experiences an outage?
Regulations such as DORA (Digital Operational Resilience Act) and the Cyber Resilience Act (CRA) enforce strict third-party dependency management. Under DORA, financial institutions retain full legal responsibility for ICT risks even when services are outsourced to cloud providers. Similar logging and auditability mandates apply to high-risk systems under the EU AI Act.
Abstraction makes creating technical dependencies trivial (e.g., building a low-code flow in 20 minutes) while making long-term governance, security, and auditing significantly harder if governance does not scale at the same rate.
Remediation Roadmap: Building Sustainable Cloud Governance
To avoid complexity traps and maintain regulatory compliance, enterprise delivery teams should apply twelve structural rules:
- Slow Down Implementation When Required: Fixing missing architecture, ownership, and security controls post-launch costs significantly more than designing them correctly upfront.
- Start with a Design-Pattern-Driven ADD: Base every infrastructure plan on documented cloud design patterns (e.g., Microsoft Azure Architecture Patterns) aligned with legal constraints before writing code.
- Design Before Selecting Technology: Select software stacks based on business process needs, data sensitivity, and regulatory requirements rather than internal partner familiarity.
- Assign Explicit Dual Ownership: Every application, flow, API, connector, and service principal must have an assigned Business Owner and Technical Owner.
- Build Governance In From Day One: Enforce logging, resource tagging, budget alerts, access reviews, and deployment pipelines from initial deployment.
- Enforce Infrastructure as Code (IaC) & ALM: Prohibit manual “click-ops” configuration in production environments. Execute all deployments via version-controlled pipelines (GitHub Actions, Azure DevOps).
- Minimize Customization in Low-Code Stacks: Stay within platform out-of-the-box boundaries to avoid compounding long-term maintenance and auditing debt.
- Maintain an Active Dependency Inventory: Track all APIs, external models, data sources, and third-party vendors feeding critical business processes.
- Test Exit and Failure Scenarios: Plan for vendor service unavailability, sharp price increases, or regional outages. Recognize that identity providers (e.g., Entra ID) require independent backup and continuity strategies.
- Partner with Technical Specialists: Work with implementation partners who demonstrate deep, verified technical capability in the chosen technology stack.
- Make Vendor Lock-In a Conscious Choice: Understand the exact operational dependencies accepted in exchange for delivery speed.
- Treat Compliance as Hard Architecture: If a security control cannot be verified via automated technical telemetry, assume it does not exist. Regularly review architecture documents to eliminate technical drift.
Conclusion
Cloud computing and Low-Code/No-Code platforms are powerful enablers when deployed with discipline. The issue arises when organizations mistake abstraction for simplicity and speed for sound architecture.
Slow down where necessary, establish formal architectural design before implementation, define explicit ownership, and retain accountability. If you cannot explain how a system is structured, who owns it, how it fails, and how it is audited, you are not moving fast—you are accumulating risk.
Disclaimer: This post reflects the personal opinion of the author and does not constitute legal or professional advice. Organizations should consult qualified legal and compliance professionals regarding their specific situation.