Редакція dev.ua Useful Guidelines 3 October 2025, 10:30

What role does hybrid and multi-cloud strategy play in Ukraine today, and what is the difference between these concepts?

Today, multi-cloud strategy is a global trend. Forbes predicts that both hybrid and multi-cloud models will remain in the spotlight and become the new reality. This is due to the high demand for data analytics, integration of cloud solutions into production, as well as the development of artificial intelligence and machine learning technologies.

OnPrem infrastructure can rarely provide such broad opportunities as the cloud, because there the business receives not only scalability, but also tools for innovation: from low-code platforms to out-of-the-box analytics. But if you work with solutions that do not require constant changes, it is more profitable to leave them on your own capacities.

What does the algorithm look like for a client who came to you for multicloud?

I haven't had a scenario where someone came and said, "I want multicloud." This is always a response to specific challenges. For example, when we were considering migrating certain services, we analyzed which cloud would be more efficient. It's enough to calculate the cost over a few years, and the solution becomes obvious. If there is no multicloud, you are limited to one provider and its rules of the game.

There is another aspect: a client may need to work in a specific region due to technical or regulatory requirements. If the provider does not offer this, they have to either build their own solution in the data center or look for an alternative cloud. The more such alternatives appear, the more incentives there are to choose the best of several options or to take advantage of several.

But to get to this level, you need to have a strategic view. If a company looks at only one provider, it can survive like that, that's not a mistake either.

The only question is whether this provider is ready to give you all the tools, prices, and services that will suit you in the long term. Such situations force you to look for alternatives, and it is companies that are actively looking for better solutions that most often come to a multi-cloud strategy.

What are the biases against multicloud?

The first is “it’s incredibly expensive.” The second is “it’s an excessive burden on the team: a lot of manual work, complex integration, high qualification requirements, and you also need to combine everything with On-Prem.” This is partly true, because at the start there are indeed overhead costs: training, pilots, adaptation, integration work. But over time, when the team enters a stable mode, everything looks much simpler: specializations appear, people quickly “switch” between projects, compare approaches, and expertise grows. This, by the way, keeps engineers interested and helps them stay in the company longer — because they work with different stack technologies, and not monotonously in one.

Another thesis is “it’s hard to integrate.” Partly so: solutions that have to work in different clouds and on-prem require additional design, testing, and validation. But once you’ve worked through all of this and know the tools, it works for you: you get a stable, large-scale infrastructure without the need for an “army” of people to support it.

The biggest trap is when you choose a technology that is impossible to adapt or has a strict vendor lock-in, and are left to “eat cactus”, hoping for updates from the vendor. We try to avoid this: when building a hybrid multi-cloud, we prefer solutions that work well in several clouds and do not force you to make compromises for one platform, but at the same time we give the customer the choice to enter into vendor lock-in, if it makes sense. We also have situations when, for example, the developer of a solution valuable to the customer does not support deployment in another cloud, and you absolutely need it.

What should a business think about when it comes to infrastructure - just CapEx and OpEx, or also speed to market, flexibility, and scalability?

I will say this: in the “long” term, the cloud is usually more expensive. According to our calculations, about one and a half times. At the same time, the cloud is an ideal way to start without large CapEx: do a proof of concept, stabilize the system, test the architecture, go into production. And then, when the platform is stabilized and such a strategy is envisaged, launch it into your own data center and save money there in the long term.

So in all unforeseen scenarios, the cloud is an option. Higher price, but higher flexibility?

For unpredictable loads, the OpEx model of the cloud is ideal: you can take a resource and just as easily abandon it. If the business sees stable consumption, you can take commitments and receive significant discounts: annual approximately 15–25%, three-year — even more. It is important to strategically distribute services across providers: some things work better in one cloud environment, others in another. It is a matter of architecture and vision of the stack and the advantages of providers.

As digital sovereignty issues become increasingly important in Europe, including concerns about American services, how do you balance local providers and hyperscalers?

Sovereignty is a sensitive topic. It is not for nothing that the EU is moving towards a sovereign cloud class and is strengthening regulations to reduce dependence on the US. Are political “shutdowns” of clouds possible? Technically, yes, but for the provider this is reputational suicide, so the probability is low in my opinion. However, the sovereign cloud is on the agenda in the EU. Since we are moving towards integration with the EU, this issue will also concern Ukraine in the near future. In practice, to avoid this risk, we adhere to the rule of performing three backup copies of data: the first is a backup in the “native” location/cloud, the second is a backup in the cross-cloud for restoration to an alternative provider, and the third is a physical copy in our own data center.

This allows you to recover where it is most convenient. Yes, there are vendor lock-in scenarios, and not every business is ready to give them up. But then you need to consciously take risks, provide reliable backups and or a Cloud Vendor ready strategy. We also advise customers: plan near-zero RTO where it is critical, and have a real recovery path even in the event of failures of entire data centers or regions.

How to manage costs in multi-cloud without losing service performance? Where to save and where is it better to invest?

The answer is FinOps, a well-established approach to cloud cost management. The key principles are cost transparency for everyone involved in the cloud costing process in the company (this could be engineers, architects, FINOPS practitioners, finance people, CEOs, buyers, etc.), as well as managing discounts in exchange for forecasted consumption. This works when you understand your workload profile — for example, you need SAP for $1 million/year with planned growth. You reserve part of the workload for 1–3 years, and get significant discounts.

It is also important to configure your consumption wisely: turn off dev/test at night and on weekends, change "unutilized" resources to cheaper classes there if they meet the power requirements.

