Calculating Cloud Costs Accurately: What Does an Application Really Cost?
Compare cloud offerings fairly: total cost of ownership, compute, storage, traffic, operational costs, a worked example and a checklist.
48 of 53 items
Compare cloud offerings fairly: total cost of ownership, compute, storage, traffic, operational costs, a worked example and a checklist.
In tenders and procurement processes within the industrial, financial, and critical infrastructure sectors, mid-sized service providers are observing a fundamental shift: Pure functionality promises and ISO certificates are no longer sufficient for large corporations. In the context of **NIS-2**, **DORA**, and stringent supply chain audits, purchasers and security officers demand explicit proof that business-critical data flows and service workflows are portable in an emergency and not held hostage by individual US SaaS monopolies.
In the commercial mid-market, standard SaaS was considered the economic optimum for years: no acquisition costs for servers, seemingly transparent per-user pricing, and zero administrative effort. However, as the workforce grows and compliance requirements increase, the cost calculation shifts. Linear licensing models, opaque feature tierings, and annual price increases of 15 to 25% turn the supposedly lean cloud strategy into a financial bottomless pit.
In modern CI/CD pipelines, fast release frequency is often considered the primary success metric. However, for platform operators and software providers in regulated markets, this unchecked dynamism increasingly leads to severe security risks: When external base images, third-party libraries, and ephemeral dependencies are rolled out uncontrollably into production clusters, the software supply chain becomes an unpredictable entry point for attackers. The binding requirements of the NIS-2 directive and the Digital Operational Resilience Act (DORA) therefore demand a fundamental shift in direction—away from trusting deployments, towards a seamlessly verifiable software supply chain security.
In many established corporate and industrial landscapes, there is a risky security gap between central corporate governance and modern Cloud-Native platforms: While identities, roles, and access rights are managed company-wide via Azure Entra ID (formerly Azure AD), Kubernetes clusters and container registries often operate as isolated islands. Developers share static service account tokens, container images are pulled unchecked from public repositories, and IT security management loses visibility over the actual software supply chain.
In many industrial and analytics environments, unstructured data volumes, model artifacts, and ingest archives are growing exponentially. The traditional response of enterprise IT—constantly expanding proprietary SAN/NAS appliances or uncontrolled outsourcing to US hyperscaler buckets—leads to a dead end: hardware expansions demand six-figure CapEx investments, while cloud object storage with opaque API calls and egress fees drain the IT budget.
Anyone leading a digital team knows that the support helpdesk is the operational nerve center of customer service. Emails, chat messages, and API tickets arrive simultaneously. Customers expect real-time responses, and support staff need split-second search results on historical records to assist efficiently. If the ticket system stalls, communication breaks down. Unsatisfied customers and stressed teams are the immediate consequence.
Operators of business-critical web applications or platform services know: The availability and performance of an application are often determined at the outermost network boundary, the so-called edge. If routing at the entry point fails, even the best-scaled Kubernetes cluster in the background becomes unreachable to the outside world.
The success of modern cloud-native platforms hinges on the security and availability of their software artifacts. When CI/CD pipelines continuously build new container images and Kubernetes clusters deploy them multiple times a day, the container registry becomes the absolute focal point of the IT infrastructure. It is no longer just a passive storage location but the logistical bottleneck and the most crucial control instance of your software supply chain. Relying on unprotected data silos or proprietary black-box services from US hyperscalers risks uncontrolled malicious code in production and the loss of digital sovereignty.
The virtualization of computing power has reached an unprecedented level of maturity through Kubernetes. Containers are launched, moved, and scaled within seconds. As long as applications operate in a stateless manner, this dynamic works seamlessly. However, the reality in enterprise infrastructures is different: databases, content management systems, AI models, and e-commerce platforms require persistent storage media (stateful workloads). They need to store data permanently, performantly, and securely.
This week, I repeatedly asked myself whether we in IT are actually solving problems or just swapping the names of the problems.
In modern cloud-native systems, synchronous communication is a risk factor. When an application communicates directly and blocking via HTTP/REST interfaces with another application, it creates a rigid chain of dependencies. If a single service in the background fails (e.g., a payment API or a logistics system), the entire connection breaks down. The result is incomplete transactions, blocked users, and data loss. To design business-critical platforms, complex enterprise workflows, or data-intensive IoT pipelines to be fail-safe, applications must be isolated from each other and operated asynchronously.
Video streaming and real-time communication are considered the ultimate challenge in IT infrastructure. While traditional SaaS applications or database-driven web apps often absorb minor latency spikes and CPU bottlenecks unnoticed, video infrastructure reacts mercilessly: A minimal configuration error or brief CPU throttling immediately leads to visible artifacts, audio dropouts, or the complete interruption of a live stream, right before the audience's eyes.
Operating a Kubernetes cluster with one of the major US hyperscalers offers significant convenience at the network edge: a single click in the manifest or a simple ingress entry is all it takes, and the cloud platform automatically provisions a highly available external load balancer (like AWS ALB or Google Cloud Load Balancer). The application is instantly accessible worldwide.
When companies distribute their business-critical workloads across multiple regions or in hybrid scenarios (cloud and on-premises), disaster recovery becomes a top priority. Kubernetes clusters are set up redundantly, databases are continuously mirrored, and data sets are synchronized. However, in practice, there is an architectural blind spot that can cripple the entire recovery strategy in an emergency: the availability and geographic placement of the container registry.
In the early stages of container projects, things are usually simple: A small development team builds a handful of microservices, shares a common access to the container registry, and pushes all images into one large, open repository. However, as the containerized infrastructure within a company grows, multiple departments work on clusters in parallel, or external service providers and agencies are integrated into the CI/CD pipelines, this unregulated model reaches dangerous limits.
To maximize the security of your container supply chain, automated CVE scanning at the cluster boundary is essential. The combination of registry scans and admission control ensures that code with known vulnerabilities never gets executed. This clears an important hurdle. However, a fundamental problem remains: a vulnerability scan only checks the *content* of a container at a specific point in time - it does not verify its *origin* and *integrity*.
In the digital age, accessibility is everything. As a company grows, internationalizes its services, or operates critical infrastructures, IT departments invest significant budgets in scaling application servers and database clusters. However, a fundamental component often overlooked in scaling is the nameserver infrastructure. Every connection on the internet begins with a DNS query. If this first step is slow or error-prone, even the fastest backend in the background is of no use.
In modern Cloud-Native design, the principle of functional division of labor applies. As we saw in the first post of this series (Layer 4 vs. Layer 7 Load Balancing), load balancing at **Layer 4 (TCP level)** offers unbeatable advantages in terms of performance, latency, and IT security. Since the system does not open encrypted data packets at the network boundary but forwards them unseen at wire speed to the backends, the infrastructure remains lean and extremely resilient.
When a medium-sized company or corporation decides to modernize its IT infrastructure, migration is almost always on the agenda. Workloads move from the old co-location data center to a modern European cloud provider, or services are relocated back to a private on-premises environment for cost reasons. While the migration of data and compute resources is well manageable today thanks to containerization and modern storage technologies, a massive hurdle awaits at the network boundary: the IP address.
Among system administrators and platform engineers, there's a well-known running gag: When an IT system goes down globally, the web app is unreachable, or internal APIs fail, the first diagnosis is almost always: *"It's always DNS"*. What is humorously portrayed in memes has a serious background in the enterprise environment. The Domain Name System is the invisible nervous system of the internet. If it fails, even the best-replicated application servers in the background are of no use.
Less rigid systems. Fewer monolithic dependencies. Faster deployments. More automation. Greater scalability. More portability.
When IT decision-makers and data engineers discuss the deployment of machine learning and artificial intelligence, the focus is almost entirely on frameworks, algorithms, and GPU performance. However, one aspect is regularly underestimated in the early stages—with fatal consequences for stability in later production operations: **artifact management**.
When a B2B company enters into contracts with highly regulated industries such as banking, insurance, or the automotive sector, the final decision rarely hinges on price or the best sales pitch. The ultimate hurdle is the **supplier audit**. Increasingly, it's not just commercial decision-makers in procurement but specialized IT auditors meticulously examining the handling of sensitive data.
In many medium-sized companies, the IT landscape resembles a collection of digital islands. There is one application for customer contact, another for internal communication, one for document storage, and yet another system for project management. Each of these tools serves its purpose individually. However, because they do not natively communicate with each other, isolated data silos—known as **SaaS silos**—emerge in daily operations.
The use of established US SaaS solutions is standard in the mid-sized business sector. Whether for collaboration, customer support, or document management, the advantages are clear: the applications are ready to use immediately, require minimal in-house IT resources, and offer an excellent user experience.
In the world of complex B2B software and ERP systems, the live demo is the crucial moment of truth. It's where a prospect decides whether they understand the solution's potential or walk away frustrated. While marketing teams invest heavily to generate leads, the process often gets stuck in a technological bottleneck after the inquiry: the provisioning of the demo environment.
"We have a nightly backup." In many SaaS companies, this phrase is the standard response to questions about data security. However, the harsh reality in a disaster scenario often looks different: corrupted backup files, missing configuration data, or recovery times that consume entire business days.
For many SaaS providers, winning a large enterprise client or a public sector contract is a double-edged sword. On one hand, there's the attractive revenue; on the other, the demand: "We don't use public cloud. We need an on-premise installation in our own data center."
In modern event communication, streaming "only" on your own website is rarely enough. Marketing teams want to be where their audience is: on LinkedIn for B2B contacts, on YouTube for the general public, or on Twitch for the younger audience.
Operating Software-as-a-Service (SaaS) or complex eCommerce solutions presents an economic and architectural challenge: the cost structure demands shared infrastructure (multi-tenancy), while compliance and stability require strict separation of customers (isolation).
In software development, versioning code is standard. However, in data engineering and AI projects, this is not sufficient. A model consists not only of code but also of a specific combination of training data snapshots, library dependencies (Python packages), and the weighted parameters of the model itself.
For a long time, IT infrastructure in B2B sales was a peripheral issue. Companies relied on major US SaaS providers because they were considered the "standard." But the tide has turned: In times of tightened compliance regulations like **NIS-2** or **DORA**, the question of **"where and how" data processing occurs** becomes a decisive factor in contract awards.
Enterprise Automation: Building, Versioning, and Sharing Polycrate Blocks Within Teams
For a long time, Elasticsearch was the undisputed standard for log analytics and full-text search. But then Elastic changed its license, effectively excluding the open-source community to block cloud providers. OpenSearch (managed by the Linux Foundation, initiated by AWS) is the answer: A true, Apache-2.0 licensed fork that keeps the original vision alive. Running OpenSearch in your own cluster not only provides a blazing-fast search engine but also all enterprise features (Security, Alerting, Vector Search) that would be costly with Elastic—while maintaining full data sovereignty.
In a world where Microsoft 365 and Google Workspace set the standard, companies often pay with their data. The GDPR compliance of US clouds is perpetually questionable (Schrems II, CLOUD Act). Nextcloud Hub is the answer for those seeking independence. It is far more than just "file storage." With integrated office, video conferencing, and groupware, it is a full-fledged digital workplace. Operated on the ayedo Kubernetes platform, it also overcomes the typical performance issues of traditional LAMP installations and scales for enterprise use.
For a long time, it was said: "SQL Server needs Windows Server." Those days are over. Since Microsoft ported SQL Server to Linux, it has become a first-class citizen of the container world. Running MSSQL on heavy Windows VMs today wastes resources on the operating system and struggles with complex updates. On Kubernetes, MSSQL runs leaner, faster, and more cost-efficiently. It is the perfect symbiosis of enterprise features (T-SQL, stored procedures) and cloud-native agility.
Relational databases are the backbone of almost every business application. However, the market leader MySQL is now owned by Oracle, and cloud providers like AWS RDS charge a premium for hosting ("Managed Service Premium"). MariaDB is the legitimate, community-driven successor to MySQL. It is fully compatible but often technologically superior (faster query optimizer, more storage engines). Running MariaDB in your own cluster provides enterprise performance without license costs and without the constraints of proprietary cloud services.
A Large Language Model (LLM) without access to current enterprise data is like a brilliant professor without a library: it has the world's knowledge but doesn't know your specific projects, documents, or customer histories. To make AI agents truly useful, we use **Retrieval Augmented Generation (RAG)**. The core of this architecture is the **vector database**.
The classic "Data Lake" model has failed. Companies have invested millions in infrastructure to collect data in one place, only to find that this data "rots" there due to lack of context. The Data Mesh breaks with this paradigm: instead of pouring data into a central lake, it remains where it is generated—in the responsibility of the respective domain (e.g., logistics, sales, production).
Edge computing is often touted as a logical evolution of the cloud. Processing power closer to the data source, reduced latencies, more efficient processing of large data volumes – that's the theory.
Multi-Cloud is no longer just a trend. It has become an operational reality—often intentional, sometimes evolved, rarely fully thought through.
Identity is the new perimeter. Outsourcing login and user management to SaaS services like Auth0 or AWS Cognito initially offers convenience but leads to a double trap: exponentially increasing costs with growing user numbers (pay-per-MAU) and limited customizability. Keycloak is the industry standard to regain this sovereignty. It offers a complete, open-source-based IAM solution that scales indefinitely, connects with any existing directory (AD/LDAP), and does not charge a 'tax' per active user.
In a Retrieval Augmented Generation (RAG) architecture, the vector database (Vector DB) is the core component. It provides the Large Language Model (LLM) with context from your enterprise data. However, while traditional databases are primarily optimized for disk I/O, vector databases like **Qdrant, Weaviate, or Milvus** impose entirely new demands on your Kubernetes infrastructure.
The introduction of Artificial Intelligence in small and medium-sized enterprises has opened a new security front. When we train LLMs or build RAG systems (Retrieval Augmented Generation), we move massive amounts of sensitive data through our Kubernetes cluster—often directly onto powerful GPU nodes.
The self-description was promising: "Local & secure AI platform for enterprises", "full control", "independence from the Cloud". The reality: Admin access with a trivial password, unsecured test systems, plaintext credentials in the internal knowledge database, and potential access to systems of over 150 companies – including banks, authorities, energy providers, and public organizations in Germany and Austria.
Cloudflare is far more than just a CDN provider. In addition to performance optimization and security features, the platform offers numerous tools that can be creatively used to address individual requirements in modern infrastructure setups—without necessarily relying on the paid Enterprise features.
**Spoiler Alert:** Yes, it is – and it's not only possible but already a standard in many enterprise environments.