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!