The current cloud landscape

US cloud platforms dominate the global market. According to recent estimates, about 85% of European enterprises rely on at least one major US-based cloud service. This isn’t necessarily because there aren’t any qualitative European alternatives, but because they’ve become deeply embedded in the way many organizations work. Their platforms are convenient, widely adopted and tightly integrated with the tools companies already use (Like Microsoft 365 or Google Workspace). Over time, this convenience has made US providers the default choice for many European organizations.

However, this reliance comes with hidden complexity. The US Cloud Act grants US authorities the legal right to access data held by American companies, even if the data is stored abroad. For European organizations, this creates a direct conflict with stringent local privacy regulations such as GDPR. While compliance frameworks exist, the fundamental question remains: who ultimately controls the data, and under which legal jurisdiction?

Beyond the legal dimension, the world has entered an era of heightened political and economic instability. Trade tensions, cybersecurity threats and geopolitical disputes all have implications for cross-border data storage. In this context, companies relying on US-based cloud infrastructure may face risks they did not anticipate when they first migrated their workloads. The convenience and innovation offered by global cloud platforms now come with increasingly visible strategic vulnerabilities.

Sovereign cloud: A response to rising complexity

Sovereign cloud offers a compelling answer to this dilemma. At its core, sovereign cloud refers to cloud infrastructure that is hosted, managed and legally controlled within a specific country or region. It is designed to comply with local data protection laws and provide organizations with assurance that their data is subject to domestic jurisdiction rather than foreign legislation.

The concept revolves around three key principles:

• Data residency: Ensuring that data physically resides within a defined geographic boundary.
• Legal control: Allowing local authorities and organizations to maintain oversight over data access.
• Regulatory compliance: Aligning infrastructure with local laws and industry-specific regulations.

Several forces are driving interest in sovereign cloud. European regulations are tightening, and companies handling sensitive information (like financial institutions, healthcare providers and government agencies) face mounting compliance obligations. At the same time, concerns over geopolitical volatility are influencing strategic IT decisions. A disruption in the relationship between the US and Europe, for example, could expose companies to unexpected legal or operational risks.

As a result, sovereign cloud is gaining traction. Several European initiatives, both public and private, aim to build cloud infrastructure that remains under domestic control. National and regional governments are increasingly investing in sovereign cloud projects, while European companies are exploring partnerships with local providers to reduce dependency on foreign platforms. This trend reflects a shift in priorities: speed and scale remain important, but regulatory certainty and geopolitical resilience are becoming equally crucial.

Implications for businesses and the cloud market

For European companies, the rise of sovereign cloud signals a shift in the calculus of cloud adoption. Cost and convenience are no longer the only factors: legal compliance, geopolitical risk and long-term strategic resilience are becoming equally important. Companies may need to rethink their cloud strategies, assessing whether relying on non-sovereign platforms exposes them to unnecessary regulatory or operational risk.

The trend also affects cloud providers themselves. US-based giants face growing pressure to localize their infrastructure or establish partnerships with European entities to address sovereignty concerns. Meanwhile, European and other regional cloud providers have a significant opportunity to differentiate themselves through offerings that guarantee local control and regulatory compliance.

From a market perspective, the sovereign cloud movement represents both a challenge and an opportunity. For businesses, it’s a chance to align technology with regulatory realities and risk management strategies. For providers, it’s a chance to innovate and expand services in response to shifting customer priorities. Analysts predict that as political and regulatory pressures increase, adoption of sovereign cloud solutions will accelerate, particularly among organizations handling sensitive data or operating in highly regulated industries.

Rethinking cloud dependence

While it is not a cure-all, sovereign cloud is more than a technical trend, it is a reflection of a broader shift in how organizations think about data, governance and risk. In a world of increasing political complexity and regulatory scrutiny, understanding this shift, and its implications for business strategy, is essential for companies that want to navigate the cloud with both confidence and foresight.

The post Who really owns your data? Navigating cloud compliance in a global ecosystem appeared first on Verhaert Masters in Innovation.

