Modern infrastructure isn't just built to last—it's built to evolve. These days, cloud architecture isn't just about uptime, but about adaptability, scale, and automation. In this interview, Site Reliability Engineer Vladyslav Haina shares what makes architecture truly scalable, why platform engineering is on the rise, and how observability and well-placed guardrails already shape the future of cloud engineering.
Vladyslav, you've worked on infrastructure for projects of very different scales. What would you say is the key principle behind building a cloud architecture that can truly handle business growth and increasing loads over time?
I'm convinced that the key principle is adaptability. Scalability isn't just about autoscaling groups or serverless functions—it's about building systems that can evolve alongside the business. That means using a modular architecture, managing infrastructure as code, and relying on decoupled services so individual parts can be replaced or scaled independently.
From experience, observability and automation are just as critical. If you can't measure it, you can't scale it effectively. And if scaling depends on manual intervention, it quickly becomes a bottleneck. The most successful systems I've seen scale naturally because they're designed to grow—not just to function one day at a time.
When a business comes in and says, "We need to move to the cloud"—in your opinion, where should that journey always start? What risks or common mistakes do companies often overlook in the early stages?
It should always begin with discovery—mapping out the current state of systems, applications, and data, then aligning that with business goals. Too often, companies rush into a lift-and-shift approach, thinking it's the fastest route. But without a proper assessment, they risk carrying over existing inefficiencies into the cloud and driving up costs unnecessarily.
I always start by asking: where are people still doing manual work? That's exactly where labor automation comes into play. People often carry over old habits when they start using cloud services—like managing infrastructure through ticketing systems or manually deploying. Initially, these tasks don't seem like a big deal, but in the end, they're what keeps you from scaling. By automating them, not only do you save time, but you also reduce risk, increase consistency, and let engineers focus on real business problems instead of repeating themselves. My experience shows that introducing automation early on made it easier to enforce guardrails, standardise environments, and build momentum within the team.
Some of the most commonly overlooked risks include underestimating cloud expenses, particularly data egress fees or misconfigured resources, overlooking security gaps during migration, and assuming the team is cloud-ready when it may not be. That's why I usually recommend starting with a few clearly defined services, establishing a landing zone with strong guardrails, and prioritising team enablement right from the start.
You've worked with AWS, GCP, and Azure simultaneously. How do you approach choosing the right technologies or cloud providers? When does a multi-cloud strategy really make sense—and when is it just unnecessary complexity?
The choice should always be based on the use case, how well the provider fits your ecosystem, and the internal capabilities of your team. AWS is often the go-to for its breadth and maturity of services. GCP stands out when it comes to data engineering, machine learning, and Kubernetes-native environments. Azure tends to be the best fit in Microsoft-heavy setups, especially when enterprise identity management or Office 365 integration is involved.
A multi-cloud strategy can make sense in specific scenarios—for example, when you need redundancy across providers to meet compliance or high-availability requirements, when your company is acquiring others that are already operating on different clouds, or when you're looking to optimise specific workloads, like running BigQuery on GCP while using AWS for compute. But outside of those cases, multi-cloud often introduces complexity without a clear return on investment, especially if the operations team isn't equipped to handle multiple policy frameworks, cost models, and monitoring systems across platforms.
Can you recall one of the toughest infrastructure challenges or architectural puzzles you've faced during your work at the Bank? How did you manage to solve it?
One of the most complex challenges I faced at the bank was reducing deployment risk in a tightly regulated, multi-region environment. We worked with dozens of services, all dependent on shared infrastructure, which meant that even a single misconfigured change had the potential to trigger cascading failures.
To manage that risk, we implemented progressive delivery using canary releases. This allowed us to test changes gradually in production before rolling them out fully. We also introduced automated policy enforcement to catch misconfigurations early and added service-level health checks directly to the delivery pipeline. These checks acted as gatekeepers, blocking faulty updates before they could propagate across the system.
Together, these changes significantly reduced our mean time to recovery and change failure rate—and just as importantly, they helped build trust with the leadership. Over time, this gave teams the confidence to release more frequently, which marked a major cultural shift across the organisation.
You led the modernization of cloud infrastructure, serving over 900 healthcare offices. What technologies or architectural decisions were most critical to ensure that the system was stable, scalable, and secure at the same time?
We focused on three core pillars. First, standardisation: we built reusable Terraform modules and containerised all services, which allowed us to enforce a consistent baseline configuration across all dental offices. Second, a zero-trust architecture: each microservice had identity-aware access, and all sensitive data access was tightly controlled through secret management and IAM roles. Third, we ensured edge and regional failover by using Cloud CDN, deploying regional GKE clusters, and applying health-based routing, so that services remained operational even if an entire zone experienced downtime.
What really made the difference was combining observability with automation. Dashboards connected to real-time alerts allowed us to detect anomalies proactively, often before they had any impact on patients or staff.
How do you see the future of cloud engineering? What changes do you expect in system architecture and the role of infrastructure teams over the next 3–5 years?
We're moving toward platform engineering as the next stage in cloud infrastructure evolution. Cloud engineering teams are no longer just managing resources—they're building self-service platforms where developers can deploy, monitor, and scale their own services within a well-governed environment.
In the next few years, I expect to see more AI-powered automation in operations, particularly in areas like anomaly detection and predictive scaling. Edge computing will continue to rise, especially for latency-sensitive applications. At the same time, there will be a growing emphasis on cost-aware architecture, with FinOps practices becoming increasingly mainstream.
The boundaries between development, data, and infrastructure are steadily dissolving. As a result, infrastructure engineers will need to be fluent not only in technical execution but also in product thinking and data fluency.
And finally, what motivates you personally today as an engineer and leader? What are you most curious to explore or experiment with right now when it comes to cloud and infrastructure?
I find a lot of motivation in solving problems that scale, and in seeing how engineering can unlock real business outcomes. It's genuinely fulfilling to build systems that teams can rely on, whether that's delivering healthcare, handling real-time data, or powering great customer experiences.
Lately, I've been especially curious about autonomous infrastructure—systems that can optimize themselves based on patterns. I'm experimenting with policy-driven pipelines, applying machine learning to observability, and using AI in CI/CD workflows. It's an exciting space where a lot is evolving fast.
And I've always been drawn to anything that reduces toil. When you remove repetitive work, you create space for engineers to think, design, and actually innovate—and that's where the real impact happens.
