The integration revolution: Building bridges between On-premises and Cloud ecosystems

© OPITZ CONSULTING 2024 / Öffentlich
The Integration revolution: Building bridges between On-premises and Cloud ecosystems 1
Building bridges between on-
premises and cloud ecosystems
Nuremberg, 22.11.2024
Sven Bernhardt
THE INTEGRATION
REVOLUTION
Photo by Chris Becker on Unsplash

13.192
Length of the German highway network (in km)

Source: adac.de

Demands on systems
are continually shifting

Source: Unsplash

17.636
RAILROAD LINE
IN NEED OF RENOVATION (IN KM)
1.160
RAILROAD BRIDGES
IN NEED OF RENOVATION
7.112
HIGHWAY
IN NEED OF RENOVATION (IN KM)
8.000
HIGHWAY BRIDGES
IN NEED OF RENOVATION

Source: sueddeutsche.de

CURRENT ARCHITECTURES: STANDALONE MONOLITHIC DATA SILOS

STRATEGIC OPTIONS FOR MODERNIZATION
The Integration revolution: Building bridges between On-premises and Cloud ecosystems
Current
situation
?
Continuation
Monolith
today tomorrow day after tomorrow
Retention
Platformshift /
Generator Concepts
?
Monolith Crunching
Reengineering
Commercial off-the-Shelf (COTS)
Relief
Change
Deprecated applications
(mostly monolithic):
• Legacy Java
(pre-cloud-native)
• Legacy App Server
• Cobol
• RPG
• Database monoliths
Condition:
Structurally
unsustainable
Save time, postpone problem to later
Modernized applications
(mostly cloud-native):
• Containerized
• Aligned with Business
Capabilities
• Maintenance-friendly
• Design for Change
Condition:
Structurally
sustainable
Is there new, cost-optimized software on the market??
The "right" way
can only be decided
individually.
e.g. Lift&Shift, CI/CD, dyn. Runtime env
9

CURRENTLY: CLASSIC, MONOLITHIC SYSTEM ARCHITECTURE
Business Domain
On-prem infrastructure
Standard
(On-Prem)
Business Domain
Monolith
Business Domain
Standard
(On-Prem)
Monolith

ZOOMING IN A TYPICAL SYSTEM ARCHITECTURE
SharePoint
PVS
Doxis
FiBu
LoBu
Active Directory
DWH
assyst
OpenScape
HR4You
Oscar
LoBu PL
Onesto
Exchange
FileServer
Steak
TLMT
Website + Tracking

TARGET: PRODUCT-ORIENTED SYSTEM ARCHITECTURE
Digital
Product
Digital
Product
Business Domain
Shared Platform (Monitoring, Integration, Development, etc.)
Hybrid, flexible infrastructure incl. Cloud Services
Standard
(On-Prem)
Business Domain
Business Domain
Digital Product
Standard
(On-Prem)
SaaS-Cloud
Standard
SaaS
Digital
Product

Modernization always
affects technologies,
organizations &
people

FROM CENTRALIZED TO DISTRIBUTED ARCHITECTURES
UI
Business
Logic
Persistence

WE LIVE IN A „DECENTRALIZE-ERA“!
Centralized
STATIC
ON-PREM
MONOLITH
VIRTUAL MACHINES
MANUAL CHANGE PROCESS
Decentralized
DYNAMIC
CLOUD / MULTI-CLOUD
MICROSERVICES / SERVERLESS
CONTAINERS, KUBERNETES
AUTOMATED CI/CD TOOL CHAIN
# Services & APIs
CONTROL AND VISIBILITY
15

You need to ensure
end-to-end
connectivity

INTEGRATION? IT’S JUST ABOUT BOXES AND LINES!
Goals:
 Enabling systems to talk to each other
 Ensure that data is where it is needed when it is needed in the form in which it is needed
Gregor Hohpe
A small line. That‘s where the beef is!

INTEGRATION AREAS
User-centric
apps („users”)
Real-life
objects
(„things”)
Cloud
On premise
Cloud to user
On premise to user
Cloud to thing
On premise to thing
Cloud to cloud
On premise to on premise
 There are seven typical integration areas in IT landscapes
Cloud to on premise
1
2
3
4
5
6
7

INTEGRATION CHALLENGES ARE MULTIDIMENSIONAL

BASED ON PATTERNS THAT ARE STABLE SINCE DECADES
Content-based Router
Message Filter
Splitter
Aggregator
Normalizer
Resequencer
https://www.enterpriseintegrationpatterns.com

API GATEWAY
 It is basically an agnostic architecture pattern
 Defines a single entry point for clients to
access services
 No matter the implementation technology
 No matter the deployment model (Monolithic
or µService)
 Decouples Client and Service implementation
 Is deployed separately in its instance