The post Who really owns your data? Navigating cloud compliance in a global ecosystem appeared first on Verhaert Masters in Innovation.

Connected products open the door to powerful new digital features, services and business models, yet many companies shy away from making their products connected. Adding this extra layer of technical complexity also requires new skills, raises security concerns and brings up privacy issues. At the core of these digital transformation challenges lies one key enabler: the right infrastructure. Connected products require a real-time, reliable and maintainable architecture that bridges digital ecosystems and physical devices, without losing control over scalability, security or flexibility.

During the ‘Building the digital backbone of smart, connected devices’ webinar on May 20th, Dennis Daems, Chief Technology Officer, and Joachim Jansen, Senior Software Engineer & Project Manager, shared their real-world experience with connected digital innovation. Access the recording and summary below to learn how to approach this complexity with confidence and turn it into a competitive edge.

Watch the recording

Read the summary

The post Building the digital backbone of smart, connected devices appeared first on Verhaert Masters in Innovation.

The post Building the digital backbone of smart, connected devices appeared first on Verhaert Masters in Innovation.

Today, nearly every product – digital or physical – connects to the cloud. But without a strong foundation, businesses can’t scale, stay secure or innovate reliably. This is where infrastructure as code (IaC) comes in. By managing infrastructure through code, teams ensure consistency, speed and resilience. Though invisible to end users, IaC is critical to delivering seamless digital experiences.

What is ‘infrastructure as code’?

Infrastructure as code (IaC) is the practice of configuring and deploying infrastructure, like servers, networks and databases, using code instead of manual setup. Think of setting up your infrastructure like building IKEA furniture. Even with a manual, it’s easy to make mistakes or forget how something was put together. Now imagine that you have a magic instruction book that automatically builds furniture exactly the same way every time you open the box. That’s what infrastructure as code does for your infrastructure. You write instructions once like a recipe, and the system builds everything the same way, every time. It saves time, avoids mistakes and makes sure everything’s built the same way.

End users may never see your infrastructure, but they experience the outcomes it supports when it’s done right:

• Sites that stay fast under pressure
• Services that recover instantly after downtime
• Products that scale smoothly without surprise errors

These outcomes aren’t the result of Infrastructure as Code alone, but IaC helps make them possible by ensuring that the underlying systems are consistent, reproducible, and easy to evolve.

Why it’s worth the investment

Managing infrastructure as code brings clear, repeatable advantages over manual configuration:

• Speed: Provision environments in minutes, accelerating development cycles.
• Reliability: Standardized configurations reduce human errors and environment-specific bugs.
• Scalability: Systems adapt to changing demand automatically.
• Traceability: Every change is versioned, auditable, and reviewed.
• Cost efficiency: Resources can be spun up or down based on need.

From bottleneck to accelerator

Before IaC, infrastructure was often a bottleneck: time-consuming, error-prone and hard to reproduce. With IaC, it becomes a scalable asset:

• Teams collaborate better with shared visibility into what’s deployed
• Development, staging and production environments can be created consistently
• Code reviews and version control improve quality and reduce risk

Even better, infrastructure setups become reusable and composable. Teams can build faster by borrowing proven patterns, while still customizing where needed. And because infrastructure is now written in code, all the benefits of software engineering apply: modular design, documentation, peer review, and continuous improvement.

When not everything needs IaC

Not every project requires a full-scale Infrastructure as Code setup from day one, and that’s okay. The key is aligning early on what the project is today and what it might become tomorrow.

For example, a more lightweight or manual approach may make sense when:

• You’re building a proof of concept (PoC) that will be discarded in a few weeks
• It’s a temporary internal demo, not intended for reuse
• The infrastructure is very minimal, and the team is using it for learning or visual exploration

But here’s the nuance: we’ve seen plenty of PoCs turn into pilots, and pilots into products. That’s why we always clarify with our clients early on: “Is this truly short-lived? Or could it evolve?”

If there’s any chance the environment will be reused, shared, or audited, then even a basic, right-sized IaC setup is worth it because it avoids hidden technical debt down the road.

