Cloud-native where it fits: six deliberate choices for digital government solutions

For years, during projects and in conversations with customers, we have experienced both the benefits and the limitations of cloud-native thinking. Particularly within a strictly regulated sector such as government, every digital solution requires careful consideration. What data is processed? Where may it be stored? How important are customisation, integrations and predictable performance? And how much control does an organisation want to retain itself?

Information security, data sovereignty and technological independence are not afterthoughts today, but essential conditions. That is why we do not automatically choose for or against cloud-native. For each project and solution, we assess which architecture best aligns with the organisation’s processes, risks and infrastructure.

We have set out six reasons why it is sometimes a deliberate choice not to work cloud-native.

In a non-cloud-native environment, often on-premises, the organisation retains full physical and logical control over its data.

Data residency

For government agencies and organisations working with highly sensitive data, such as data classification 4 within the Flemish Government, it may be necessary for data to be stored in specific physical locations. This avoids sensitive data falling under foreign legislation (such as the US Cloud Act) without clear safeguards.

Bridg’s software solutions can be hosted in a private cloud or another secure environment, such as the VO-MDC for organisations within the Flemish Government.

Isolated infrastructure

Unlike multi-tenant cloud-native solutions, a traditional architecture carries no risk of data and applications belonging to different customers coming into contact with each other or being leaked on the same platform.

Cloud-native architectures are often praised for their flexible pay-per-use model. However, this flexibility can also lead to difficult-to-predict costs, for example during usage spikes or a significant increase in data traffic.

CapEx versus OpEx

For organisations with fixed budgets (such as those in the public sector), a predetermined investment in infrastructure and licences (CapEx) may be easier to manage than variable monthly consumption costs (OpEx).

No unexpected egress fees

There are no charges for moving large amounts of data out of the cloud. For data-intensive applications, this can offer a significant financial advantage.

Cloud-native applications often make use of technologies or services specific to a single cloud provider, such as AWS Lambda, Google BigQuery or certain Azure components. This can make it more difficult and expensive to move to another environment later.

Portability

A traditional architecture, for example based on standard Java/JEE and SQL databases such as DB2 or PostgreSQL, can be moved more easily between different hosting partners or in-house data centres.

Independence

This makes organisations less dependent on the roadmap, price changes (read: increases) or discontinuation of specific services by a single cloud provider. They retain more freedom to adjust their infrastructure strategy later.

In a cloud-native multi-tenant environment, intensive usage by one customer can, in certain situations, affect the capacity available to other customers. This is also known as the noisy-neighbour effect.

Reserved capacity

In a non-cloud-native setup, such as multi-instance, each customer has their own reserved computing power and memory. This makes it possible to better align performance with the expected workload, while keeping speed and availability predictable.

Standardised cloud-native SaaS solutions are often set up according to a single common model. This enables rapid implementation, but does not always provide sufficient scope for organisations with complex or highly specialised processes.

In-depth configuration and customisation

Case management systems and solutions involving complex business processes may require more extensive modifications at application, database or server level. This is not possible in a standardised cloud environment.

Integration with existing systems

Many organisations still work with mainframes, local databases and other applications running on-premise. A solution that can be deployed within the same traditional infrastructure can integrate more easily with these systems and minimise delays in data traffic.

Before the current geopolitical uncertainty, ‘relieving organisations of the burden’ was often the starting point. With cloud-native solutions, specialised knowledge of Kubernetes, Terraform and specific cloud security protocols, among other things, generally lies entirely with the supplier. Organisations do not need to build up that expertise themselves, but in doing so they also hand over part of the technical control.

Control over the technical environment

For IT teams with expertise in traditional server stacks, a familiar architecture can actually be an advantage today. They retain the knowledge, control and responsibility for the technical environment themselves and are less dependent on external suppliers.

In this way, retaining a familiar architecture is not a limitation, but a deliberate choice to keep control in their own hands.