Executive Summary: The Future of Integration

• The ESB is an Agility Bottleneck: In a hybrid world, the ESB’s centralized nature creates latency, hinders elastic scaling, and has a large blast radius, making it a bottleneck for continuous delivery and resilience.
• Modern Architecture is Decoupled: Today’s leaders are building a new core using three key components: API Gateways for north-south traffic control, Service Meshes (like Istio) for east-west security, and Event-Driven Backbones (like Kafka) for decoupling and real time reactions.
• Security Must be “Zero-Trust”: In a hybrid environment, trust can no longer be assumed. The reference architecture is built on a zero-trust model, enforcing strong identity and mutual TLS (mTLS) encryption between every service, not just at the perimeter.
• Compliance is an Architectural Outcome: Instead of being an afterthought, compliance with NIS2, GDPR, and ISO 27001 is designed into the system. Standardized, privacy-aware telemetry pipelines provide the verifiable evidence trail that regulators demand.
• Migration is a Gradual Journey: A “big bang” replacement is too risky. The recommended approach is the Strangler-Fig pattern: incrementally routing traffic to new microservices while safely phasing out legacy ESB flows, ensuring business continuity. This staged approach minimizes risk and enables compliance validation at every migration step.
  

Who should care?

ESB’s limitations under hybrid cloud

• Central choke-point leads to latency & agility friction. Every new SaaS or region adds hops and transforms in the bus.
• Single control plane creates broad blast radius. Misconfiguration or overload affects many domains.
• Vertical scaling & proprietary stacks. License-bound or appliance-bound ESBs hinder elastic scaling, blue-green deployments, and multicloud portability. Comparative studies since 2020 consistently flag these as recurring inhibitors.
  

Hybrid-cloud pressures

• SaaS, on-prem and public cloud create new trust boundaries and data residency obligations (GDPR). Cross-border telemetry/logging must honor data minimization.
• Vendor lock-in often undermines digital sovereignty. A single-vendor ESB can become the de facto cloud strategy. Modern platforms adopt open standards (Kubernetes, OTel, Prometheus, Envoy/Istio)
  .

Licensing pressure as a control mechanism

Architecture / Solution Patterns

Event-driven vs request/response

When to prefer EDA (Kafka):

• High fan-out, real time reactions (fraud alerts, logistics updates, IoT).
• Cross-domain decoupling where producers shouldn’t know consumers.
• Durable event logs enable replay and repair. European banks and logistics providers illustrate these advantages through Kafka-backed alerting and notification systems.

When to prefer request/response:

• Synchronous user flows with tight SLAs (checkout, identity verification).
• Fine-grained read paths that depend on low latency and immediate consistency, typically behind an edge API gateway.

API gateways vs service meshes

Orchestration vs choreography

• Orchestration (centrally managed flows) is easier to reason about but risks a new mini-ESB.
• Choreography (services react to events) scales organizationally but raises observability and real time dependency challenges. A hybrid model, where orchestration initiates and events carry state, often works best for regulated workflows.

Platform building blocks (reference choices)

• Kubernetes (AKS/EKS/GKE/OpenShift) as the uniform runtime.
• Kafka for event backbones across sites/regions.
• Istio/Cloud Service Mesh for identity, mTLS, and traffic policy.
• API Gateways (3scale, Kong, Envoy-Gateway, Kgateway) at the edge; emerging Gateway API standard  improves cross-platform portability.
• OpenTelemetry, Prometheus, Elastic, Fluent Bit for standardized traces/metrics/logs with PII-safe pipelines.

Trust boundaries across on-prem (private cloud) and public cloud

Failure modes & recovery

Security & Privacy Implications

Identity propagation

• Edge: OAuth 2.0/OIDC (RFC 6749) issues short-lived tokens. API gateways validate and enforce scopes. JWT (RFC 7519) carries claims; prefer asymmetric signing for stronger verification. For high-sensitivity clients, use OAuth mTLS (RFC 8705) to bind tokens to client certificates.
• Inside the mesh: Adopt mTLS by default with workload identities (for example, using SPIFFE/SPIRE). Avoid bearer tokens in plain-text service calls.

Secure connectors in hybrid environments

Use private connectivity such as IPSec, ExpressRoute, or VPNs together with service-level mTLS. Terminate only where necessary and immediately re-encrypt. Keep policy-as-code (OPA/Rego or mesh AuthorizationPolicy) versioned alongside the applications. Google Cloud’s Service Mesh documentation illustrates this security posture.