But the cloud also has a downside, and that is uncontrolled cost growth. An incorrectly configured autoscale without limits can easily “spend” the bill, so limits, alerts, regular cost post-mortems, and the participation of engineers, architects, and managers are needed. In the cloud, it is worth systematically monitoring consumption anomalies so as not to be surprised by the bill at the end of the month, because the cloud is so flexible that it does not forgive mistakes in automatically scaling your services.

When the basic FINOPS disciplines are worked out = operational processes, the next level is architectural optimization: changing services and platforms to more economical ones.

DevOps and automation in hybrid environments - what works best?

It depends a lot on the company's technology stack and whether there is in-house development. If you simply accept code from external teams, the impact is less. If you build your own CI/CD processes and DevOps/SRE practices at the enterprise level, there are many nuances: security, compliance, integrations between clouds and OnPrem.

Our approach is to unify practices and record them in "living" documentation (internal wiki, DevOps Cookbook).

We spent almost a year defining what DevOps means in our context, and we are constantly updating it. This speeds up onboarding, bridges the word-of-mouth gap, and makes the process repeatable. It is critical to involve engineers in shaping and adapting DEVOPS: the principle of “do unto others as you would have them do unto you” is the best here.

Let's move from automation to artificial intelligence in infrastructure. Where has it already provided a tangible increase in capabilities — in a way that was previously difficult to imagine? And where, in your opinion, AI is not needed yet?

To be honest, there is a bit of a bubble around AI. But there are exceptions where it really works.

In a pure OnPrem environment, implementing "artificial intelligence" as a separate system is difficult and expensive. On the other hand, machine learning for specific tasks is quite practical: models for narrow cases give results.

In mass production, this is, for example, visual inspection of defects or detection of safety violations automatically and in real time. In infrastructure, it is more often not about “own AI”, but about built-in ML tools in vendor products, plus cloud provider platforms on which you can deploy specific solutions for your processes. The point is to find exactly the application that will increase productivity here and now: sometimes it can even be the generation of code or automation descriptions. We have piloted this and continue to test the hypothesis of real benefit in development.

The results are mixed so far. There are studies that show an increase in developer and DevOps productivity thanks to AI tools; there are also more restrained conclusions: use is increasing, but the effect is not always linear. That's why we focus on applied value, not hype.

From an operational perspective, AI is useful where humans physically cannot. This includes identifying inefficient resource consumption, early signals of increasing errors, spikes in database delays, and generally providing clues as to where it hurts and what to focus on first. These are things that are difficult to catch with trigger monitoring, but a platform that processes billions of events sees them immediately.

We have tested individual AI solutions with generative AI, and so far we are not very satisfied with the effects. We are waiting for narrower agents (focused on specialized functions) from vendors and in parallel we are selecting those that really increase the productivity of engineers. We are also testing platforms and developing agents to work with our knowledge bases for customer support and automation of routine processes that people take a long time and inefficiently to perform, and the agent finds and solves in a minute.

How to organize the transition and traffic between the cloud and OnPrem without a classic perimeter?

Today, the approach is changing under the pressure of Zero Trust. The classic “open a VPN and go” model is disappearing. Zero Trust dictates a different technological stack for accessing clouds. Vendors are actively promoting SASE/ZTNA solutions that relieve the company of most of the perimeter concerns: firewalls, gateways, routers, proxies. This works well in both cloud-to-cloud and cloud-on-prem scenarios, but it also has nuances that are worth considering: tying yourself to a security information stack from one manufacturer can be a “weak link” in the chain. So there are many pros and cons.

When your own OnPrem is essential, a perimeter is still needed, but we build it in such a way that you can manage the network from a single console: the same access policies for any segment and provider, NGFW with a full set of security tools (IPS/IDS, anti-malware, URL filtering, role-based access). Then, without rights, you won't even be able to access the service at the network level and you won't be able to develop a cyberattack.

In practice, we use solutions from the market leader, Check Point. They provide a homogeneous policy for different clouds and OnPrem, plus they cover compliance audits, posture management, vulnerabilities, and monitoring. With experience, multi-cloud is managed centrally and stably.

Is multicloud greener than OnPrem? Does it help reduce CO₂ emissions?

It depends on the location of the equipment and the country's regulatory requirements. In Ukraine, the requirements for the "greenness" of data centers are not always strict. In the EU, on the contrary: you often have to report on energy consumption and compliance with "green" standards.

In the cloud, the provider usually declares the share of “green” energy itself, so you can consciously choose greener regions — if this is part of the company’s strategy. FinOps practices already have metrics for carbon footprint, so the impact can be measured both in the cloud and onPrem. So multi/hybrid gives you the flexibility to choose more environmentally friendly sites, but “greenness” is not automatic — it’s a matter of specific choices.

What's the worst mistake a C-level can make when moving to the cloud?

When IT strategy is not aligned with business strategy. If multi- or mono-cloud gives the business the necessary value, it is right. If not, it is a mistake, regardless of fashion. The same applies to security: you can have vendor lock-in and gaps in protection, or you can consciously build a multi-vendor landscape. The main thing is business value, compliance with business requirements and compliance.

And finally, a little bit into the future. What skills of engineers will be critically important in the coming years?

It depends on the role and domain, but the trend is this: multicloud is not going anywhere. So engineers will have to work in both the cloud and OnPrem. But in short, the engineer of the future is someone who builds platforms and provides self-service, understands multicloud and business metrics, and not just the hardware or infrastructure of one provider.