DEV Community: vshosting

Kubernetes Doesn't Have a Cost Problem. Most Teams Have an Operations Problem.

vshosting — Wed, 19 Aug 2026 09:41:08 +0000

For years, Kubernetes has been marketed as the platform that solves infrastructure at scale. It automates deployments, recovers from failures, scales applications, and provides a consistent environment regardless of where workloads run.

Yet talk to enough engineering teams, and you'll hear a very different story.

"Our cloud bill doubled."

"We're running twice as many worker nodes as expected."

"Our platform team spends more time maintaining Kubernetes than improving it."

The obvious conclusion is that Kubernetes is expensive.

The more accurate conclusion is that most organizations are running Kubernetes inefficiently.

After working with production environments across different industries, a pattern starts to emerge. Clusters rarely become expensive because of Kubernetes itself. They become expensive because of operational decisions that seem harmless in isolation but compound over time.

Oversized resource requests. Poor workload scheduling. Underutilized nodes. Too many clusters. Autoscaling without proper observability.

None of these are platform limitations. They're operational challenges.

Kubernetes Is Surprisingly Efficient

One misconception still persists: Kubernetes consumes too many resources.

In reality, Kubernetes itself has a relatively small footprint. The real cost comes from the applications running inside it and, more importantly, from how those applications are configured.

Consider a typical deployment:
resources:
requests:
cpu: "2"
memory: "4Gi"

Nothing looks unusual here.

The application starts, deployments succeed, and everything appears healthy.

Then someone opens Grafana.

Average CPU usage?
0.18 cores.

Memory consumption?

Less than 1 GB.
The scheduler doesn't know that. It only knows what you've told it.

If a pod requests two CPU cores, Kubernetes reserves two CPU cores when placing that workload. Even if the application spends most of its life almost idle, those resources remain unavailable for other workloads.

Multiply that across hundreds of services, and suddenly your cluster appears "full" while half the available compute power sits unused.

The expensive part isn't Kubernetes.

It's inaccurate resource planning.

Bigger Isn't Safer

Many engineering teams intentionally overprovision resources.

It's understandable.

Nobody wants production outages because a service ran out of memory or CPU during peak traffic.

So developers play it safe.

Two CPUs become four.

Two gigabytes become eight.

A few extra worker nodes seem insignificant.

Individually, these decisions don't matter much.

Collectively, they create clusters where utilization rarely exceeds 30 or 40 percent.

Ironically, overprovisioning often reduces reliability rather than improving it. Larger nodes are slower to replace, cluster upgrades take longer, and scaling decisions become less predictable because resource requests no longer reflect reality.

Infrastructure should be sized according to measured demand—not worst-case assumptions.

CPU Limits Aren't Always Your Friend

For years, Kubernetes best practices recommended defining both CPU requests and CPU limits.

Today, many platform teams are revisiting that recommendation.
Memory limits are essential. Running out of memory affects the entire node.

CPU behaves differently.

When a workload reaches its CPU limit, Linux throttles the process. The application isn't crashing, but it suddenly receives less processing time than it actually needs.

The result often shows up as increased API latency, slower background jobs or inconsistent application performance.

Many organizations now configure realistic CPU requests while avoiding CPU limits for trusted workloads.

That approach isn't suitable for every environment, particularly multi-tenant platforms, but it highlights an important point.

There is no universal Kubernetes configuration.

Operational decisions should always reflect workload behaviour rather than generic best practices copied from a tutorial.

Autoscaling Is Not Infrastructure Optimization

Autoscaling has become almost synonymous with Kubernetes.

Enable the Horizontal Pod Autoscaler, configure a few thresholds, and everything should scale automatically.

Except it doesn't.

Autoscaling solves very specific problems.

The Horizontal Pod Autoscaler increases application replicas.

The Vertical Pod Autoscaler adjusts resource recommendations.

The Cluster Autoscaler manages infrastructure capacity.

They're complementary tools, not interchangeable ones.

Adding more pods won't solve inaccurate CPU requests.

Adding more worker nodes won't improve application efficiency.

Scaling infrastructure that's already underutilized simply makes waste more expensive.

Before enabling any autoscaler, platform teams should first answer a simpler question:

Is the current cluster using resources efficiently?