Preventing data leakage in integration & logging

GDPR requires data minimization and privacy by design. Do not include entire payloads in logs or traces. Hash or remove identifiers where possible, and use OpenTelemetry processors for PII scrubbing.

Compliance mapping (NIS2 / ISO 27001 / SOC2)

It is important to design telemetry first. Decide which identifiers are essential to detect fraud or incidents, then instrument only those. Drop or hash everything else at the collector before storage. EDPB guidance emphasizes data minimization and Data Protection by Design and Default (DPbDD). Maintain a single evidence catalog linking controls to trace IDs and policy versions; this directly supports NIS2 incident-response documentation.

Effective security and privacy controls rely on early design decisions. When identity propagation, encrypted connectivity, and telemetry minimization are embedded from the start, compliance becomes a natural property of the architecture rather than a checklist item.

Reference Architecture

The reference architecture translates strategy into concrete, verifiable building blocks for a Dutch and EU enterprise context: hybrid by default and regulated by design. It shows how edge facing APIs (OAuth2/OIDC), an internal service mesh (mTLS, workload identity, policy-as-code), and an event backbone (Kafka) come together to securely replace ESB centrality with decoupled, resilient flows. he unifying principle is zero-trust: strong identities at the perimeter and between services, explicit trust boundaries, and least-privilege access everywhere. Because evidence matters under NIS2, GDPR, and ISO 27001, telemetry is modeled as a first-class capability rather than an afterthought.

Each C4 view narrows the lens: the System view establishes the north-south and east-west control planes and identifies where residual ESB flows remain, the Container views make connectivity, policies, and hybrid links explicit, and the Component view demonstrates an event driven core with schema governance and isolated failure domains. OpenTelemetry operates across all layers to enforce data minimization and export controls before any metric, log, or trace leaves the platform. This supports compliance audits without risking personal data exposure.. Read the diagrams left to right as user-to-service journeys and top to bottom as identity and policy enforcement paths. The boundary callouts show exactly where to prove controls, recover from failure, and scale safely.

Context (C4: System) — “Secure Hybrid Integration”

This system-level view illustrates the end-to-end architecture pattern underpinning secure hybrid integrations.

External consumers (browsers, partner SaaS, and mobile clients) access the environment through an API Gateway enforcing OAuth 2.0/OIDC, rate limits, and threat protection.

Within the private cloud, a service mesh (e.g. Istio) provides east-west mTLS, authorization, and telemetry, connecting containerized microservices, the Kafka event backbone, and any remaining ESB flows.

Across the hybrid boundary, workloads in public cloud regions expose managed APIs, FaaS components, or cloud native meshes, all instrumented through OpenTelemetry Collectors. Telemetry is exported to diverse observability stacks, ranging from open source (Prometheus, Grafana, Loki, Tempo, OpenSearch) to commercial suites (Datadog, Dynatrace, Elastic Cloud, New Relic, Splunk), supporting compliance with NIS2 Article 21, ISO 27001 Annex A.12, and GDPR Article 25 (Data Protection by Design and Default).

Context (C4: Container) – “Secure Hybrid Integration”

This container-level representation details the runtime topology within the hybrid integration platform. The Edge Gateway enforces OAuth 2.0/OIDC authentication, rate limiting, and Layer 7 protection (JWT verification, DDoS mitigation, WAF), forming the perimeter of the zero-trust boundary. Inside the private cloud domain, the Mesh Ingress terminates mTLS and applies service-level authorization policies before routing traffic to microservices (Service A, B, C). East-west communication is protected through mTLS identities and event driven coupling between services, ensuring low latency and bounded trust zones.

Service C exposes controlled interfaces to external SaaS connectors via encrypted private links (VPN, ExpressRoute, or private endpoints) within the hybrid connectivity boundary. Each component, including the gateway, mesh, services, and SaaS connectors, emits standardized telemetry through OpenTelemetry Collectors, which apply PII scrubbing, tokenization, and encryption before exporting data to observability stacks such as Prometheus, Grafana, Loki, Tempo, Elastic, OpenSearch, Datadog, Dynatrace, and Splunk.

The explicit demarcation of the Zero-Trust, Hybrid Connectivity, and Telemetry Egress boundaries illustrates how identity, encryption, and data-minimization principles jointly satisfy evidence and control requirements defined by NIS2 Article 21, ISO 27001 Annex A.12, and GDPR Article 25 (Data Protection by Design and Default).