Source: https://microservices.io/patterns/apigateway.html

Application
Application
Application
Client
Items Customers
Orders Invoices
Load Balancer
SHIFT FROM MONOLITHIC TO MICROSERVICE …
22

Client
Items
Items
Items
Items
Items
Customers
Items
Items
Invoices
Items
Items
Orders
Client may beanother service
Load Balancer
Load Balancer
ORGANIZATIONS START BREAKING UP THE MONOLITHS

Client
Items
Items
Items
Items
Items
Customers
Items
Items
Invoices
Items
Items
Orders
MORE
LOGIC
Load Balancer
Load Balancer
- Authentication
- Security
- Logging
- Transformations
- Load-Balancing
- Etc
NEW STANDALONE APPS NEED TO BE SECURED AND MANAGED

Load Balancer
Client
Items
Items
Items
Items
Items
Customers
Items
Items
Invoices
Items
Items
Orders
MORE
LOGIC
Load Balancer MORE
LOGIC
Load Balancer
- Authentication
- Security
- Logging
- Transformations
- Load-Balancing
- Etc
- Authentication
- Security
- Logging
- Transformations
- Load-Balancing
- Etc
WE STILL NEED COMMON FUNCTIONALITY

Load Balancer
Client
Items
Items
Items
Items
Items
Customers
Items
Items
Invoices
Items
Items
Orders
Load Balancer
MORE
LOGIC
Load Balancer MORE
LOGIC
MORE
LOGIC
MORE
LOGIC
Load Balancer
- Authentication
- Encryption
- Logging
- Transformations
- Load-Balancing
- etc.
- Authentication
- Encryption
- Logging
- Transformations
- Load-Balancing
- etc.
- Authentication
- Encryption
- Logging
- Transformations
- Load-Balancing
- etc.
- Authentication
- Encryption
- Logging
- Transformations
- Load-Balancing
- etc.
… CAN LEAD TO FRAGMENTATION
26

