With winter holidays and 2019 around the corner, let's think about something hotter and more exotic. A city perhaps... Cairo? Sounds good, right?

If you're wondering what does Cairo have to do with Kyma, we're happy to explain. We decided that new releases need a cool common identification theme. After a long, coffee-fuelled brainstorming session we decided to name our releases after major cities in the world. Cool, right?

Soooo... What can you expect from Kyma 0.6 Cairo?

Knative integration is our main focus for this release. The new Knative Working Group (click here to visit its Slack channel) works tirelessly to make Knative components available in Kyma clusters. By enabling a special toggle you will be able to delegate the eventing and messaging duties to Knative and use its ingress gateway for API exposure.

The Prow Working Group is also firing on all cylinders. Soon all contributors will be able to see the build status and the logs for their pull requests. What's even more exciting, Cairo will be built using the new CI architecture!

We're also working on a more consistent naming scheme for all of our components. As Kyma users are well familiar with Kubernetes Namespaces, we decided to abandon our custom term "Environment" and use the Kubernetes standard instead.
The renaming will also affect the Application Connector, as we'll say goodbye to "Remote Environments" and start using the "Application" name instead. This is an important step that follows our Application Connectivity vision. You can read more about both renaming efforts in this Slack post.

In parallel, we are working continuously on the Kyma UI/UX - you can expect a better navigation structure and technical foundation for UI modularization and extensibility, achieved by switching Console UI to Luigi framework.

With the 0.6 release, we aim to improve code quality by introducing common libraries and unifying the acceptance tests code base. Additionally, the delivery of tools for testing the Service Catalog UI is planned.

Last, but definitely not the least, we're continuously improving the security of Kyma. In the 0.6 release we're extending the UI-API Layer (GraphQL) with an authorization concept.

You can find all items planned for the 0.6 in Zenhub. Come back and check out Kyma 0.6 Cairo when it's released on 14.01.2019 and keep an eye out for more Kyma news and updates on our blog.

See you around!

From the early stages of its development, Kyma has raised interest among other companies. The main reasons for that were Kyma's existing open-source technologies that constitute its cornerstone, and the fact that it allows companies to extend and customize their enterprise applications using serverless computing or microservice architecture.

Innovative companies are constantly seeking ways to identify and experience new technology solutions that can provide potential benefits to their businesses. Receiving feedback from such companies at the early stage was very valuable to the Kyma team. As a result, we could make the necessary improvements to the product and launch its refined version as an open-source project.

Before going open-source, Kyma was prelaunched to a selected group of companies. One of them was XXXLutz KG, one of the world’s top furniture retailers. The company representatives received privileged early access to Kyma and were encouraged to test it. If you are interested in the outcome, watch the video below where Christian Renner, the Chief Technology Officer of the XXXLutz Group, explains why they wanted to test Kyma and what their experience with the project was like.

Getting feedback and contributions from the open-source community remains our focus moving forward. Feel invited to start your very own Kyma journey:

• Install Kyma and test it.
• Explore the examples on GitHub.
• Share your feedback on Slack.
• Join the Kyma community on Twitter and LinkedIn for the latest news.

We are looking forward to your feedback and engagement!

As you may already know, the KubeCon conference, known among the whole Kubernetes and CNCF community, is taking place in Seattle on December 10. This one-liner intro already clarifies why we, the Kyma people, want to be there too. Our main focus is:

• To meet you, show you what Kyma is, and answer all your questions
• Meet with other communities. For now, we are planning to meet with the Kubernetes' Testing SIG and the Service Catalog SIG and talk about our future contributions.

These Kyma experts are comming:

• Ralf Hofmann, our Product Lead
• Krassimir Semerdzhiev, our Strategist
• Ahmed Abdalla, the leader of the Kyma's Core SIG and our Lead Product Engineer
• Piotr Kopczynski, the leader of the Kyma's Core SIG and the owner of the Kyma's Service Catalog capability
• Lukasz Gornicki, the leader of the Kyma's Core SIG and the owner of the Kyma's Core and Supporting capability

The easiest way to talk to us before the event is to do it through Slack. During the event, you can easily find all Kyma members that travel to Seattle at the SAP booth. Why SAP? Kyma was donated to the open-source community a few months ago by SAP. Stop by and find us at the SAP booth together with another great Kubernetes-native project called Gardener.

So what are you waiting for? Install Kyma now and prepare your questions.

See you there and follow us for any updates on Twitter.