Context (C4: Container) – “Telemetry integration”

This container-level representation details the runtime topology within the hybrid integration platform. The Edge Gateway enforces OAuth 2.0/OIDC authentication, rate limiting, and Layer 7 protection (JWT verification, DDoS mitigation, WAF), forming the perimeter of the zero-trust boundary. Inside the private cloud domain, the Mesh Ingress terminates mTLS and applies service-level authorization policies before routing traffic to microservices (Service A, B, C). East-west communication is protected through mTLS identities and event driven coupling between services, ensuring low latency and bounded trust zones.

Service C exposes controlled interfaces to external SaaS connectors via encrypted private links (VPN, ExpressRoute, or private endpoints) within the hybrid connectivity boundary. Each component, including the gateway, mesh, services, and SaaS connectors, emits standardized telemetry through OpenTelemetry Collectors, which apply PII scrubbing, tokenization, and encryption before exporting data to observability stacks such as Prometheus, Grafana, Loki, Tempo, Elastic, OpenSearch, Datadog, Dynatrace, and Splunk.

The explicit demarcation of the Zero-Trust, Hybrid Connectivity, and Telemetry Egress boundaries illustrates how identity, encryption, and data-minimization principles jointly satisfy evidence and control requirements defined by NIS2 Article 21, ISO 27001 Annex A.12, and GDPR Article 25 (Data Protection by Design and Default).

Context (C4: Component) – “Event-driven core”

This component-level view depicts the internal event-driven design underpinning the hybrid-integration platform.

The OrderAPI publishes canonical domain events (order.created) validated by a Schema Registry, which enforces schema integrity, version control, and backward compatibility guarantees before events enter the Kafka backbone. Downstream microservices (RiskSvc, BillingSvc, and Notifier) each subscribe through isolated consumer groups (risk-g1, billing-g1, notify-g1) to ensure parallel processing, resilience, and controlled failure domains. The Schema Registry acts as a contractual governance layer, supporting policy-as-code practices and auditability. This is key for regulated industries where data lineage and message integrity form part of ISO 27001 Annex A.12 evidence.

All components emit standardized telemetry via OpenTelemetry Collectors, applying data minimization, tokenization, and encryption prior to egress toward the observability stacks (Prometheus/Grafana/Loki/Tempo, Elastic/OpenSearch, Datadog, Dynatrace, Splunk). The Telemetry Egress Boundary enforces privacy by design and controlled data export, satisfying accountability and monitoring requirements under NIS2 Article 21 and GDPR Article 25 (Data Protection by Design and Default).

Together, this view illustrates how event driven choreography, when coupled with schema governance, isolated consumer domains, and instrumented telemetry, provides a resilient and compliant foundation for hybrid cloud microservice ecosystems.

Takeaway

The reference architecture demonstrates that secure hybrid integration is not achieved through tools alone, but through deliberate layering of identity, policy, and observability. By combining API gateways, service meshes, and event driven backbones under a zero-trust model, enterprises can modernize beyond the ESB without losing auditability or control. Each trust boundary doubles as a compliance checkpoint, proving encryption, authorization, and data minimization by design, while the standardized telemetry pipeline provides the evidence trail demanded by NIS2, ISO 27001, and GDPR. In short, resilience and compliance become outcomes of the architecture itself, not separate projects.

Migration Strategy

Migrating from an ESB-centric architecture to a distributed, event driven microservices model is as much an organizational transformation as it is a technical one. The migration strategy must balance modernization goals(agility, resilience, and scalability) with the realities of operational continuity, compliance, and legacy dependencies. A big bang replacement is rarely feasible in regulated environments. Instead, gradual coexistence allows critical systems to evolve safely within defined trust boundaries. This section outlines a Strangler Fig approach tailored for European enterprises: incrementally encapsulating legacy flows behind gateways, introducing service meshes and event backbones domain by domain, and using observability and policy as code to ensure that every new component strengthens the overall security and compliance posture. The goal is not just to replace an ESB, but to build a verifiable, auditable hybrid architecture that continuously aligns with NIS2, ISO 27001, and GDPR obligations while accelerating delivery.

Strangler-Fig modernization