API GATEWAY WILL BECOME THE CENTRAL SHARED POLICY LAYER
Business
Logic (B)
Policy (P)
OTHER
MONOLITH
Routing
Load Balancing
Authentication
Authorization
Logs & Metrics
Rate Limiting
Caching
Validation
Transformation
MICROSERVICES
MULTI-CLOUD & KUBERNETES
ON-PREMISE
HOSTING
B
Shared Policy Layer (API Gateway)
B B B B B B
B B B
Serverless
(e.g. AWS
Lambda)
More applications and services
More languages and protocols
REST}
{
More deployment types
3RD-PARTY

CLASSIC API GATEWAY
MONOLITHIC APP
API
API MANAGEMENT
CLIENT
PRIVATE
TRAFFIC
PUBLIC TRAFFIC
𝗫 High Performance
𝗫 Multi-cloud and Hybrid
𝗫 Kubernetes-native
𝗫 CI/CD automation
𝗫 Modern Protocols
→High Cost, Lost Revenue
→Lock-in, Security Risk
→Dev. Inefficiency, Security Risk
→Dev. Inefficiency, Poor Quality
→Dev. Inefficiency, Opportunity Cost
API GATEWAY EVOLUTION: MONOLITHIC API GATEWAY
28

CLASSIC API GATEWAY MODERN API GATEWAY
MONOLITHIC APP
API
API MANAGEMENT
CLIENT
PRIVATE
TRAFFIC
PUBLIC TRAFFIC
GW DP
CLIENT
PUBLIC TRAFFIC
GW
DP
API
APP
API
APP
API
APP
API
APP
API
APP
GW
DP
GW
DP
✓ High Performance
✓ Multi-cloud and Hybrid
✓ Kubernetes-native
✓ CI/CD automation
✓ Modern protocols
API GATEWAY EVOLUTION: DISTRIBUTED AOI GATEWAY
29

HOW TO DEAL WITH SECURITY, RELIABILITY AND OBSERVABILITY?
f(x)
f(x)
f(x)
f(x)
f(x)
On-premises
Cloud
SaaS
Mondern Integration

SERVICE MESH
 Efficient implementation of cross-cutting
concerns with respect to service
integration challenges
 Everything is a service!
 Cloud-native apps deployed to Kubernetes
 Non Cloud-native workloads
 Should be independent of
 Architecture (e.g. Monolithic or µService)
 Platform (e.g. VMs, Containers, Kubernetes)
Dedicated infrastructure layer that
makes service-to-service communication
more reliable, secure and observable

A MESH CAN SPAN MULTIPLE CLOUDS AND MULTIPLE CLUSTERS

MODERN API GATEWAY FULL SERVICE CONNECTIVITY
GW DP
CLIENT
PUBLIC TRAFFIC
GW
DP
API
APP
API
APP
API
APP
API
APP
API
APP
GW
DP
GW
DP
GW DP
CLIENT
PUBLIC TRAFFIC
GW
DP
MESH CP
MESH1 MESH2
API GATEWAY EVOLUTION: SERVICE CONNECTIVITY PLATFORM
33
✓ Developer experience
✓ Zero Trust security
✓ Self service networking
✓ Seamless observability
✓ Reliable connectivity

Modernization without
integration and APIs is
not possible

CLOUD-AGNOSTIC INTEGRATION – THIS IS THE WAY…
 Best-of-breed approach
 Cloud-native architecture
 Containerization
 Kubernetes as Core runtime platform
 Single execution process per integration
 Core components:
 Distributed, lightweight ESB
 Event Hub for async integration
 API Gateway for sync integration
 Focus on horizontal as well as vertical
integration challenges

TECHNOLOGY BASE - USE OPEN INDUSTRY STANDARDS
https://landscape.cncf.io/

Think about your
potential exit strategy
early

CRUSHING THE MONOLITH
Seite 38
Was completely transferred to SCS
Own microservices/SCSs with web UI, mobile UI and
chatbot interface (teams and mobile) with API
connection
Introduction of standard software (Salesforce, etc.)

DESIRED SITUATION – STRUCTURED INTEGRATION
Doxis
Active Directory
DWH
assyst
OpenScape
Oscar
Lohn Polen
Onesto
Exchange
FileServer
Steak
Website + Tracking
CRM
OC Integration
Platform (OCIP)
ERP
SharePoint
TLMT
3rd Party Cloud(s)
HR
Business Partners OC employees

OC SPINE IS BUILT ON CLOUD-NATIVE PRINCIPLES …
40

… AND TECHNOLOGIES
 Open-Source tools from CNCF landscape
 Key technology components
 API Gateway (Kong)
 Event Hub (Confluent Cloud)
 Schema Registry (Confluent Schema Registry)
 Apicurio (API Registry)
 Secrets Management (HashiCorp Vault)
 Identity Management (Keycloak)
 Service Mesh (Kuma)
 Application-level monitoring is done with
Grafana Stack (Grafana Cloud)

SERVICE CATEGORIES
42
 Presentation Services (Single-purpose APIs)
 Expose tailored information set for specific clients
 Use the information provided by Domain services
 Business Services (Multi-purpose APIs)
 Implement business resp. domain logic
 Operate on a domain object model
 Combine information provided by Adapters
 Connectivity Services (Adapter)
 Implement system-specific logic
 Convert data & Protocols
 Expose a domain model

“LEGO”-LIKE COMPONENT ARCHITECTURE
43
EventHub
PVS
DWH
Other Systems
API Gateway
ChangedDataEvent
DomainEvent
DomainEvent
DomainEvent InsertChangedData
InsertChangedData
GetSalesforceObject
GetDomainObject

CENTRALIZED OBSERVABILITY
 Challenge: Distributed integration
architecture that consists of multiple,
independent services
 Provide a centralized 360-degree view of
distributed integration architecture
 Infrastructure view / Platform health
 Application view / Integrations apps
 More efficient troubleshooting
 Key components:
 Grafana Stack, Datadog, EFK
 Service Mesh (Kuma, Istio, Consul Mesh)

TRACING EXAMPLE VIEW (WITH APP INSTRUMENTATION)

EXAMPLE ERROR DASHBOARD (BASED ON APPLICATION LOGS)

TRANSPARENT ERROR HANDLING
 Different exception types
 Retryable (Network errors, Rate limits, etc.)
 Non-Retryable (Data errors, Business errors,
etc.)
 Use of resilience patterns for auto-retry
exceptions
 Circuit breakers
 Timeouts
 Retries
 Central view on errors
 Proactive notifications to platform and
product teams

CONCLUSION
 Modernization always affects technologies,
organizations & people
 You need to ensure end-to-end connectivity
 Modernization without integration and APIs is
not possible
 Think about your potential exit strategy early
Photo by Chris Becker on Unsplash

IN CASE OF ANY QUESTIONS…
Sven Bernhardt
Chief Architect / Integration Evangelist | Kong
Champion
OPITZ CONSULTING Deutschland GmbH
Kirchstrasse 6, 51647 Gummersbach, Germany
Phone: +49 172 2193529
Mail: sven.bernhardt@opitz-consulting.com
X: @sbernhardt
Blog: https://svenbernhardt.wordpress.com

The integration revolution: Building bridges between On-premises and Cloud ecosystems

Contenu connexe

Similaire à The integration revolution: Building bridges between On-premises and Cloud ecosystems

Plus de Sven Bernhardt

Dernier

The integration revolution: Building bridges between On-premises and Cloud ecosystems