Kyma- A flexible way to extend applications

As today’s enterprises and IT landscapes constantly evolve, and with the increasing number of cloud applications amongst many cross-vendor products, integration becomes overly complicated. This also presents new needs and challenges:

• Management and integration complexities of heterogeneous vendor products portfolio
• Changes and new features in large monolithic applications also bring process/time constraints to quickly take them to the market
• Need for the ability to make loosely coupled feature extensions outside existing monolithic applications

The Emergence of ‘Kyma’

When SAP noticed these challenges and wanted to address those, the approach it came up was to implement an open-source, cloud-native solution that leverages:

• A central extension layer that exists outside of the core applications, in which new application features are deployable independently of the core application
• Microservices so that it is independently scalable
• An event-based mechanism for a loosely-coupled architecture
• Proven and carefully selected open-source frameworks/tools so that it gets itself reinforced constantly with the support from the open-source community.
• Ability to enable developers to focus on coding rather than on operational set-up concerns

SAP, therefore, initiated the project Kymato implement this solution. Kyma is an open-source project designed on Kubernetes.

Kyma enables the implementation of end-to-end integration flows triggered by business events in existing enterprise solutions, resulting in extension modules being executed within Kyma and outside the legacy applications.

What Are the Key Capabilities of Kyma?

• An application connector module which connects any application either on-premise and/or cloud-native with Kyma and registers its APIs/events through the Kubernetes Service Catalog
• A serverless module that exposes Lambda functions as FaaS.
• A service catalog that groups reusable, integrated services from all service brokers registered in Kyma

Real-World Kyma Integration With SAP Commerce and Other Components

Let us understand the integration architecture with a sample use case. In this example, we can see that an order is placed in an e-commerce system (SAP Hybris is used as an example for Monolithic in this example). We want to validate the user credentials (via email) with an external service for fraud check. Then, we invoke another application to get additional information about the customer to decide whether to accept/hold the order. Then finally, we want to send that order decision to our Slack channel.

Kyma connects the Monolithic and other applications in this use case as follows:

Extension of a Monolithic capability via Kyma for external order validation (Reference credit — SAP)

1. Customer places an order in the e-commerce system
2. SAP Commerce starts the Order business process.
3. SAP Commerce sends the Order-placed event to Kyma. Kyma receives it (via its Application Connector Component), sends it to the event bus, and invokes a Custom Lambda function (FaaS means “Function as a Service”), which has been developed for this use case.

The Lambda then performs steps, as explained below:

4. Kyma — via its Service Catalog Component — knows the web services that are exposed by Hybris. Lambda invokes Hybris’s Order Web Service to get more information about the order (i.e. the Customer’s email address)

5. Lambda invokes an external email microservice to validate the email ID for fraud check.

6. Lambda invokes the Marketing Cloud application via Odata APIs to get more information about the Customer

7. Lamda then invokes Odata API to update the Order status in Hybris, which then completes the business process

8. Lamda finally sends those results to Slack.

So Why Use Kyma?

Note that in this above flow, we extended the Monolithic e-commerce system’s Order validation logic via with a serverless code using Lambda —WITHOUT actually coding anything in the e-commerce application, thanks to the capabilities of Kyma! Last but not least, we were able to extend a capability of the Monolithic, without coding for that feature in it!

This use case already employs six service calls/events. With the bundled tools in Kyma, it becomes easier to troubleshoot, analyze, scale, extend, and improve these interaction independently of the Monolithic commerce application.

Kyma is written in GO; it is cost-efficient and consumes fewer server resources. The advantage of this is that Kyma comes bundled with a variety of open-source tools (such as Loki for logging, Grafana for analytics and monitoring, Istio for service meshing for microservices, Dex for identity management, Jaeger for tracing, service brokers which are Open-Service-Broker-API-Compliant). All of this provides complete visibility, monitoring, and tracing of all the transactions for tuning, scaling, and optimizing.

Sample Kyma console demonstrating its integration with WordPress

Additional Use Cases

• A commerce app invoking an external pricing database/microservice for on-the-fly currency conversion/rounding/price honoring via Kyma
• A blogger who, when updating his blog (via WordPress), wants to automatically update YouTube, Twitter, and Instagram with those blog links. These automatic updates can be done using Kyma listening for blog events from WordPress and updating these social sites by connecting to their respective plugins.

Conclusion

The biggest benefit of Kyma is that you no longer have to add custom code to those legacy enterprise applications, as custom code typically introduces performance and upgrade risks. Kyma provides the benefit of extensibility at speed by combining various carefully selected open-source projects and cloud-native extensions running on Kubernetes. Yeah, go ahead and check out Kyma!

References

What is Kyma

Kyma-Youtube video for overview of features

The next evolution of extensions

SAP Kyma Open Course

Blog post on Kyma in CNCF Landscape

Kyma meets CCV2

Kyma on Kubernetes