Create new product surfaces through a proxy facade that routes some calls to the legacy ESB and others to new services, with progressive replacement of the old flows. This pattern is documented in Martin Fowler’s catalog and in prescriptive guidance from major cloud providers such as Azure and AWS.

Co-existance playbook (12-24 months)

1. Declare critical domains (e.g., orders, identity, payments).
2. Event-first for new flows; keep ESB for slow moving legacy.
3. Introduce gateway/mesh with an mTLS default; create SLOs and error budgets with Prometheus.
4. Standardize telemetry via OTel collectors with PII scrubbing.
5. Decommission by slice (service by service) using strangler routes and canary releases.

This structured coexistence phase allows architecture and governance teams to validate each modernization step against operational metrics and compliance evidence before retiring legacy components.

KPIs to measure success

• Lead time for change per service, deployment frequency.
• P99 latency across edge and service hops, error rate, and SLO burn-down trends.
• Mean time to detect and respond (NIS2 reporting readiness).
• Compliance evidence freshness (policy versions, trace IDs in incident records).

Tracking these indicators over time provides tangible proof of modernization impact—linking agility and resilience gains directly to compliance readiness.

How this applies to the Dutch landscape

Modernization is never one size fits all. Each sector faces its own blend of regulatory obligations, operational pace, and resilience requirements that shape how an ESB to microservices transition can succeed. Financial institutions prioritize transaction integrity and auditability, logistics and transport must orchestrate data flows in near real time across physical networks, energy operators balance grid stability with cybersecurity and traceability, and IT service providers seek automation without losing control or evidence. This chapter highlights how hybrid, zero trust, and event driven design principles manifest differently across these domains, showing that sector specific constraints, not vendor tooling, ultimately determine the architecture’s trust boundaries and compliance posture.

Financial Services (NL)

Banks such as Rabobank and ING have transitioned from centralized ESB workflows to Kafka based event backbones, improving resilience, real time monitoring, and auditability. Regulatory drivers like DORA, PSD2, and GDPR accelerated this move toward decoupled services, schema governance, and streaming based fraud detection.

Event driven architectures now support continuous compliance and faster recovery, with OpenTelemetry pipelines ensuring traceability from transaction to incident report.

Compliance Focus: DORA, GDPR, SOC 2, Basel IV

Aviation & Logistics

Dutch logistics and aviation hubs like Schiphol, Port of Rotterdam, and PostNL, orchestrate thousands of concurrent integrations across customs, transport, warehousing, and IoT telemetry. ESB models proved too rigid for such dynamic, multi stakeholder ecosystems.

Event driven integration now underpins real time situational awareness: IoT sensors publish events via MQTT or Kafka, APIs expose live shipment and asset states through secure API gateways, and service meshes maintain mTLS secured channels between operational zones.

The result is end to end visibility and compliance with customs and transport regulations, while enabling predictive logistics and carbon tracking under EU sustainability directives.

Compliance Focus: NIS2, customs, CO₂ tracking

Transport & Mobility

Transport networks like Nederlandse Spoorwegen (NS) face hybrid challenges: integrating real time operational data from trains, stations, and control systems with passenger facing digital services and third party APIs.

Traditional ESB architectures introduced latency and limited scalability as data volumes grew across sensors, ticketing, and planning systems.

Microservices combined with Kafka, Azure Event Grid, and service meshes now allow NS to unify event streams for real time passenger updates, maintenance telemetry, and predictive scheduling.

Zero-trust principles ensure isolation between operational technology (OT) and IT systems, while OpenTelemetry based observability provides forensic evidence for incident management, NIS2 compliance, and SLA validation across multiple suppliers and data domains.

Compliance Focus: NIS2, GDPR, SLA proof

Energy & Utilities

Energy operators (for example TenneT, Enexis, Alliander) face twin priorities: grid resilience and regulatory accountability. NIS2 extends cybersecurity duties deep into their supply chains, forcing stronger separation between OT and IT layers.

Modernization efforts center around hybrid microservice platforms that securely integrate SCADA telemetry, market APIs, and predictive analytics. Kafka and Azure Event Hubs provide real time data streams, while service meshes enforce isolation and authenticated communication between critical workloads.

Data exposure via ENTSO-E CIM APIs supports transparency without compromising security, and observability stacks log every transaction for ISO 27019 and NIS2 Article 21 evidence.

The architectural goal is provable segmentation, so every connection can be authenticated, monitored, and explained.

Compliance Focus: NIS2, ISO 27019

