Configuring VK Cloud: why the environment fails under load
While traffic grows gradually, the environment looks healthy: response is predictable, metrics are normal. The first peak — a sale, an ad campaign, a seasonal surge — and degradation under load begins: the request queue grows, response time climbs, some services return errors.
The cause is usually not the code, but the fact that the cloud infrastructure configuration was designed for the current profile rather than the peak one: there is not enough reserved capacity, there is no autoscaling, and connection limits hit the ceiling.
The second source of failures is manual configuration changes. Someone adjusted a load balancer rule through the panel, someone added a port to a security group, someone manually expanded a disk for logs.
The changes are not recorded anywhere, environments diverge from one another, and it is no longer possible to assemble a working state from scratch: VK Cloud configuration turns into a set of verbal agreements held in one engineer's head.
A separate risk line is the absence of a fault-tolerance scheme. One application node, one disk, one database instance: any hardware failure or scheduled maintenance turns into hours of service downtime, and recovery is done manually, from memory, and under pressure.
Below we break down how this is addressed — from redundancy and managed services to describing infrastructure in code.
What a properly built cloud environment provides
A properly built environment in VK Cloud is distinguished not by the list of connected services, but by the fact that its behavior is predictable at two points: at the moment a change is released and at the moment of failure.
Both effects are measurable — by time and by the share of operations that proceed without manual intervention.
Predictable change release time
Environments are spun up from templates, and configurations and secrets live in the repository, so the development stand and production environment do not diverge. A change goes through the same pipeline: immutable image build, automated checks, migrations, deployment.
Then reversibility works — rollback is the deployment of the previous image, not a manual analysis of consequences. Release time stops depending on who is on duty, and the share of changes reaching production without manual edits grows to nine out of ten.
Resilience to node and zone failures
Application instances are distributed across several availability zones, the load balancer removes unhealthy nodes and shifts traffic to healthy ones.
The environment survives the failure of an individual node or process on its own: recovery after a failure is measured in minutes, not in the time until the duty engineer arrives.
For each failure class — process, node, zone, region — its own scenario and target recovery time are defined in advance. Backup runs on a schedule, but more important is regular verification of recovery from a copy: an unverified copy is not considered working.
Environment configuration: deployment options and their limitations
The choice of deployment option in VK Cloud determines which failures you get and what trade-offs they bring. A managed cluster removes control-plane maintenance but imposes provider limits.
Virtual machines give control over the kernel, disks, and network at the expense of manual maintenance. Hybrid is a compromise in which the communication channel becomes a separate point of failure.
| Option | When it fits | Limitations |
|---|---|---|
| Managed cluster | Microservices with horizontal scaling, fast start, updates without downtime | No access to nodes and control plane, update windows are set by the provider, quotas on nodes and disks |
| Virtual machines | Custom kernels, DBMS with fine-tuning, licensed software, non-standard networks | Updates, redundancy, and scaling are on the team's side |
| Hybrid scheme | Part of the data must remain in its own perimeter, peaks go outside | Channel latency, two monitoring perimeters, a second point of failure |
Isolated perimeter for a single service
A separate project, its own networks, quotas, and access policies. Such a perimeter is needed when a service processes sensitive data or its failures should not affect neighbors: a failure and an unsuccessful update remain within the boundary.
The trade-off is duplicated gateways, monitoring, and manual maintenance, which is noticeable for a small service.
Shared environment for several teams
One cluster and one network, teams separated by namespaces with quotas, limits, and network policies by default. Resource utilization and a shared image registry have an effect: more services fit on the same infrastructure.
The downside is the "noisy neighbor" and a shared failure domain, so limits are set before the second team arrives, not after an incident.
How implementation proceeds: stages of engineering work
VK Cloud configuration begins with an inventory: which services are already in production, who accesses them, and what relies on manual actions. Without this picture, the architecture diagram remains a hypothesis, and access separation is a formality.
What we capture at the input
We compile a list of services with owners, load profiles and peaks, fault-tolerance requirements, and permissible change windows.
We separately list external dependencies — databases, queues, integrations with internal systems: they most often determine what is migrated immediately and what requires an intermediate perimeter.
Order of work
- Infrastructure audit: resource inventory, review of the network, storage, backups, and current access rights.
- Architecture diagram: availability zones, subnet segmentation, failure points, scaling rules.
- Access separation: roles of teams and service accounts with the minimum necessary rights.
- Configuration: infrastructure as code, reproducible rollout, change checks before reaching production.
- Load testing: a profile close to production, measurement of response time and behavior during node failure.
- Documentation handover: diagram, recovery regulations, instructions for the duty shift.
How we accept the result
We agree on the criteria in advance: the perimeter is deployed from scratch without manual steps, recovery fits within the agreed time, and service accounts have no excessive rights. Acceptance is based on these checks, not on the fact that "the work is handed over."
Documentation, diagrams, and regulations as deliverables
After project handover, the infrastructure does not remain a "black box": every decision is captured in artifacts your team can use independently, without contacting us.
The set is assembled during the work rather than written at the end, so it describes the actual state of the environment, not the original intent.
- Infrastructure diagram: network segments, load balancing, connections between services and external systems.
- Environment documentation: purpose of each component, configuration parameters, dependencies, and failure points.
- Maintenance regulations: scheduled work, backups, update and rollback procedures.
- Access policies: roles, permission boundaries, granting and revoking access, key and secret rotation.
- Team instructions: how to spin up a stand, release a version, collect logs and metrics, and what to do during a failure.
- Incident response map: trigger thresholds, responsible parties, escalation procedure.
- List of external dependencies: third-party services, their owners, and terms of use.
Handover formats
We provide diagrams in editable form with export for printing — they can be extended as the environment grows.
We place instructions and regulations next to the configuration in the repository: they change with the same change as the infrastructure itself and do not diverge from reality.
We hand over access not as a list in an email, but through role management and a secure secret store — you can see at any moment who has which rights and revoke them with one action.
Case study: how the environment withstood a threefold load increase
The client came with a service that followed seasonal promotions: at peak, the number of simultaneous requests tripled within a few hours.
The environment was assembled manually according to instructions, some settings were duplicated in two places and gradually diverged, and scaling was handled by the duty engineer at night.
The very first surge showed that the bottleneck was not in the application code, but in how the infrastructure was designed.
What the metrics showed before and after
- Recovery after node failure: hours of manual actions → a few minutes — state is moved outside the server and spun up again from a template.
- Share of manual operations during release: more than half the steps → single confirmations, the rest is covered by automated checks.
- Failures at peak: every surge → none; three consecutive load increases ran on the standard configuration without nighttime intervention.
The environment description was converted to a declarative form and placed in VK Cloud: servers, network, and access rules are now created from a single source, so stands stopped diverging from one another.
Liveness and readiness checks remove a node from load balancing before it starts returning errors, and autoscaling adds capacity for a peak and removes it afterward — without requests and approvals.
A separate class of failures also went away — one that previously was caught only through complaints: "silent" degradation of a single node when traffic continued to go to it.
Now such cases are handled automatically, and the engineer sees the change history and understands exactly what led to the deviation.
Technical concerns before starting work
Engineering objections before moving to the cloud usually come down to four: service downtime, responsibility for the environment after handover, access separation, and the risk of rework. We explain how we address each.
How do you migrate without stopping the service?
The database moves via streaming replication; we synchronize volumes and object storage until lag is down to seconds.
At cutover, we lower the TTL of records and route traffic first with a small share, then fully: the write unavailability window is measured in minutes, and it has a reverse plan to return to the original perimeter.
Who is responsible for the environment after handover?
The environment is described as code: configuration, network rules, and policies live in the repository, and changes go through review.
Support remains with us at an agreed level, and if the team takes over management — we hand over diagrams, regulations, and access so that the perimeter can be understood without us.
How are team accesses separated?
A personal account for each engineer, rights — on the principle of least privilege.
Service accounts for automation are separated from human ones, secrets are stored with rotation rather than in configuration files, and access to the production environment is granted on request, for a limited time and with an audit of actions.
Can you scale gradually, and how is load tested?
We start with one perimeter and add services as they are ready — the migration does not turn into a simultaneous replacement of everything.
We capture the load profile from the running system and run it on the new one before cutover: capacity is confirmed by measurements, and we configure autoscaling in advance, before production traffic.
Let's discuss the task and come back with an estimate and plan
We assemble the implementation plan from your perimeter, not from a template: first an analysis of the current state and limitations, then the scope of work by stages — with a verifiable result at each.
Below is what is needed from your side so that we come back with an estimate and schedule, not general wording.
- Load and current scheme description: which services run, what is already placed in the cloud, where the bottlenecks are.
- Access for analysis: reading configurations, exporting metrics and logs, network and routing diagram.
- Limitations: requirements for data placement, security regulations, change windows.
- Target indicators: response time, failure rate, recovery time after a failure.
- Integration points: external systems, queues, and storages with which the perimeter needs to be linked.
- Acceptance owner: who approves the stages and accepts the result for each of them.
Then we form the scope of work: what we do during design, what during load migration, and what remains in support. We describe each stage with a readiness criterion and rollback procedure so that changes proceed predictably and without downtime.
Describe the task in a convenient format — correspondence, a call, or a meeting. We will come back with an estimate, an implementation plan, and a starting order: who does what and in what sequence from day one.
How does a cloud environment differ from your own servers?
The difference starts with the responsibility boundary. In a cloud environment, the provider maintains the physical hardware, network, disks, and virtualization layer, while operating systems, service configuration, data, and access remain on our side.
On your own servers, the boundary shifts all the way to the power outlet and communication channel: diagnosing a disk failure, replacing components, and keeping spare parts are already the infrastructure owner's task.
The second difference is time to result. A new perimeter is described with declarative configuration and spun up in minutes, not in a procurement and installation cycle.
Fault tolerance in the cloud is achieved by placement across availability zones, whereas on your own hardware it has to be maintained as a permanent reserve that sits idle on ordinary days.
Your own servers are justified where the load is even and predictable, where data must remain within a specific perimeter, and where specialized hardware or legacy systems are in use, whose migration is more expensive than maintaining them on site.
It is precisely in these cases that comparing options ends not with a choice of "cloud or your own servers," but with hybrid infrastructure.
In a hybrid scheme, latency-sensitive services remain on your own hardware, while new products, test environments, and peak loads go to VK Cloud and are connected to the internal perimeter via a private channel. Management is unified: configuration as code, shared access policies, one monitoring.
Environment support is structured the same way for both parts, and migration to the cloud proceeds in parts — first the test perimeter, then stateless services, and only then databases with replication and rollback verification. This order allows comparing options under live load without stopping the product.