If the answer is no, autoscaling simply accelerates inefficiency.

Observability Is More Valuable Than Optimization

Many infrastructure projects start with optimization.

They should start with measurement.

Every production cluster should answer questions like these without guesswork:

Which deployments consistently over-request CPU?
Which namespaces consume the most memory?
Which nodes remain underutilized?
Which workloads restart frequently?
Which applications experience CPU throttling?
Without that information, optimization becomes an exercise in assumptions.

Tools like Prometheus and Grafana aren't optional extras anymore.

They're operational necessities.

The best optimization project is often the one you decide not to pursue because the metrics show there isn't actually a problem.

Too Many Clusters Create Invisible Costs

Growth often brings another pattern.

Every new project receives its own Kubernetes cluster.
Development.

Testing.

Staging.

Production.

Customer-specific environments.

Regional deployments.

Eventually, infrastructure teams spend more time maintaining clusters than supporting developers.

Each cluster introduces another upgrade cycle.

Another monitoring stack.

Another backup strategy.

Another networking configuration.

Another security review.

Cluster sprawl rarely appears on a cloud invoice.

Instead, it appears in engineering capacity.

Sometimes a well-designed multi-tenant platform with proper RBAC, namespaces and network policies provides exactly the same level of isolation while dramatically reducing operational overhead.

More clusters don't automatically create better architecture.
Sometimes they simply create more work.

The Role of Managed Kubernetes

Managed Kubernetes is often misunderstood.

Some developers assume it means losing flexibility or access to the underlying platform.

Modern managed platforms don't remove Kubernetes.

They remove repetitive infrastructure work.

Developers still deploy with Helm.

They still use kubectl.

GitOps workflows remain unchanged.

CI/CD pipelines continue exactly as before.

The difference is who maintains the platform beneath those workloads.

Instead of spending weekends planning Kubernetes upgrades or replacing failed control-plane components, internal engineering teams can focus on building products.

That's where a managed platform becomes valuable—not because Kubernetes is difficult, but because running production Kubernetes consistently requires operational expertise that many businesses would rather invest elsewhere.

For organizations looking for a fully managed Kubernetes platform hosted in European data centres, vshosting Managed Kubernetes combines upstream Kubernetes with enterprise infrastructure and 24/7 operational support. The goal isn't to change how developers use Kubernetes—it's to reduce the operational burden behind it.

Infrastructure Still Matters

Container orchestration receives plenty of attention.

The underlying infrastructure often doesn't.

Fast storage, reliable networking, low-latency communication and resilient hardware continue to determine how applications perform in production.

Enterprise Kubernetes depends on reliable infrastructure. Learn more about vshosting Private Cloud.

No Kubernetes distribution can compensate for slow disks.

No autoscaler can fix unreliable networking.

Choosing the right infrastructure remains one of the most important architectural decisions.

That's one reason many organizations continue to prioritize providers with enterprise-grade infrastructure, predictable performance and engineers who understand Kubernetes beyond simply provisioning virtual machines.

More information about managed infrastructure, private cloud and Kubernetes services can be found at vshosting.eu.

Final Thoughts

Kubernetes has earned a reputation for being complex and expensive.
Complex?

Sometimes.

Expensive?

Usually not.

In most environments, rising costs are symptoms rather than root causes.

They're symptoms of inaccurate resource requests, limited observability, unnecessary cluster growth and operational practices that haven't evolved alongside the platform.

The encouraging part is that these aren't architectural dead ends.

They're operational improvements.

Teams that continuously measure resource consumption, revisit deployment configurations and simplify platform operations often discover something unexpected.

They don't need bigger clusters.

They need better ones.

If you're evaluating Managed Kubernetes or enterprise infrastructure hosted in European data centers, you'll find more technical resources at Managed Kubernetes: Skalierbare & Sichere Orchestrierung - vshosting.

And that's ultimately what successful Kubernetes adoption looks like—not running more infrastructure, but getting more value from the infrastructure you already have.

7 Mistakes Companies Make When Building GPU Infrastructure for AI

vshosting — Mon, 13 Jul 2026 14:39:20 +0000