IT Operations & Managed Services

Within SOC/NOC and managed service environments, the ESB to microservices transition is driven by the need for automation, elasticity, and evidential logging.

Modern IT operations rely on event driven orchestration using Kafka, NATS, or Azure Event Grid, with workflows tied into SOAR and CMDB systems for automated response.

Service meshes secure internal automation APIs across multi tenant clusters, while OpenTelemetry and Prometheus ensure each remediation step is observable and attributable, key for audits under ISO 20000, SOC 2, and NIS2.

Where ESBs once serialized automation, microservice integration now enables autonomous, policy controlled remediation that remains compliant by design.

Compliance Focus: NIS2, ISO 20000, SOC 2

Sector Takeaways

Across all sectors, the migration from ESB to microservices aligns modernization with compliance. The common thread is measurable trust: every event, policy, and trace supports both operational goals and regulatory evidence.

Practical Guardrails

Practical guardrails translate architectural principles into operational discipline, the daily controls that keep hybrid environments secure, observable, and compliant as they evolve. While reference models define what ‘good’ looks like, guardrails define what ‘safe’ looks like in production. They include enforced mTLS between workloads, privacy aware telemetry pipelines, policy as code for consistent authorization, and governance practices that prevent silent drift. These measures ensure that every deployment, integration, and change adheres to zero trust, data minimization, and evidentiary requirements under NIS2, ISO 27001, and GDPR, without slowing down engineering velocity. In essence, they make compliance a continuous runtime property, not a periodic audit exercise.

Security

Enforce mTLS for all traffic, use short-lived JWTs at the edge, apply OAuth mTLS for high-risk clients, and maintain clear separation between north-south and east-west policy planes.

Privacy

Treat logs and traces as potential personal data risks by default, enforce scrubbing at the collector, avoid payload logging, and document purposes as required by GDPR Article 25. This establishes privacy by design across observability pipelines.

Ops/Cost

Control cardinality in Prometheus labels and tags, sample traces to manage storage cost, use Fluent Bit at the edge for efficiency, and graduate to Fluentd where complex routing is needed. These practices maintain observability quality while containing operational cost.

Governance

Productize APIs through catalogs and SLAs, and manage events through schemas and versioning. Establish deprecation and schema evolution playbooks to avoid integration drift. Recent studies on API evolution underscore the importance of maintaining forward compatibility.

Together, these guardrails operationalize the architectural intent of zero trust and privacy by design. They ensure that every release, deployment, and runtime behavior can be traced, justified, and audited — turning compliance from a static requirement into a living, verifiable property of the platform.

Conclusion

The European and Dutch reality is hybrid, both technically and regulatorily. The ESB’s centrality once helped, but now it constrains scale, resilience, and autonomy. A microservices and event driven architecture, secured by a gateway at the edge and a mesh inside, provides both the agility the business demands and the evidence trail required by NIS2 and GDPR. Begin with a Strangler Fig migration, demonstrate measurable value in a single domain, and expand iteratively with privacy by design telemetry from the start.

In the hybrid era, modernization is not just about replacing technology but about embedding verifiable trust, resilience, and compliance into the architecture itself.

Translate Architecture into Action

This guide provides a blueprint for a resilient, secure, and compliant integration platform. Yet every organisation’s journey from its legacy ESB is unique.

If your organisation is ready to move from design to implementation, this blueprint can guide the development of a practical migration strategy aligned with your regulatory and operational context.

Schedule a 30-minute hybrid integration strategy session

To discuss how these principles can apply within your architecture, schedule a short strategy session with our experts.

The shift beyond the ESB is not a technical rewrite but an architectural evolution. By combining open standards, zero trust design, and privacy aware observability, enterprises can modernize integration at their own pace, gaining agility and control while meeting Europe’s strictest regulatory standards.

References & Further Reading

• Campaign for Clear Licensing. (2021). Oracle’s Licensing and Audit Practices in Europe: Findings and Recommendations. London: CCL.
  https://www.clearlicensing.org/reports/oracle-audit-practices-europe/
• Forrester Research. (2023). The Future of Integration: From Centralized ESB to Cloud-Native Platforms. Cambridge, MA: Forrester Research.
• Gartner. (2024). Market Guide for Integration Platform Technologies. Stamford, CT: Gartner Inc.
• House of Commons (Digital Economy Committee). (2022). Enterprise Software Licensing Inquiry: Audit and Compliance Practices of Major Vendors. London: UK Parliament Publications.
• Cloud Native Computing Foundation (CNCF). (2023). CNCF Service Mesh Landscape Report. San Francisco, CA: CNCF.
  https://www.cncf.io/reports/service-mesh-landscape-report/