We constantly work improving Kyma and modularizing it further. Shortly after our last release, we now introduce the next update including many changes.

Application Connector

With the overall strategy to modularize Kyma as a whole, the Application Connector went through this change as well:

• The Application Connector has been modularized. All components have been moved to a separate Helm chart and are no longer a part of the Core. This also includes changes in the naming of the elements. The Gateway service has been renamed to the Proxy service.
• The Application Connector tests were extended with an additional flag for skipping SSL verification. It allows testing functionality against the Kyma cluster with a self-signed certificate.
• The Connector service now returns a client certificate as a full chain with a server-side certificate. The verification of a client certificate is now possible.

Serverless

Making use of serverless concepts and technologies is what makes Kyma so great. Hence, we made a number of improvements in this area:

• The Lambda UI was extended with the option to set Environment Variable Prefixes for Service Bindings. This allows binding multiple services with the same set of environment variables.
• The Lambda UI was extended with the option to set JWK Authentication Properties. This allows defining specific Token Issuers.

Authentication is enabled by default, and you can change JWKs URI using the Load Present option.

• The Lambda UI was extended with an alert informing you if you are about to leave the Lambda UI with unsaved changes.

Service Catalog

We did a lot of great enhancements to the Kyma Service Catalog:

• Support for "namespaced" service catalogs. This means a possibility to register brokers for specific Namespaces only. The Catalog has an additional Brokers view in the Environment context. The view lists Service Brokers registered only for a given Namespace.

  • Here you can view a new getting started guide about brokers registration.

  • Here you can find an architecture diagram for the Namespace catalog.

  • The instance list and details views now work on web-sockets. This significantly improves the user experience because all changes to the instance, and most important its status, are updated in real-time in the view without the need for a page refresh. If you are interested in how we managed to accomplish that on a GraphQL layer with Istio and token verification, feel free to contact us on Slack.

• A completely new binding flow has been implemented in the instance view. Based on your feedback, we made sure it is far less complex than before:

  • Names for resources are autogenerated.
  • When binding to the application, you do not have to decide if you want to bind to Deployment first or maybe to the Function, as all applications are listed in one component for your convenience.

  

  • You can set a proxy for instance environment variables that are injected to your application.

  

  • The status of credentials (ServiceBinding) and application binding (ServiceBindingUsage) is now visible. Even more, if you are viewing the bindings and in the meantime the credentials creation fails, the UI indicates the failure and adds a red marker on the tab. This way, you know something wrong happened and you need to check the tab.

  

  

  • The UI supports the ServiceBinding creation if the owner of the service class specified a custom schema for binding creation.
  • The cleanup of resources got improved. When you decide to delete some Credentials, the related application bindings are also deleted.

• Helm Broker supports many bundle repositories.

• The new bundles repository enables Kyma to install addons such as brokers, showcases and local services.

  • It contains bundles which the Helm Broker uses. It allows you to choose a set of bundles and configure the Helm Broker. You can also define your own bundles.
  • Have a look at the getting started document which explains how to create your own bundles repository.

Eventing

As eventing is one of the core principles Kyma is built on, we enhanced the functionality further:

• It is now possible for developers to change their subscriptions and fix any typos or wrong configurations. It allows avoiding a situation where, for example, specifying a wrong URL causes wrong Event type to be updated. Click here to see how this can be done.

• A bug, which caused that it was impossible to create two subscriptions with same name in different Namespaces, has been fixed.

• Kyma now enables a developer to understand better how to leverage tracing for handling problems in the Event flow.

Known issues

There is a known intermittent Event trigger issue that causes the Events to not be delivered to lambdas or microservices.

We are aware of this issue and we will provide a fix for it as part of the issue.

Technical details

The issue lies in the subscription validator application. The application sometimes does not react when Kubernetes notifies it about creating new EventActivation instances.

Workaround

As a temporary fix for this issue, delete the sub-validator Pod by running the following command:

$ kubectl delete pod $(kubectl get pods -l app=sub-validator -n kyma-system --output=jsonpath={.items..metadata.name}) -n kyma-systemC

After deleting the sub-validator Pod, Kubernetes recreates it automatically, and the issue should be fixed.

Security

We constantly work on improving the security of Kyma:

• Documentation is now available on how to update TLS certificates.
• The static user password for administrators is generated during installation and stored in the secret admin-user in the kyma-system Namespace. You can add further static users by providing your own Kubernetes secrets. Use this link to learn more.