The demand for GPUs has never been higher.
As organizations rush to deploy AI applications, many invest heavily in GPU hardware—only to discover that expensive accelerators alone do not guarantee better performance.
Building successful AI infrastructure requires careful planning across compute, networking, storage, software, and operations.
Here are seven common mistakes organizations should avoid.

1. Buying GPUs Before Understanding the Workload

Not every AI application requires the fastest GPU available.
Inference, training, rendering, simulation, and visualization each have different requirements. Selecting hardware before defining the workload often leads to unnecessary costs.
Before investing in hardware, it's helpful to compare different GPU deployment options and understand which platforms are best suited for training, inference, visualization, or HPC workloads.

2. Ignoring Network Performance

As models grow larger, GPU communication becomes increasingly important.
Distributed AI training relies on technologies such as NVLink, NVSwitch, and InfiniBand to exchange data efficiently.
Without sufficient bandwidth, additional GPUs deliver diminishing returns.

3. Underestimating Storage Requirements

AI systems continuously read massive datasets.
Slow storage pipelines create bottlenecks that leave GPUs idle.
Fast NVMe storage and high-throughput file systems are essential for maintaining GPU utilization.

4. Focusing Only on Compute

Many organizations compare GPUs solely by TFLOPS or memory size.
In reality, CPU performance, RAM, networking, storage, and software optimization all contribute to overall application performance.
Balanced infrastructure consistently outperforms isolated hardware upgrades.

5. Forgetting About Power and Cooling

Modern GPU servers consume several kilowatts of electricity.
Power redundancy, cooling capacity, airflow, and rack density should be considered before deploying GPU clusters.
Infrastructure limitations often become deployment limitations.

6. Neglecting Software Optimization

Even the fastest GPUs cannot compensate for inefficient software.
Frameworks such as CUDA, PyTorch, TensorRT, and ROCm allow developers to optimize memory usage, reduce latency, and increase throughput.
Well-optimized software frequently delivers larger performance improvements than new hardware.

7. Assuming Cloud Is Always Cheaper

Cloud GPUs provide exceptional flexibility.
However, continuously running AI workloads often become more economical on dedicated infrastructure over time.
Organizations should evaluate total cost of ownership rather than comparing hourly prices alone.

Final Thoughts

GPU computing is transforming nearly every industry.
However, successful AI infrastructure is no longer about purchasing the most powerful hardware. It is about building balanced systems where compute, networking, storage, software, and operations work together efficiently.
Companies that understand this principle will not only achieve better AI performance but also reduce operational costs while creating infrastructure ready for the next generation of accelerated computing.

AI Agents Are Rewriting the Rules of Web Traffic – And Most Businesses Aren’t Ready

vshosting — Mon, 29 Jun 2026 11:23:42 +0000

Nearly half of internet traffic is no longer human

For years, web security teams have focused on a familiar set of threats: DDoS attacks, credential stuffing, scraping bots, and malicious automation.

But a new category of traffic is emerging — one that doesn't necessarily look malicious, yet can have many of the same operational consequences.

AI agents.

Powered by large language models and autonomous workflows, these systems increasingly browse websites, compare products, retrieve information, query APIs, and gather context on behalf of users. Every prompt submitted to an AI assistant can trigger dozens of requests across multiple websites, databases, and services.

What makes this shift significant is scale.

A single human visitor may view five or ten pages before leaving a website. An AI agent can easily request hundreds of pages, API endpoints, product records, or documentation entries within seconds.

Multiply that behavior across millions of users and the result is a new infrastructure challenge that many organizations are only beginning to notice.

The hidden cost of AI-driven traffic

At vshosting, we analyzed traffic patterns across customer environments and observed a trend that is becoming increasingly difficult to ignore.

In some deployments, automated systems account for nearly half of all incoming requests.

The issue is not necessarily malicious intent.

Most AI crawlers, data collectors, and autonomous agents are simply doing what they were designed to do: collecting information as efficiently as possible.

The problem is that infrastructure must still process every request.
Servers allocate resources.

Applications execute queries.

Databases consume I/O.

APIs generate responses.

Whether the request comes from a customer or an AI agent, the computational cost remains largely the same.

For organizations operating ecommerce platforms, SaaS applications, media services, financial portals, or high-volume APIs, this additional load can quickly become expensive.

The impact usually appears in three areas:

Increased infrastructure costs
Higher server utilization
Reduced performance for legitimate users

Many companies initially discover the issue through cloud invoices rather than security alerts.

When bots become your largest users

One of the most surprising observations is how quickly automated traffic can dominate system resources.

In a recent deployment protected by vshosting's Web Security Pack, more than 96 million requests were processed over a relatively short period.

The protection layer identified over 30 million challenge events and blocked more than 21 million unwanted requests before they reached the customer's infrastructure.

These numbers reveal an important reality:

Organizations often spend substantial resources serving requests that provide little or no business value.

Without filtering mechanisms, all of this traffic would reach application servers, databases, and backend systems.

The result is wasted compute capacity, higher operational costs, and increased performance risks.

AI agents behave differently than traditional bots

Traditional malicious bots tend to exhibit predictable patterns.

They scrape aggressively.
They perform credential attacks.
They generate obvious anomalies.

Modern AI agents are different.

Their traffic often resembles legitimate user behavior.
They navigate websites naturally.
They follow links.
They request product pages.
They access documentation.
They interact with APIs.

From a security perspective, distinguishing valuable automation from wasteful automation is becoming increasingly difficult.

The challenge is no longer simply identifying bad traffic.

The challenge is determining which automated traffic deserves infrastructure resources.

This represents a fundamental shift in how organizations think about web security.

Infrastructure metrics tell the story

Looking at server-level metrics provides a clear picture of the operational impact.

During periods of elevated automated traffic, infrastructure teams frequently observe:

Increased worker process utilization
Higher request concurrency
Significant spikes in load averages
Greater variability in application response times

What makes the problem particularly challenging is that these patterns do not always indicate an attack.

Many organizations see infrastructure stress without obvious security incidents.

The traffic is technically legitimate. The resource consumption is real. And traditional security controls often allow it through.

The rise of traffic optimization as a competitive advantage

Historically, organizations measured success by traffic growth.

More visitors meant more opportunities.

Today, the equation is changing.

As AI-generated traffic continues to expand, successful organizations will increasingly focus on traffic quality rather than traffic volume.

The goal is not to block automation entirely.

Automation creates value.

Search engines create value.

AI systems create value.

Partners and integrations create value.

The objective is to ensure that infrastructure resources are allocated to traffic that supports business outcomes.

Organizations that can intelligently distinguish between valuable and non-valuable automated requests will gain measurable advantages in:

Infrastructure efficiency
Application performance
Operational costs
Customer experience

The next era of web security

The future of web security is not simply about stopping attacks. It is about managing automation. AI agents are rapidly becoming a permanent part of the internet ecosystem.Their numbers will continue to grow. Their sophistication will increase. And their impact on infrastructure will become more significant. For businesses, the question is no longer whether AI agents are visiting their websites.

The question is whether they understand how much infrastructure those agents are consuming-and whether they are prepared to manage it.

The organizations that solve this challenge early will not only improve security.

They will build faster, more resilient, and more cost-efficient digital platforms for the AI-driven web.

What happens inside a data center during a large-scale power outage

vshosting — Fri, 12 Jun 2026 07:08:09 +0000

A large-scale power outage is one of the most practical tests of data center resilience.

It does not only test whether backup power exists. It tests whether the entire chain works together: UPS systems, diesel generators, redundant power distribution, automation, monitoring, operational procedures and the people responsible for keeping the infrastructure running.

One prolonged outage lasting almost five hours became a real-world example of how the vshosting data center responds when the public power grid becomes unavailable. Throughout the incident, the data center remained fully operational, with no interruption to customer services.

The goal: no visible impact on customers

From the customer’s perspective, the desired outcome during a power outage is simple: nothing should happen.

Servers should remain online. Applications should continue running. Websites and e-shops should stay available. The transition from the public power grid to backup power should not be visible at the service level.

During the outage, the data center infrastructure continued to operate as expected. Customer servers remained online, and no service limitations occurred.

That outcome was not accidental. It was the result of a backup power architecture designed for redundancy, tested regularly and supported by defined operational procedures.

Backup power architecture

The vshosting data center uses several layers of power redundancy. The architecture is designed so that a single failure does not threaten service availability.

The backup power system includes:

UPS systems: Vertiv APM modular units
Diesel generators: CAT and Visa units
Redundant power distribution: each power supply has two PDU branches, with each branch backed by double redundancy

The UPS systems continuously stabilize the power supply and protect the infrastructure from voltage fluctuations. If the public grid becomes unavailable, the diesel generators are kept in hot standby mode and start within approximately 30 seconds.

This is a critical part of the design. The UPS systems bridge the transition between the grid outage and generator operation, so servers and other critical systems continue running without interruption.

Why UPS systems matter

In a data center, power resilience is not only about having generators.

Generators take time to start, stabilize and take over the load. Even if that time is short, the infrastructure still needs continuous power during the transition.

That is where UPS systems come in.

They help protect the environment against:

short power drops
voltage fluctuations
brief interruptions
the transition period before generator takeover

In practice, the UPS layer ensures that critical systems do not experience the outage directly, even when the public grid fails.

Regular testing is essential

A backup system is only useful if it works when it is needed.

That is why vshosting performs controlled backup power tests four times a year. These are not just basic checks. During the test, the technical team deliberately disconnects the power supply and verifies whether automatic procedures work according to defined scenarios.

The process is coordinated across the data center. Specialists are present in individual technical rooms, monitor the situation in real time and communicate with the control room.

This type of testing helps validate three things:

whether the technology behaves as expected
whether automatic procedures are triggered correctly
whether the team is ready to follow the required operational steps

During the outage itself, the systems behaved as expected. The generators started as designed, the backup infrastructure was continuously monitored, and internal systems ran at full capacity without restrictions.

Fail-safe mechanisms

Power infrastructure needs more than one fallback layer.

If one of the primary backup components becomes unavailable, additional systems and procedures must be ready to take over.

The data center setup includes:

backup diesel generators in case the main units fail
automated procedures for different failure scenarios
escalation processes for manual intervention
24/7 availability of trained data center personnel

Automation plays a key role, but it is not the only safeguard. A reliable operating model combines automated response, redundant hardware and experienced people who know how to respond during an incident.

What happens operationally during an outage

From an operational perspective, the response follows a defined process.

Once an outage is detected, the team immediately checks whether the automatic systems have responded correctly and whether the backup infrastructure is running as expected.

The next steps include:

monitoring the status of backup power systems
checking internal systems
identifying the cause of the outage
assessing the expected duration
staying ready for escalation if needed

In this case, the scale of the blackout was unusual, but the response inside the data center was controlled and routine. The alarm system worked as expected, backup power took over, and the operation of the server room remained unaffected throughout the outage.

Service continuity during the blackout

For customers, the most important result was that their servers kept running.

During the blackout, vshosting customer support received only two inquiries related to the autonomy of backup power sources and service availability. The company also received positive feedback from clients on social media, who appreciated that their websites, applications and e-shops remained available while other services were affected by the outage.

Based on client feedback on social media, the situation was significant in a broader context as well. While some services, such as payment terminals, mobile networks, healthcare facilities operating on backup power and industrial operations, were affected by the outage, websites, applications and e-shops running at vshosting remained available.

What this incident confirmed

The blackout did not reveal the need for a fundamental change in the backup power strategy. Instead, it confirmed the importance of long-term investment in redundancy, automation, testing, maintenance and operational readiness.

In the past, the vshosting data center has also experienced very short power fluctuations lasting fractions of a second. In all such cases, the systems responded according to specification. This blackout was exceptional mainly because of its duration, not because of its technical complexity from the data center’s perspective.

100% power availability since opening

Since opening in 2015, the vshosting data center has maintained 100% power availability without outages. This real-world blackout scenario became another confirmation that the infrastructure, processes and team readiness meet the demands of critical IT operations.

For organizations running business-critical websites, applications, e-shops or internal systems, resilient infrastructure is not just a technical advantage. It is a requirement for service continuity.

Redundant power systems, regular stress tests, disaster recovery planning and trained technical teams are not optional extras. They are the foundation that keeps services running when a real incident occurs.

To learn more about the technical infrastructure behind vshosting services, visit our Technology page.

A blackout shows whether backup power systems work only on paper, or whether they can protect real businesses in real time. In this case, the systems worked exactly as they were designed to.