• European Union Agency for Cybersecurity (ENISA). (2024). Implementing NIS2: Technical Measures and Reporting Requirements. Brussels: ENISA Publications.
  https://www.enisa.europa.eu/publications/nis2-technical-measures-and-reporting
• European Data Protection Board (EDPB). (2023). Guidelines on Data Protection by Design and by Default (Art. 25 GDPR). Brussels: EDPB.
  https://edpb.europa.eu/system/files/2023-06/edpb_guidelines_2023_dataprotectionbydesign_en.pdf
• Fowler, M. (2021). Patterns for Incremental Modernization: The Strangler Fig Approach.
  https://martinfowler.com/bliki/StranglerFigApplication.html
• OpenTelemetry Project. (2024). Data Privacy and Minimization in Observability Pipelines. San Francisco, CA: Cloud Native Computing Foundation.
• https://opentelemetry.io/docs/concepts/privacy/
• Red Hat. (2024). Istio Service Mesh Security Best Practices. Raleigh, NC: Red Hat Inc.
  https://www.redhat.com/en/resources/istio-service-mesh-security-best-practices-overview
  

Recent 2025 Publications and Articles

• Cloud Native Computing Foundation. (2025, October 9). Testing Asynchronous Workflows Using OpenTelemetry and Istio. CNCF Blog.
  https://www.cncf.io/blog/2025/10/09/testing-asynchronous-workflows-using-opentelemetry-and-istio/
• Cloud Native Computing Foundation. (2025, August 25). How Should Prometheus Handle OpenTelemetry Resource Attributes – A UX Research Report. CNCF Blog.
  https://www.cncf.io/blog/2025/08/25/how-should-prometheus-handle-opentelemetry-resource-attributes-a-ux-research-report/
• Cloud Native Computing Foundation. (2025, March 3). Announcing the Beta Release of OpenTelemetry Go Auto-Instrumentation Using eBPF. CNCF Blog.
  https://www.cncf.io/blog/2025/03/03/announcing-the-beta-release-of-opentelemetry-go-auto-instrumentation-using-ebpf/
• Piwosz, P. (2025, April 14). Monolith vs Microservices 2025: Real Cloud Migration Costs and Hidden Challenges. Medium Technology Journal.
  https://medium.com/@pawel.piwosz/monolith-vs-microservices-2025-real-cloud-migration-costs-and-hidden-challenges-8b453a3c71ec
• Gupta, S., & Verma, R. (2025). Microservices Architecture for Scalable Enterprise Applications. ResearchGate Preprint.
  https://www.researchgate.net/publication/389817361_Microservices_Architecture_for_Scalable_Enterprise_Applications
  

Sector Case Studies (Transport, Logistics, Energy, IT Ops)

• Ximedes. (2024). GVB Fleet Management: Microservices Case Study. Amsterdam: Ximedes BV.
  https://ximedes.com/case_study/gvb-fleet-managment
• Nederlandse Spoorwegen (NS). (2023). NS zet volledig in op datagedreven werken. Computable.nl.
  https://www.computable.nl/artikel/nieuws/datamanagement/7398688/250449/ns-zet-volledig-in-op-datagedreven-werken.html
• Port of Rotterdam Authority. (2024). Digital Twin Port Operations and Data Platform. Rotterdam: PoR Authority.
  https://www.portofrotterdam.com/en/port-future/digital-twin-port-operations
• Fincons Group. (2024). A Future in Microservices for the Energy and Utilities Sector. Milan: Fincons Group.
  https://www.finconsgroup.com/blog/business-insights/energy-utilities/a-future-in-microservices-for-the-energy-utilities-sector.kl
• Christoforidis, M., et al. (2020). Integration of an Energy Management Tool and Digital Twin for Coordination and Control of Multi-Vector Smart Energy Systems. arXiv:2007.12129.
  https://arxiv.org/abs/2007.12129
• ERIGrid 2.0 Consortium. (2024). Integrating Power-to-Heat Services in Geographically Distributed Multi-Energy Systems. arXiv:2407.00093.
  https://arxiv.org/abs/2407.00093