Our rule of thumb?

If the setup is truly short-lived, internal-only, and unlikely to scale, be pragmatic. But if there’s any future ahead of it, even uncertain, we lean on infrastructure you can trust and repeat.

The future of infrastructure as code

Infrastructure used to be a ‘mystery box’ managed by a few experts. Today, it’s transparent, collaborative and accessible to all, forming the backbone of how we deliver better digital solutions together. Looking ahead, infrastructure as code will become even more standard practice, with customers increasingly requesting it as part of their digital transformation.

Looking ahead, IaC will become even more accessible and intelligent:

• Multi-cloud & hybrid-cloud setups will be easier to manage
• AI-assisted infrastructure generation will allow teams to describe what they want and let tools write the code
• Policy-as-code will make compliance and security checks automatic
• IaC will become a core part of internal developer platforms, enabling self-service for product teams

The future of innovation is digital and digital depends on infrastructure.

The post Invisible until it breaks: The hidden power of infrastructure as code appeared first on Verhaert Masters in Innovation.

The post Invisible until it breaks: The hidden power of infrastructure as code appeared first on Verhaert Masters in Innovation.

The power of infrastructure-as-code

Infrastructure-as-code has quickly transformed how organizations manage their infrastructure. Why is that? First and foremost, IaC drastically lowers the amount of manual labor necessary to set up, scale and maintain your infrastructure, reducing costs, increasing SLA and reducing human errors. In addition, it greatly improves scalability and consistency because you’re using the same code every time. IaC scripts are stored in version control systems which allows for tracking changes, collaboration and rollbacks if needed.

We’ve seen firsthand how the right choice of IaC tools can streamline operations, accelerate time-to-market, and reduce overhead. But we’ve also seen the repercussions when the wrong tools are selected—delays, increased costs, and frustrated teams. The choice between tools like Microsoft Bicep and Terraform isn’t just a technical decision; it’s a strategic one that impacts your effectiveness and future-proofness. Each has its strengths and challenges, how do you know which one is right for your project?

Bicep vs. Terraform: diving into the key differences

When it comes to managing cloud infrastructure, organizations have a variety of tools at their disposal, each with its own strengths and challenges. Two of the most prominent IaC tools are Microsoft Bicep and Terraform, let’s explore the key benefits and challenges of both tools, helping you determine which one might be the best fit for your needs.

Microsoft Bicep

Bicep is a domain-specific language developed by Microsoft as a simplified alternative to Azure Resource Manager (ARM) templates. It is designed specifically for deploying and managing infrastructure on Microsoft Azure, offering a more user-friendly and readable syntax than its predecessor, ARM templates.

Key benefits

• Strong integration with Azure: Bicep is designed specifically for Azure, providing seamless integration with its services and native support for resource types. This makes it a powerful choice for managing Azure infrastructure.
• Simplified syntax: Bicep offers a cleaner and more concise syntax than ARM templates, making it easier to read, write and maintain. This is especially beneficial for teams who may find ARM templates verbose or difficult to work with.
• Built-in linting and validation features: Bicep comes with built-in linting and validation capabilities, which help catch errors and ensure best practices are followed during development. This can save time and effort by preventing deployment issues due to syntax errors or misconfigurations.

Main challenges

• Over-engineering modules: Creating overly complex, generic modules can lead to difficulties in maintenance and adaptation. It’s essential to strike a balance between reusability and maintainability.
• Limited module sharing outside of repositories: Bicep modules are primarily shared within repositories, limiting their accessibility across teams and organizations. Azure Bicep Registry (currently in preview) aims to address this by providing a central repository for sharing and discovering modules.
• Requires Azure-specific knowledge: Bicep is deeply integrated with Azure services and resource types, requiring familiarity with Azure concepts and terminology. If your team is new to Azure, there might be a learning curve involved.

Terraform

Terraform is an open-source IaC tool developed by HashiCorp. It offers a consistent way to manage infrastructure across different platforms. This flexibility makes it a go-to tool for organizations looking to maintain a consistent infrastructure management approach across various environments.

