The API Gateway capability aims to provide a set of functionalities allowing developers to expose, secure and manage their API's in an easy way. Based on the Service Mesh capability, it provides a common way to plug in security (authorization & authentication), enable routing and accessibility for all created APIs. An API can be any application (functions, GO application, etc.)

• Extend authorization strategies for APIs

  • OAuth2 server issuing access tokens for exposed Kyma APIs (both user, and non-user oriented tokens)
  • OAuth2 proxy securing exposed APIs in Kyma, allowing access based on issued access tokens
  • Enable Open Policy Agent policies for authorization and admission control
  • Support refreshing OAuth2 tokens

• Traffic management for APIs

  • Control outbound traffic for APIs - define a list of external services which the API can access
  • Control internal API traffic - specify which services can access APIs internally
  • Traffic management for different API versions - split traffic between different versions of one API
  • API failure prevention - enable setting circuit breakers for APIs

• Enable developers to create and expose APIs separated on the Namespace level

  • Allow applications to be exposed with Namespace name as a part of their hostname
  • Allow blocking communication between services living in different Namespaces

• Enable easy adoption of GraphQl in APIs

  • Allow legacy/microservice/serverless applications to be exposed and visible as GraphQl APIs
  • Automate configuration and deployment of frontend proxies to allow communication using GraphQl

• Expose services running on different environments

  • Allow proxying requests to services running outside of Kyma - on Cloud Foundry, other Kubernetes clusters etc.
  • Allow configuring the same authentication and authorization policies as for services deployed in Kyma

The Application Connectivity capability supports the extensibility and integration between applications in a cloud-native way using the best available solutions. It provides integration patterns and necessary tooling for establishing a trusted connection between Kyma and third-party applications.

The goal is to enable the integration of various systems in a coherent way, where the management and usage of APIs and Events are standardized and allow to extend such systems in a natural, cloud-native way. The unification of the connected system enables fast development which unlocks brand new possibilities for extending and customizing the existing solution in a modern, cloud-based, way.

A new way of system scalability is available. The event mechanism and simple access to the exposed API is a foundation for moving the workload from a legacy system to Kubernetes.

An additional benefit is that you can mesh different systems using the language of your choice.

The integration must be as simple as possible.

• Application Registry and Discoverability

  • Connected application can register its APIs and Event catalogs.
  • The registration contains the configuration of the endpoints together with required security credentials, documentation of the API and Event catalog based on open standards like OpenAPI and AsyncAPI, and additional documentation.
  • Registered APIs and Event catalogs will be exposed as virtual services in Service Catalog.

  • The registration of the application contains the required metadata, like health endpoints, localization, version.

• Events integration

  • The event integration functionality provides required middleware for delivery of the business events to Kyma.

  • The support for delivery guarantee, monitoring, and tracing is added.

• Access to the registered APIs
  • The access to API exposed by a connected application is provided, and all requests are proxied by the delivered proxy service.
  • The proxy service is handling the authentication and authorization, integration with monitoring and tracing. Various standard security mechanisms are provided to ensure the identity of the application. The support for OAuth, Basic auth, client certificates, CSRF tokes and more must be delivered.

  • The Service Catalog binding controls the access to the proxy service and therefore to the API. The development effort is reduced to the required minimum, and all the boiler-plate code is packed into connectors.

• Connectors
  • In the case of integration with the legacy system, which is not exposed using open standards such as REST, or if it is hidden behind a network firewall, the connectors will be provided.
  • The connector ensures that a legacy system will be exposed in the same way as other systems, and the required translation of the API calls or events will be handled.
  • The palette of provided connectors should be kept to the necessary minimum and wherever possible, the industry standards must be used.

The Console/Microfrontends capability relates to the way in which a user interacts with the Kyma UI. It drives the development of the Console, a modular and extensible web user interface for managing all aspects of Kyma.

• User Experience

  • Provide easy and intuitive user interfaces for Kyma to support its users in the best possible way.
  • Focus on a consistent user experience based on unified Fiori 3 Fundamentals style guides.
  • Enable most common user journeys in the UI so that usage of CLI is not required.
  • Don't hide the Kubernetes nature from the user but extend it with Kyma-specific user guidance.

• Extensibility & Modularity

  • Use Luigi orchestration framework as UI extension mechanism to ease customization.
  • Compose user interfaces from modular and highly reusable UI components.
  • Ensure consistent and correct usage of micro frontend-hosting.

• Fast & Responsive

  • Quick loading time for user interfaces
  • Load only the essential data that is needed for rendering user interfaces and nothing more (use GraphQL).
  • Give the user feedback for his actions (use websockets).

The Core and Supporting capability provides functionalities required to deliver the content and its visual representation. For us, content is not only regular documentation but also specifications and contextual help. Due to the nature of the content and the number of different areas it sits in, the Core and Supporting capability provides also many generic tools that not only support content but also other aspects of the product.

In other words, if some content must be displayed in a given UI, the capability cares also about the rest of the UI of a given business functionality and its backend.

• Content is written once and reused in different contexts in an efficient way on the documentation portal, as the inline help, or in the UI applications. In other words, we provide a headless CMS that is an abstraction layer on top of a more generic files storage solution that allows you to store any static content, such as client-side applications. This is possible because of:
  • The Kubernetes-native way of delivering content that supports distributed content sourcing and modularity. It means that content is delivered only if the documented component is enabled.
  • Generic reusable UI components for rendering documentation and specifications that are reusable in any context. For example, you can use them in the Service Catalog view to display documentation for ServiceClasses and their instances or in the Applications view to display the documentation of connected applications.
  • Providing the UI support for rendering specifications such as Swagger for REST API, EDM for OData, or AsyncApi for any kind of asynchronous communication.
  • The backend that allows for the reuse of content and specification details in any UI context.