• Cloud Native Computing Foundation. (2025). MLOps with Microservices: A Case Study on the Maritime Domain. arXiv:2506.06202.
  https://arxiv.org/html/2506.06202v2
• IBM. (2024). Event-Driven IT Operations Architecture. Armonk, NY: IBM Corporation.
  https://www.ibm.com/think/topics/event-driven-it-operations
• Dynatrace. (2025). Observability for Modern Microservice Architectures. Waltham, MA: Dynatrace LLC.
  https://www.dynatrace.com/news/blog/observability-for-modern-microservice-architectures/

How Does Docker Work?

Before we start with the installation it’s good to know a little bit about how Docker works. Docker has a client-server architecture. Docker Daemon or server is responsible for all the actions that are related to containers. The daemon receives the commands from the Docker client though cli or REST API’s. Docker client can be on the same host as daemon or it can be present on any other host. Images are the basic building blocks of Docker. Containers are built from images. Images can be configured with applications and used as a template for creating containers. Images are organized in a layered manner. Every change in an image is added as layer on top of it.

Docker registry is a repository for Docker images. Using Docker registry, you can build and share images with your team. A registry can be public or private. Docker Inc provides a hosted registry service called Docker Hub. It allows you to upload and download images from a central location. If your repository is public, all your images can be accessed by other Docker hub users. You can also create a private registry in Docker Hub. Docker hub acts like git, where you can build your images locally in your laptop, commit it and then can be pushed to the Docker hub.

Docker containers are created from images. It is a writable layer of the image. You can package your applications in a container, commit it and make it a golden image to build more containers from it. Two or more containers can be linked together to form tiered application architecture. Containers can be started, stopped, committed and terminated.

The best feature of Docker is collaboration. Docker images can be pushed to a repository and can be pulled down to any other host to run containers from that image. Moreover Docker hub has thousands of images created by users and you can pull those images down to your hosts based on your application requirements.

Installation of Docker

As said, Docker can be installed on several types of environments. ranging from Linux, via Apple’s OSX to Microsofts Azure and Windows 10. A ready environment can be obtained from Amazon AWS, Google Cloud Platform, Microsoft Azure, and a number of independent cloud providers like Digital Ocean and Rackspace. This tutorial will show how to install Docker and optionally Docker Compose on Debian and Redhat Enterprise based Linux Distributions.

Step 1: Add the repository

Debian based:

# docker requires apt-transport-https
sudo apt-get install apt-transport-https -y
# get the docker key for the docker registry
sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
# add the repository
sudo echo "deb https://apt.dockerproject.org/repo debian-jessie main" | \
sudo tee /etc/apt/sources.list.d/docker.list

RHEL based:

$ sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

STEP 2: Install the service on your Linux machine.

Debian based:

# Install the Docker engine
sudo apt-get update && sudo apt-get -y install docker-engine
# Start the docker service
sudo service docker start

RHEL based:

#Install the Docker engine
sudo yum install docker-engine
# Start the docker service
sudo service docker start

STEP 3: Create a Docker group to prevent use of the root user.

Debian based:

#The group docker should be created during installation, but can be done like this
sudo groupadd docker
#add the users that manage the docker containers to the group
sudo adduser $USER docker

RHEL based:

#The group docker should be created during installation, but can be done like this
sudo groupadd docker
#add the users that manage the docker containers to the group
sudo usermod -aG docker your_username

STEP 4: Install Docker compose (optional, only in DEV environments

Docker Compose applications are easy to share with your teams. You just need to define your application with Docker Compose once and use that same configuration to run the application on other machines to save your time.

Debian based:

To install Docker compose, we need to install the python-pip package as a prerequisite before installing the docker-compose.

sudo apt-get install python-pip

After that, you are ready to install docker-compose by running the below command in your command line terminal.

#Install Docker Compose
sudo pip install docker-compose

RHEL based:

On RedHat based systems, you will need to install epel-release and php-pip

sudo yum install -y epel-release python-pip

After that, you are ready to install docker-compose by running the below command in your command line terminal.

#Install Docker Compose
sudo pip install docker-compose

To run docker-compose successfully you will need to upgrade the php packages.

sudo yum upgrade python*

Now you have successfully installed docker-compose, docopt, requests, texttable and few other packages, and are able to compose docker contained applications. You are also able to run docker containers from a non-privileged account.
Hope this helps

Your Data, Your Responsibility, Our Business