Key benefits

• Large community and provider ecosystem: Terraform boasts a vast community of users and contributors, which translates into a wealth of knowledge, tutorials and support. Additionally, the extensive ecosystem of providers allows you to manage resources across various cloud platforms and services (beyond Google Cloud, AWS and Azure).
• Flexibility to manage multi-cloud environments: Terraform’s provider model allows you to manage resources across multiple cloud providers (ex. Google Cloud, AWS and Azure) within the same configuration. This is a significant advantage for organizations with a multi-cloud strategy or hybrid infrastructure.
• Strong support for state management: Terraform excels at state management, providing a mechanism to track the current state of your infrastructure and plan changes accordingly. This is crucial for ensuring consistency and avoiding accidental modifications or deletions.

Main challenges

• Tight coupling between modules: Highly interdependent modules can create a cascading effect of changes, making updates and troubleshooting complex. It’s crucial to design modules with well-defined interfaces and minimal dependencies.
• Challenges managing module versions and compatibility: Terraform modules evolve over time, and managing different versions across projects can be challenging. It’s crucial to implement a versioning strategy (ex. using semantic versioning) and clearly communicate compatibility requirements.
• Risk of infrastructure drift if not properly managed: Infrastructure drift occurs when the actual state of your infrastructure diverges from the desired state defined in your configuration files. This can happen if changes are made directly to the infrastructure outside of Terraform’s control. Terraform’s declarative nature can lead to configuration drift if external changes are made to the infrastructure. To prevent this, it’s essential to use Terraform’s state management to track changes and ensure consistency between your code and the actual infrastructure

And what about cloud development kits

Recently, though, more and more companies are trading in declarative configuration languages (like Bicep and Terraform) for cloud development kits (like AWS CDK and CDKTF). This reflects an overall need for greater flexibility, expressiveness and integration with modern software development practices. And here’s why:

• Programming language flexibility: Although declarative languages are good for straightforward infrastructure, they’re typically limited to a specific domain and lack the expressive power of general-purpose programming languages that complex scenarios require. Using CDKs makes the code more reusable, modular and easier to maintain.
• Improved developer experience: With CDKs, developers can use familiar development practices like testing, version control, and debugging enhances productivity and reduces the learning curve.
• Enhanced abstractions and reusability: Typically declarative languages require repetitive configuration code, even for common patterns. While some tools support modules or templates to promote reuse, they often lack the flexibility and power provided by CDKs.
• Dynamic configuration capabilities: CDKs provide dynamic capabilities, allowing the creation of infrastructure that can adapt based on conditions or inputs. This dynamic nature is useful for scenarios where infrastructure needs to vary based on environment, scale or other factors.
• Better integration with application code: Declarative languages typically separate infrastructure configuration from application code, which can lead to challenges in maintaining consistency and integration between the two. CDKs facilitate seamless integration between infrastructure and application code since you use the same programming language and tools.

Weighing the pros and cons of leading IaC tools

For enterprises deeply embedded in the Microsoft ecosystem, Bicep offers seamless Azure integration and a streamlined approach that can enhance efficiency and reduce overhead. Meanwhile, Terraform’s multi-cloud flexibility and powerful state management position it as a strong choice for organizations managing diverse infrastructure across multiple platforms. CDKs, with their unparalleled flexibility and integration capabilities, may be attractive for innovation-focused teams but require careful consideration of the complexities they introduce, particularly in terms of maintainability, onboarding and predictability.

Selecting the right IaC tool is critical to achieving your strategic objectives and maintaining a competitive edge. Whether you’re considering Microsoft Bicep, Terraform, or CDKs, the decision isn’t just about the technical features but about aligning the tool with your organization’s broader goals and operational frameworks. Not sure where to start? Let’s explore how we can tailor the best IaC solution to drive your organization forward.

The post Decoding the infrastructure-as-code maze appeared first on Verhaert Masters in Innovation.

The post Decoding the infrastructure-as-code maze appeared first on Verhaert Masters in Innovation.