Danylo Mikula, DevOps & Infrastructure Architect, led a shift from manual processes to declarative workflows – cutting cluster provisioning time by 97%
For many enterprise engineering teams, Kubernetes has long passed the innovation stage and settled into the category of everyday critical infrastructure. Yet maintaining that infrastructure efficiently – especially across multiple clusters and environments – remains a challenge that slows down feature delivery and increases operational risk.
At a global healthcare technology company operating in highly regulated environments, this challenge was particularly acute. The organization managed hybrid infrastructure spanning on-premises data centers and cloud environments – multiple Kubernetes clusters and thousands of virtual machines powering critical workloads.
Provisioning a production-ready cluster was a lengthy process that could take weeks of coordinated effort across multiple teams. Keeping infrastructure applications current was time-intensive, as configuration histories lacked centralization – adding overhead to routine operations.
That changed when Danylo Mikula, a DevOps & Infrastructure Architect with over a decade of experience in regulated industries, joined the platform engineering team in late 2023 and set out to overhaul the way infrastructure was managed. The mandate, as Danylo describes it, was deceptively simple.
“The goal wasn’t to introduce new tools for the sake of modernization. It was to make existing infrastructure easier to operate, maintain, and scale – without increasing staff or complexity.”
– Danylo Mikula, DevOps & Infrastructure Architect
From Manual Steps to Declarative Workflows
The core of the transformation centered on consolidating fragmented processes into a GitOps-based model. Instead of engineers applying configurations manually to each cluster, deployments moved into version-controlled repositories, with a GitOps operator handling synchronization.
The bottlenecks he encountered existed at every stage. Container networking required coordination between platform engineering and networking teams, with configurations distributed across the organization rather than managed centrally. Infrastructure applications were deployed manually, and secrets management followed traditional manual approaches. Deployment processes had evolved organically over time without a unified framework. By consolidating each phase into version-controlled Helm charts with environment-specific overrides, Danylo reduced the time per stage from days to minutes.
The GitOps architecture Danylo built followed a “define once, deploy everywhere” philosophy. A central repository held shared service definitions that automatically generated cluster-specific deployments, while each environment maintained only its unique overrides. “Instead of copying configuration files across every cluster individually,” Danylo explains, “we created a system where adding a new service meant writing one definition and letting automation handle the rest.” This approach covered dozens of infrastructure components – from data stores and messaging systems to security and monitoring tools – while dramatically reducing the risk of configuration drift.
Secrets distribution was integrated into the same GitOps pipeline: a Vault-native operator synchronized secrets into each cluster automatically, ensuring that changes flowed through a controlled process with proper audit trails.
The result was a fundamental shift in how infrastructure was managed. Provisioning time dropped to approximately 30 minutes – a 97.6% efficiency improvement. Updates became consistent and repeatable, and onboarding new engineers required less tribal knowledge. Members of the cloud engineering leadership team noted that the improvements extended beyond the technical: with multiple teams contributing to the same environments, the shift to a shared source of truth made collaboration itself more predictable.
The Human Factor in Technical Change
Colleagues point out that the success of the shift wasn’t purely technical. GitOps wasn’t familiar to everyone at the start, and part of the effort involved making the approach understandable and usable for engineers who had spent years in imperative workflows. Those who worked through the transition say the architecture was strong, but what stood out was how adoption was enabled – taking time to walk engineers through the model meant that anyone on the team could deploy or modify infrastructure without needing years of accumulated context.
As a result, infrastructure updates – previously treated as risky – became routine. Teams gained confidence running scheduled upgrades because deployment histories were visible and reproducible.
Security as a Side Effect
Security improvements were equally significant. Previously, maintaining consistent patch schedules was difficult – without centralized configuration management, keeping every cluster current required significant manual effort, especially as teams evolved.
With all configurations now version-controlled, the team could finally maintain consistent update schedules and track exactly what was running where. The integration with HashiCorp Vault ensured secrets were managed consistently across the infrastructure with proper rotation and access controls – critical for an organization operating in heavily regulated environments. According to one engineering manager involved in the transition, the shift meant the team could finally answer a question that had previously required days of investigation: what exactly is deployed, and when was it last updated?
Key Lessons for Engineering Leaders
The technical patterns used in the transformation are not novel by themselves – Helm, Argo CD, and Vault are well-known tools. According to Danylo, the impact came from how they were structured and introduced: incrementally, with attention to developer experience and organizational habits.
For other engineering leaders considering a similar shift, Danylo highlights three lessons:
Start with repository design. Folder structure and naming conventions influence long-term maintainability. Getting this right early saves significant refactoring later.
Automate only what teams can understand and support. Adoption matters more than sophistication. A simpler system that engineers actually use is more valuable than an elegant one they avoid.
Leave room for gradual transition. Moving everything at once is rarely sustainable. Incremental adoption allows teams to build confidence and identify issues before they compound.
Looking Ahead
The work positioned the platform team to scale infrastructure without proportional increases in manual effort. As the number of clusters and applications grows, the declarative model becomes more valuable – not only for speed, but also for auditability, onboarding, and long-term consistency.
The focus now, Danylo says, is on extending the same declarative approach to observability – building measurable SLIs and automated alerting that make reliability an objective practice rather than a matter of intuition.
“GitOps didn’t solve every problem – but it made the routine parts of infrastructure less fragile and more predictable. In large engineering organizations, that alone can unlock meaningful efficiency.”
– Danylo Mikula
About Danylo Mikula
Danylo Mikula is a DevOps & Infrastructure Architect with over ten years of experience delivering cloud and platform engineering solutions in regulated industries. His work focuses on translating DevOps principles into measurable, repeatable reliability practices, emphasizing declarative workflows, infrastructure as code, and observability-driven governance. He has contributed research on GitOps adoption patterns and enterprise transformation strategies to international scientific conferences.