Service Mesh

Istio is now installed from official Istio charts. Istio customization was externalized into a separate component: istio-patch. As a result, Kyma can be installed on top of an existing Istio installation (in the supported version).

Installation

The installation documentation was reorganized and grouped under Installation.

Monitoring

To keep track of your Kyma systems, we enhanced the following:

• An Alert is defined if an Pod is not restarting in one of the system Namespaces. This enables basic monitoring of the kyma-system.

• Promehteus alerting webhooks are exposed in the configuration. This enables the integration of Prometheus alerting in custom dashboards.
• HTTP configuration now allows to define different ways of authentication in the face of the webhook. Basic auth, Tls and Baere token are some of them.

Known Issues

The Istio-related dashboards are not showing any data. For details, see issue.

Workaround 

None

Logging

Kyma was extended with Persistence Layer for logging based on OK Log.

Tracing

The Tracing UI is now linked from within the Kyma Console UI to make it easier to access the tracing information. Furthermore, it is now possible to compare two traces to track the process. You can get an answer to the question: "Why did something unexpected happened?" You can find more details here.

Console

• You can extend the Console to add custom micro front-ends either for a single environment or for cluster-wide administration. More details can be found here.

• It is now possible to view and edit ConfigMaps:

Is Tesla Model X still a car, or is it a smart device? This might sound like a silly question, as the Model X has all of the usual "car" traits: an engine, metal bodywork, rims, tires, etc. On paper, the Model X might look like yet another car, but its uniqueness, aside from the electric engine, of course, lies in the software innovation that Tesla brings to the market. The ability to update the onboard software over-the-air and bring new features and functionalities to a car is a key factor that attracts consumers to buy Teslas. This revolution shows that innovation, even in industries as old as car manufacturing, is an important and powerful tool that allows to penetrate the market faster. Many of the leading car manufacturers are still trying to catch up with Tesla's success. Businesses need to leverage new technologies, take on innovations and transform digitally to be competitive. Simply put - innovate or perish!

On our ongoing innovation journey, we have identified several challenges for companies that go through this process of digital transformation:

• Heterogeneous Product Portfolio: Single-vendor solutions are a thing of the past. (ref: https://www.thoughtworks.com/de/insights/blog/implications-tech-stack-complexity-executives). Companies don't want to invest in a single vendor product stack. They need to have best of breed products. Heterogeneity is unavoidable, so software product companies need to be ready to embrace the diversity and be open to work hand in hand with the dreaded competition.

• Monolithic deployment: Monolithic applications can be great, but as the size grows, so does the complexity. This slows down the time to market, adds complexity to testing and shipping, complicates adding new features or extensions, and makes scaling difficult. Currently many of the best available products are still monolithic.

• Cloud-native: Companies are moving faster towards using cloud-native open source stacks for production (ref: https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/). The Cloud Native Computing Foundation (CNCF) describes "cloud-native" software as one that is container-packaged, dynamically orchestrated and managed, and microservice-architected. Building cloud-native solutions is not easy. It requires better inter-service communication, proper traceability of transactions across solutions, logging across several services and solutions, proper monitoring and operating hundreds of services.

• The "need for speed": Some of our customers say that "speed is the new ultimate currency". It's challenging to develop at a faster pace while facing the challenges of heterogeneity, monolithic deployment and trying to teach every developer in the organization the ways of cloud-native development.

Kyma has worked hard to overcome these challenges and support businesses throughout their digital transformation journey. Kyma is an open-source project designed natively on Kubernetes. It allows you to extend and customize cloud-based and on-premise enterprise applications in a quick and modern way, using serverless computing and microservice architecture.

This way, Kyma enables businesses to:

• Be open and extendable: Using any Open Service Broker API specification-compatible service is a "plug and play" affair which gives you access to a catalog of reusable, integrated services for developers, both in-house and 3rd party. This allows you to use business services and technical backing services from different vendors to extend your existing applications.

• Be seamlessly connected: The simplified approach to secure connectivity between systems allows seamless API and event integration of the existing applications. You can manage and orchestrate existing applications to build common extension solution even in heterogeneous landscapes. A single connection gives you multiple possibilities.

• Use any programming language: Develop microservices or serverless functions using any programming language and enjoy more hiring options as a result.

• Bring speed and agility: Businesses don't have to wait for months or years to deliver specific scenarios or use cases. With Kyma the delivery times are faster (within days or weeks) and the entire process costs less.

• Accelerate innovation: In many cases innovation starts as a test or a trail. In such cases, both speed and low cost are of great importance. Kyma enables businesses to start working on their solutions immediately instead of finding the right technology and integration options first and brings the startup culture to enterprises.

Kyma is available on GitHub and open for developers to contribute. It allows businesses to build and advance products and services they offer to make them even better on the marketplace. This empowers companies to stand out, to increase revenue, and to be more like Tesla.

It has been a while since we introduced Kyma to the open-source community. Many things have changed in the project since its announcement in July. Now that we have our first official release, it is time to sum up what we have recently worked on.

Security

In the area of security, we focused on our API Gateway that you can use to expose your API easily and in a secure way. We improved the following things:

• When you create the Api kind, hostname is validated to make sure you provided the correct domain and that there are no duplicates.
• The architecture of the API Gateway component has changed. The services are now exposed by the Istio Gateway and the Istio Virtual Service, instead of the Istio Ingress.
• You can create several APIs for a single service in the Console UI by creating the API for a specific service in the Services view, or several different APIs from the APIs view.

Service Catalog

The Service Catalog, that is one of our key features, has undergone a lot of improvements over the last months, mainly thanks to your valuable feedback. To be more specific, the Console UI part of the Catalog was improved through the following changes:

• The multi-step service provisioning wizard was replaced with a one-step wizard.
• You can preview the Instance's parameters by clicking the Instance's Plan name both on the list of all Service Instances and in the given Service Instance's details.
• The Service Catalog's left navigation was removed and filtering is now available next to the search box. In its current form, it aims to support new filter options that will be introduced in the future. It also scales much better now when there are many values provided in the filters.

The Console UI is not everything, however. These are further changes:

• The Catalog was upgraded to v0.1.34 that supports the Environment-wide resources (ServiceBroker, ServiceClass, ServicePlan). The related Console views do not support it yet.
• A new dashboard was provided in Grafana to improve Service Catalog-related operations.

Application Connector

The Application Connector, that allows you to connect external systems with Kyma, underwent these major improvements:

• Management of the Remote Environments (RE) is no longer done through the Helm chart. Instead, we have a controller that reacts to changes in the RE and sets up the whole Environment.
• The RemoteEnvironments CRD was enhanced with an extra label field. Now, you can mark the purpose of the Remote Environment in a flexible way.
• The OAuth token caching functionality was added to the Application Connector.

Logging

Kyma has a new component to enhance its logging capabilities. This component is based on Logspout and OK Log.

Monitoring

Through the proper Grafana configuration, all dashboards created by you in the runtime are persistent, and Pods restarts do not remove them.

Event Bus

Our Kyma would not be so great without the support for the asynchronous communication between services. This is what we improved in that scope:

• We enabled an Event lifecycle for storing Events in a cluster. By default, it is set to 24h, but you can configure the lifecycle in the NATS Streaming's StatefulSet by changing the max_age value.
• We added the documentation for the service programming model for the Event subscribers. Read more here.

Tracing

As you know, Kyma uses Jaeger as the tracing back-end. To improve its usage, we:

• Secured the Jaeger UI so that you could access it easily without port-forwarding. Read more about Jaeger.
• Created an example on how to enable tracing for an application. Read more here.

Service Mesh

At the moment, Kyma is using Istio 1.0.1.

Installation

The following improvements were done in the installation area:

• The Kyma installation on a Google Kubernetes Engine cluster is now possible mainly due to the implementation of the API Server Proxy component.
• You can override values in Helm charts using config maps annotated with the installer: overrides label.
• The extended Installation custom resource was enabled to allow you to provide a declarative list of modules that will be installed during the Kyma provisioning process.

Documentation

A few weeks after the Kyma announcement, we published the official documentation on our https://kyma-project.io/docs/ website. It is worth remembering, however, that this is not the only place where you can read the docs. Since the very beginning, the Kyma documentation has been an integral part of the Console UI, so whenever you provision a Kyma cluster, docs for a given Kyma version are always there for you. In the last few months we have improved the following features in that area:

• The Kyma overview documentation and many other sections, like consistency of the Custom Resource reference documents.
• The general feel and look of the documentation, its navigation, consistency, and the readability of the content.

SAP TechEd is the premier SAP technology conference, which takes place every year on 3 continents and is an excellent source of news on the technical and platform offerings of SAP. In 2018 the conference venues are located in Las Vegas, Barcelona, and Bangalore.

As the centerpiece of a number of implementation projects, and the cornerstone of the upcoming SAP Cloud Platform Extension Factory Lab Preview, Kyma must be represented by the best ambassadors on each of the three events. These people will represent the product, answer all questions and be the first point of contact for all the attendees interested in Kyma.

• For the Las Vegas (02-05.Oct) event the ambassadors include myself (@evilyeti), Gopi Kannappan (@gopikannappan) and Hisar Balik. You can find us hanging around the SAP Cloud Platform booths and on the C/4HANA sessions we have on the agenda.

• For the Barcelona (23-25.Oct) event the ambassadors are Marco Dorn (@mado0803), Stanimir Ivanov (@s1vanov) and Lukasz Szymik (@lszymik) who will also be available either at the SAP Cloud Platform booths or at the C/4HANA sessions they'll run.

• Last but not least – for the Bangalore (25-30.Nov) event we have Johannes Engelke (@quablab) and Sayan Hazra as the ambassadors. They'll make sure to spread the word about Kyma, and tell the attendees all about the extensibility of the product, and the Serverless functions.

We're super excited to see the Kyma story grow and more ideas come onboard. Feel free to meet all of the ambassadors and talk about Kyma and software extensibility, or any ideas you might have around these topics. The conversation might get you some cool merch as we might have some stickers to share with our lovely guests. Don't be shy! See you there!

Knative is an important new project in the cloud-native world that was announced as a "Kubernetes-based platform to build, deploy, and manage modern serverless workloads." It is an opinionated approach covering the best practices around three areas of developing cloud-native applications: building containers (and functions), serving (and dynamically scaling) workloads, and eventing. Knative is an open-source set of components and is being actively developed by Google in close partnership with Pivotal, IBM, Red Hat, and SAP.

Similarly to Kubeless, Knative provides a set of building blocks to simplify the use of Kubernetes and Istio for managing and operating lambda functions. Kubeless takes some code, builds an image out of it, and starts it on Kubernetes. Knative is doing the same by following a more modular approach, allowing different components to be pluggable and adaptable to different deployment scenarios.

Because of this more flexible approach, we are planning to replace the current Kubeless-based Lambda Functions in Kyma with a Knative-based implementation. To provide the same commodity to which users are used with Kubeless, we have to do some extra work.

Architecture

So far, the architecture is not shaped out fully. Many details have to be sorted out and defined. The idea is to use Knative as it is and try to bridge the existing gaps using custom components, other available open-source projects (e.g. Riff), or pushing enhancements to the Knative community. In the end, Knative should provide the same functionality as Kubeless is doing today.

The core of the architecture are the Knative Serving and Build components. As a Kyma-related component, a custom build template is required to provide the function interface available in Kubeless.

Besides the build template, a custom Docker registry is required to store the build artifacts, and a storage solution to store the function code. This could be either a Git repository or a blob storage like Minio or S3. In the end, customers should be able to decide if they like to keep the function code in their own Git repository or if they prefer to store it in a storage solution provided by Kyma.

Implementation

As the implementation involves multiple components and will involve breaking changes, we will keep Kubeless till we are sure that the new version is working as expected. In the first step, Knative Serving and Build components will be integrated as optional Kyma modules. If this is working, other parts, such as the Docker registry, blob storage, and build template, will be enabled step by step. As the last step, a new (forked) lambda UI will be created and adjusted to the Knative needs. As soon as everything is working fine, Kubeless will fade out. Knative will be the new default component and Kubeless will be used as long as there are still any old deployments available. As soon as we are sure that nobody is using the old Kubeless-based implementation, we will remove it completely.

Now that Kyma is out there available to the world you are most probably keen on testing and implementing your own scenarios leveraging Kyma. Well, we are happy to introduce you to a getting started guide for developers which is a sample application based on Spring Boot showing the features on Kyma.

This hands-on guide provides an end-to-end example application implementation in Java and Spring Boot running on Kyma. In the end state, you as a developer will understand all the features Kyma delivers. To summarize, this guide teaches you how to:

• Deploy the application locally to Kyma (based on minikube) or to an actual Kyma cluster
• Connect your service to Kyma as an extension platform and run a scenario
• Extend business applications with Kyma through event-driven, Lambda (serverless) functions
• Bind your application to a brokered backing service
• Add authentication and authorization
• Leverage Kubernetes Self-Healing
• Use tracing and logging support

We would like to hear your feedback. If you face any issues or have any comments while testing Kyma, feel free to report them on GitHub.  

We also invite you to join the Kyma community on Twitter and LinkedIn.

Have fun with Kyma!

When Kyma was introduced to the public a few weeks ago at Google Cloud Next ’18, we talked about the strong partnership that we have with the Knative community. Kyma and Knative provide two complementary sets of building blocks, which together offer a powerful framework and a toolset to build cloud-native solutions on top of Kubernetes.

If you look at the Kyma source code right now, you might wonder why you are not finding many references to Knative. The answer is quite simple. In the last month and a half, the entire Kyma team has been working on restructuring the repositories, making them ready to go open source and removing all internal references and tool dependencies. We've done all of that from a stable branch.  

In parallel to those major changes, we have a fork with Kyma and Knative integrated. It was used to build some first proof-of-concept cloud-native solutions using Knative and Kyma deployed together. The fork is also the basis for our stage demo shown during the project launch. This was our first approach at combining the projects. As both Kyma and Knative are really young and going through a number of changes, some of our design decisions have not been optimal in retrospect. 

During the coming weeks, our plan is to refactor the current Kyma codebase and modularize it. Several functional components can then be installed optionally, which will certainly improve the experience when developing locally using for example Minikube. 

As shared technologies such as Istio are concerned, we're going to provide needed configuration options so that Istio deployed with Knative will also support all Kyma's requirements. 

And finally, we are going to extract some components. For example, we'll extract Kyma eventing and fully integrate it with Knative eventing. We'll evaluate the possibility of contributing the Kyma eventing based on NATS streaming as a Knative compatible eventing implementation to the Knative project. Users of Knative and Kyma will than have the additional option of deciding which eventing implementation to use (e.g. as an alternative to the Knative provided Kafka based implementation). 

Stay tuned for more updates! Remember! Your ideas and proposals are highly welcome. Don't be shy!  

At SAP we typically deal with lots of enterprise software coming from a variety of different vendors. We've helped many of our customers and partners in all industries to model software to their needs and unique business processes. To meet the desire for flexibility, we see a growing demand for openness and modern architecture in this space. That's why we decided to spin the development of our new extension framework, Kyma, out in open source. We’d like to encourage all of you to take a look, get involved and lend a hand to expand Kyma to cover even more exciting extension scenarios.

The ideas and concepts in Kyma result out of long years of experience in customizing different SAP and SAP Hybris solutions. It lets you create serverless applications, mashups and micro services – all running on the underlying Kubernetes+Istio – both serving as the foundation of Kyma. On top we enable developers to quickly code small customization modules and extension apps, interweaved with the business logic of the extended enterprise application.

And then Knative came into the picture. Build from the ground up to support, container-based and cloud-native applications – it provides building blocks for developers to build and deploy container-based serverless applications anywhere on Kubernetes. Sounds familiar, right? All of us at SAP were super excited to see that the Knative dev team has taken very similar technology decisions. It felt like a validation of our Kyma scenarios from one side as well as the technology vision we had in the broader SAP Hybris team from another. From that point on – it was clear that Kyma and Knative are bound to grow together. On our end – we’ve refactored Kyma to leverage Knative configuration, build and serving components already from the on-start. We dropped some of the overlapping components, making Kyma leaner and more streamlined. We got as well all-in involved in Knative, having the opportunity to work with the incredible Google Cloud team.

A quote coming from the discussions, that stuck and made the whole Kyma team at SAP incredibly proud was:

"SAP's extensive enterprise expertise and far-reaching commercial experience made for an ideal partnership as we developed Knative. SAP brought informed customer-driven use-cases to the table, helping us collectively shape the capabilities of Knative to meet the needs of real-world businesses. Knative and SAP Kyma make a perfect fit, and we look forward to the ongoing technical collaboration.” -DeWitt Clinton, Google Cloud

This collaboration gives us the chance to focus Kyma on the higher-level enterprise application connectivity and service consumption scenarios, relying on Knative for all the low-level infrastructure and development scenarios.

We strongly believe in open technologies and open collaboration. Our goal is to join forces with interested parties out there and to build the most flexible extension framework for any SaaS applications to be customized and extended.

Got you interested? Want to get involved? Get in touch with us via Twitter, GitHub or our Slack channel. We would also be very happy if you simply let us know your take on this!

Stay tuned for more updates... and have a great #GoogleNext2018!