You’ve likely heard about “cloud-native apps.” That term refers to software built for change, scale, resilience, and manageability. Oftentimes it’s equated with microservices and containers, but those aren’t required. Whether running in public or private clouds, a cloud-native app takes advantage of the elasticity and automation offered by the host platform.

But what are the implications for the data capabilities those apps depend on? While cloud-native apps have blueprints like the  twelve factor criteria to steer design, your data services don’t.

To better understand, we would look at a domain based architecture and deployment plan. We would define Master Data Management (MDM) context into the cloud native picture.

Master data is all non-transactional data within an enterprise – for example, customers, products, materials and locations. It serves as a foundation for businesses to build analytical capabilities and more effectively manage operations. An MDM platform allows businesses to manage, govern and analyze all of their master data within a single platform. This helps them develop new insights about their business, have confidence in data quality, increase productivity and improve the customer experience.

Sample Scenario: We are trying to decouple a monolith architecture into microservices using the levers of DDD (Domain Driven Design), Access pattern for performance, and cross-domain reference of persistent data using keys. Lets look at how this spans out..

Lets define the monolith application

 

Defining the Data Domains

Product Master

This compiles, validates, enriches, and curates all your organization’s product-related data into a complete, accurate, and easily reportable golden copy. Some examples of product-related data include product types, product lines and groups, product pricing (billing) schemes, product hierarchies and historical product details.A good product master, however, will establish the right workflows and critical data elements (CDE’s) within product attributes. It will also identify processes by which to ingest and govern that product data, regardless of how that may be defined within the organization.

Customer Master

Knowing your customer helps you to push the right content through the right channel at the right time in your customer’s purchase lifecycle. A customer master solution enables you to understand and adapt to evolving customer needs and analyze and nurture customer relationships for both B2B and B2C contexts.

Vendor Master

This manages vendor data alongside product and customer data. You can maintain relationships between customer, vendor and product domains on a single platform by standardizing the vendor creation process across brands and geographies. Enrich vendor data through address verification and maintain the Tax Jurisdiction Code by integrating with third-party providers.

Lets look at the Cloud native architecture

Cloud native Transformation

Integrated Solution

Making this performant

Logical View of the final architecture

Key Characteristics

• Simple Dataset
• Highly Scalable
• Optimized Performance Tuning
• Dedicated Caching Backing Service
• Remove inter-team Data Model Dependencies
• Allow iterative improvement

Tool Selection Strategy

• In-memory data grid (IMDG) based on Apache Geode – Ex. CQRS pattern
• Scalability, availability, and performance
• Supports many design patterns – Side cache, Inline cache, Http session management, event driven, Data aware compute (M/R)
• Supports data replication (multi data center) – Active/Active, active-passive, DR
• CI/CD friendly

How does Kyma solve your deployment challenges?

• Monitoring and alerting is based on Prometheus and Grafana
• Logging is based on Loki
• Eventing uses Knative and NATS
• Asset management uses Minio as a storage
• Service Mesh is based on Istio
• Tracing is done with Jaeger
• Authentication is supported by dex

Food for thought – below, we look at ten characteristics of cloud-native data and why each one helps you deliver better software.

Cloud-native data is…

1. Stored in many ways.
2. Independent of fixed schemas.
3. Duplicated.
4. Integrated via service interfaces.
5. Self-service oriented.
6. Isolated from other tenants.
7. At home on managed platforms.
8. Not afraid of scale (out).
9. Often used and discarded.
10. Analyzed in real-time and batch.