• To support the out-of-the-box rendering of content in the Console UI and also make it easy for the Kyma users to generate a standalone documentation portal for their services.
• To support easy content development, enable templates integration, and allow for previewing the content before publishing.
• To support automated content validation, like links, grammar, consistency, and specification compliance.

Eventing helps you to deliver the following business use cases:

• Extend existing applications by capturing the business events and triggering business extensions developed in Kyma.
• Integrate two or more applications through business events. *Allow the application developers to define workflows to achieve a business scenario.
• Enable integrating third-party messaging systems, including Cloud PubSub solutions.

• Enable customers to plug in messaging middleware that fits their requirements best as well as to run multiple messaging implementations in parallel.
• Provide Health metrics and Performance metrics for Event Bus to enable smooth operations and proactive actions.
• Provide tooling to enable customers to benchmark Event Bus for their volume or fan-out needs.
• Align with CloudEvents specification.
• Provide a user interface for creating Event triggers for services deployed using Kyma.
• Filter Events and transfer only those with existing subscriptions (triggers).
• Generate Events inside a Kyma cluster and use them to enable asynchronous processing.
• Support sending multiple Events in a single request.
• Enable the subscriber to configure the backoff applied when the Event Bus retries to deliver the Events.
• Support semantics allowing to move the message to a dead letter queue if not processed by a function or a service.
• Enable the possibility of assigning Event attributes and specifying Event durability.

Enable the operator and developer to easily observe the state of the Kyma cluster and distributed applications running on Kyma. The pre-bundled infrastructure exposes and collects the data through application logs and metrics as well as transaction traces. This infrastructure integrates with the cloud provider-specific tools.

In a cloud-native microservice architecture, a user request often flows through dozens of different microservices. Tools such as logging and monitoring provide insights on the health and state of a particular component. Based on the results, you can act proactively and reactively to maintain or recover the health of a component. Tracing enriches observability by identifying transaction traces across the different components.

To support application observability and follow the batteries included philosophy, Kyma would provide lightweight and cloud-native solutions for logging, tracing and monitoring. Such solutions enable developers and operators to easily query all application health data across the different workloads in development and production environments.

This includes the following features:

• Setting up and maintaining optional, lightweight, and cloud-native solutions for logging, tracing and monitoring.
• As much as possible data derived out of the box from Kubernetes and the Service Mesh.
• Support for local development with Minikube.
• Pluggability of all pre-bundled tooling by having well defined interfaces in place.
• Ready-to use adapters to integrate easily with the tooling provided by the cloud providers, especially DynaTrace for monitoring.
• Easily accessible and secure API and UI/CLI to query logs, traces and metrics.
• Namespace separation support.
• Support of transactional event logs such as audit logs.
• Support for auto-scaling based on application metrics.
• Proactive and reactive alerting for potential unhealthy cluster components.
• Pre-integration with notification systems for alerting, such as VictorOps and Slack.
• End-to-end tracing of distributed applications including eventing and external system connectivity.

The Serverless Runtime capability offering is a central part of the serverless strategy of Kyma. It is the easiest way to run custom code in Kyma and to integrate different services provided by the Services Brokers and the Application Connector. Following the "batteries included" rule of Kyma, the function-as-a-service (FaaS) solution is provided inside the OSS Project.

The goal of Serverless Runtime capability is to:

• Provide a simple FaaS runtime as a part of Kyma.
• Enable an easy deployment from version control systems.
• Allow fast feedback loops for development and testing.
• Allow managing FaaS workload via UI and CLI commands.
• Integrate third-party serverless providers.
• Integrate both Kyma and third-party FaaS solutions with other services provided by Kyma, such as Eventing, API Gateway, Service Catalog.
• Provide an easy way to run containerized workloads inside and outside Kyma.
• Provide helpers/sdk/utilities to eliminate boilerplate code.

The Service Management capability wraps up the Service Catalog and the Service Brokers concepts. It enables applications that run in Kubernetes clusters to easily use internally and externally managed software offerings, such as a datastore service offered by a cloud provider. It also provides a way to list, provision, and automatically bind applications with services from the Service Brokers, with no need for detailed knowledge about how those services are created or managed.

The goal of the Service Management capability is to:

• Ensure a well-configured and hardened installation of the Service Catalog.
• Provide simple and self-guided Service Catalog UI flows.
• Assure that the Service Catalog UI functionality always goes hand in hand with the Service Catalog CLI.
• Support the Service Catalog with UI as a stand-alone solution.
• Support automated service binding injection into various types of Kubernetes applications.
• Allow registering new types of Kubernetes applications at runtime.
• Enable connected remote applications in the Service Catalog using the Application Broker.
• Enable extending the Service Catalog offerings with services that will be installed in Kubernetes using the Helm Broker and the addons repository.
• Provide a set of reusable services as addons that will extend the Kyma installation.
• Allow users to choose a set of Namespaces where a given Service Broker will be automatically registered and available.
• Allow users to reduce a number of Service Classes that will be exposed by a given Broker.
• Assure that the Service Catalog UI component for bindings is used in Deployment, Function, and other types of applications UI views.