🚩 Tasks:

1. The client received grant loans from Google to develop their product and decided to migrate from Hetzner to GCP. Key requirements.
2. Migration in the shortest possible time.
3. Zero Downtime.
4. Elimination of 502 errors during peak loads.
5. Optimization of backend application performance.

What we found:
During the audit of the current infrastructure and code, we identified the following critical bottlenecks:
❌ Incorrectly configured Puma, unable to handle the combat load.
❌ Slow SQL queries in PostgreSQL, slowing down the API response.
❌ Lack of a graceful shutdown mechanism, which caused connection breaks and resource leaks.

What we did:

1. We quickly designed and implemented a fault-tolerant cloud infrastructure based on Google Kubernetes Engine (GKE) with full IaC via Terraform.
2. In parallel:

• Together with development, we adapted a Ruby on Rails application to work in Kubernetes.
• Solved the problem with graceful shutdown to minimize connection losses during deployment.
• Rebuilt CI/CD pipelines using GitLab, Helm, and ArgoCD.
• Configured automatic scaling based on custom metrics, which allowed us to handle traffic without 502 errors.
• Optimized SQL queries and made changes to the DB schema.
• Added preemptible nodes to significantly reduce costs without losing fault tolerance.

Results:
✅Sustainability and performance increased exponentially.
✅Budget savings thanks to competent architecture.
✅The migration took place without downtime or incidents.

🚩 Tasks:
The client asked to scale and stabilize a key part of their high-load platform.

1. Migration of a monolithic application to Kubernetes.
2. Increasing the stability and performance of an Elasticsearch cluster (100+ physical nodes).
3. Ensuring fault tolerance for RabbitMQ and Redis.
4. Resolving chronic instability of a PostgreSQL cluster on Patroni.

Audit: what we found
During a deep diagnostics of the existing bare metal infrastructure, critical bottlenecks were identified:
❌ Elasticsearch: incorrect cluster architecture and settings, no backup, uncontrolled index growth, violation of the Master/Data/Client role principles.
❌ RabbitMQ: one instance without a cluster is a single point of failure.
❌ Redis: a similar problem - one node without replication.
❌ Patroni + PostgreSQL:

• etcd cluster consisted of one node, which violated consensus and led to split-brain.
• synchronous replication was used, blocking write operations when replicas failed.
• non-optimal queries were identified that slowed down SELECT operations under high loads.

Solution: what we did
Kubernetes platform

1. Deployed a fault-tolerant Kubernetes cluster on bare-metal.
2. Implemented full Infrastructure as Code (Terraform, Ansible, Helm).
3. Migrated business-critical applications with minimal downtime.

CI/CD

1. Built automated pipelines with GitLab CI, Helm and ArgoCD.
2. Configured environments, canary and rollback mechanics.

Elasticsearch
Complete reconfiguration: split roles (master, ingest, data), set up shard allocation awareness.

• Implemented snapshot-based backup.
• Eliminated bottlenecks at the JVM and heap levels.

RabbitMQ & Redis

• Implemented a RabbitMQ cluster (3 nodes + ha-policy).
• Implemented a Redis cluster with automatic failover and replication.

PostgreSQL (Patroni)

• Configured a fault-tolerant etcd cluster for Patroni.
• Updated Patroni and PostgreSQL, abandoned rigid synchronous replication.
• Optimized SQL queries and added indexing on critical tables.

Results:
✅ Increased fault tolerance of all critical components.
✅ Significantly improved performance of search and analytical queries.
✅ Eliminated points of failure without changing the business logic of applications.
✅ Ensures horizontal scaling without downtime.

🚩 Tasks:

1. Migrate from Proxmox to Kubernetes without losing service availability.
2. Ensure PostgreSQL and ElasticSearch Fault Tolerance.
3. Solve PostgreSQL Connection Overload Issue.
4. Set up GitOps deployment with ArgoCD and Helm.
5. Make the infrastructure transparent and self-sufficient.

What we found:
❌ The team faced a typical situation: manual deployment in Proxmox, no custom feature stands, PostgreSQL overloaded with connections, Elastic without replication. There was a high dependence on traffic surges. The infrastructure did not scale and could not withstand peaks.

Solution: what we did

1. We built a fault-tolerant Kubernetes cluster on dedicated servers.
2. We migrated PostgreSQL to Patroni with PgBouncer - now there is HA and protection from excessive connections.
3. We set up CI/CD via Helm and ArgoCD - Auto Builds, Auto Deployment, Application Sets for feature stands.
4. Added automatic launch of temporary environments (feature/review) by PR - saving time for QA and developers.
5. Setting up VictoriaMetrics stack: Vmcluster, Alertmanager, Grafana, Loki.
6. Fixed single point of failure.

Results:
✅ PostgreSQL no longer crashes under load.
✅ Auto Deployment has become reliable and predictable.
✅ Temporary environments launch in minutes, without manual magic.
✅ The team works faster and more confidently.
✅ The business received a platform that can be scaled and developed.

🚩 Tasks:
To completely build a cloud infrastructure in Google Cloud Platform based on Infrastructure as Code (IaC) principles, migrate existing applications to Kubernetes (GKE), ensure secure interaction between services, and organize network connectivity between all company projects within GCP.

What we found:
❌ Lack of standardized infrastructure and IaC approach.
❌ Services were launched manually, without automated CI/CD.
❌ There was no secure authentication model between services.
❌ Inter-project network interaction in GCP was disjointed and unmanaged.

What we did:

1. Implemented infrastructure as code (IaC) using Terraform and centralized CI/CD.
2. Configured Shared VPC to manage network connectivity between projects.
3. Migrated all applications to Google Kubernetes Engine (GKE).
4. Implemented Workload Identity for secure authentication without using secrets.
5. Developed CI/CD pipelines based on GitHub Actions, Helm, and ArgoCD.
6. Introduced Preemptible nodes to save resources.

Results:
✅ The speed of deploying new infrastructure has been reduced from weeks to minutes.
✅ The security of interaction between services has been significantly increased, the use of static keys has been eliminated.
✅ A single scalable cloud platform where each new application is automatically integrated into GKE and CI/CD.
✅ Full control of the network architecture between all company projects within GCP.
✅ Improved fault tolerance and version control through the GitOps approach and Helm charts.
✅ Reduced costs for Google Cloud Platform infrastructure by 50%.

🚩 Tasks:

1. Take over and audit the infrastructure previously deployed by a third-party DevOps team in AWS.
2. Identify performance and stability issues in RDS Aurora and EKS.
3. Optimize the infrastructure in terms of cost and efficiency.
4. Plan and implement migration to dedicated servers to reduce costs.

What we found:
The following critical issues were identified during the audit:
❌ Incorrect configuration of Auto Scaling Groups in EKS.
❌ Errors 502 and 504 when deploying applications due to the lack of readiness probes and incorrect load assessment.
❌ Lack of spot instances, which led to irrational use of resources.
❌ Complete lack of Infrastructure as Code, infrastructure management was carried out manually.
❌ Outdated and unstable approach to deploying applications.
❌ Unoptimized SQL queries affecting RDS Aurora performance and cost.

What we did:

1. Built infrastructure as code (IaC) using Terraform and GitLab CI/CD, Ansible.
2. Reconfigured EKS cluster: implemented Horizontal Pod Autoscaler (HPA) based on custom metrics.
3. Developed CI/CD pipelines on GitLab with Helm and ArgoCD.
4. Optimized SQL queries, reducing the load and cost of RDS Aurora by 2 times.
5. Migrated from RDS Aurora to Patroni cluster (PostgreSQL) — DBMS costs decreased by another 3 times.
6. Introduced spot instances, which further reduced operating costs.
7. Improved monitoring: instead of Prometheus, a VictoriaMetrics cluster was implemented, providing greater scalability and stability of monitoring.

Stage 2: Moving to Hetzner (dedicated)

1. Complete migration of all services from AWS to Hetzner on dedicated bare-metal servers.
2. An overlay network for inter-node interaction with traffic isolation was implemented.
3. The migration took place without downtime (zero downtime) thanks to gradual traffic switching and competent CI/CD.
4. Infrastructure costs were reduced by 5+ times without loss of reliability and fault tolerance.

Results:
✅ Infrastructure spending has been reduced by more than 5 times.
✅ Improved stability and speed of releases thanks to GitOps and Helm.
✅ Reliable automation and safety standards have been implemented.
✅ Improved fault tolerance and horizontal scalability of the infrastructure.
✅ ЗThe load on the database has been significantly reduced and application performance has been improved.

🚩 Tasks:
Typical problems of very fast growth:

1. Improve the process of deploying applications to Kubernetes and get rid of downtime.
2. Achieve fault tolerance for PostgreSQL.
3. Increase the stability and availability of a loaded web application.
4. Provide extended observability of the network stack.

What we found:
❌ A large number of outgoing DNS requests caused by incorrect ndots configuration, this led to DNS overload and 5XX errors.
❌ The Calico network stack turned out to be insufficiently effective for observability tasks and the current load.
❌ PostgreSQL suffered from slow requests and a large number of connections, creating performance bottlenecks.

What we found:
Infrastructure and deployment:
Developed a deployment using GitLab CI/CD, Helm and ArgoCD, which reduced downtime and accelerated code delivery to Kubernetes.

Database:
Implemented pgbouncer for connection management and eliminated slow queries, significantly increasing PostgreSQL performance.

Network and observability:

1. Reduced the number of DNS queries by 10 times, eliminating 5XX errors and reducing the load on DNS.
2. Moved from Calico to Cilium, which improved the observability and stability of the network stack.

Results:
✅ Almost zero downtime when deploying applications.
✅ Significant improvement in PostgreSQL performance and fault tolerance.
✅ Reduced DNS load and the disappearance of 5XX errors.
✅ Increased SLA and uptime of a loaded web application.
✅ Improved observability and control of the network stack.

🚩 Tasks:

1. Migrate the entire architecture to Kubernetes.
2. Automate CI/CD with zero-downtime releases.
3. Provide access to stands at the touch of a button - quickly and reliably.
4. Increase the stability and transparency of infrastructure.

What we found:
❌ AI platform Stylus faced a typical problem of scalable projects: microservices grew, and the infrastructure could not keep up. The team spent a lot of time on manual deployment, there was no fault tolerance, and launching a new feature stand was a pain.

What we do:

1. We transferred the entire project to Kubernetes (EKS) and wrote a Dockerfiles.
2. We set up CI/CD on Helm + ArgoCD with ApplicationSets — now we can deploy without downtime and with automatic rollback.
3. We implemented feature/review stands that can be set up in a couple of minutes. It's ideal flow for QA and review.
4. We implemented monitoring and logging. Everything is under control now.
5. We optimized resources and got rid of unnecessary load.

Results:
✅ The release time for a new feature has been reduced from days to minutes.
✅ Developers work faster. Stands are launched automatically.
✅ The infrastructure is predictable and scalable.
✅ Businesses receive a reliable platform with high availability and transparent support.