Skip to content
This repository has been archived by the owner on Nov 15, 2022. It is now read-only.

The Next Big Thing(s)

Jump to bottom
Shubham edited this page Feb 21, 2018 · 2 revisions

Kedge is in a pretty good shape right now, and from a project point of view, I think it's time to integrate Kedge where it makes sense, instead of adding features to the project right now.

There are some integration points where "it makes sense", but we've not yet formed end-to-end user stories around them, let's do that.

Integration points -

  • Helm - Helm is a great tool for managing applications on Kubernetes, it performs installs, rollbacks, updates, etc flawlessly. Helm has nothing to with declarative application definitions, you need to write your own big blogs of YAML and take to Helm, and then Helm will take it from there. Kedge does application definition pretty well, and it has nothing to do with packaging and managing applications. Both tools and concepts complement each other to solve a broader problem for a developer and an operator from end to end. Kedge Helm Plugin is a (PoC) effort in this direction - https://github.com/kedgeproject/kedge-helm-plugin If done right, using this plugin, a user should be able to get their concise application definition in Kedge, and deploy on Helm. This is a huge value addition and bridge between developers and operators.

  • Eclipse Che in Fabric8 and OpenShift.io - Fabric8, upstream for OpenShift.io, currently supports mainly Java stacks and workloads like Vert.x, Sprintboot, etc, which are pre-configured in the Eclipse Che environment. The moment you click on "Run", your application is deployed. But there is no support for any other language stack, even thought Eclipse Che has support for different languages like Python, etc via LSP integrations already in place. We know that underneath, Eclipse Che deploys on the OpenShift project allocated to the user using pre-defined OpenShift templates, and this limits the platform wrt multi-language support. Upon integrating with Kedge, you can either Kedge commands in your Makefile or directly in the "Run" command to deploy your microservice definitions (already committed in your source code and hence available in Eclipse Che) on the OpenShift cluster. BOOM! We now have support for multiple microservices and 10 different languages in Fabric8 and OpenShift.io. Status: This is very much doable but I'm yet to record a PoC for this. All that I did during hacking in this was to install oc and kedge binaries in the Che workspace, and then did an oc login to my OpenShift cluster running OpenShift.io, and then modified my "Run" command to kedge apply -f app/. Now each time I clicked on Run, my entire application stack was deployed to OpenShift along with my code changes.

  • fabric8-maven-plugin - fabric8-maven-plugin does a lot of things that Kedge does, like building images, pushing images, deploying to Kubernetes/OpenShift clusters. It has a set of pre-defined Kubernetes/OpenShift YAMLs for certain Java stacks that it supports. Kedge can very much lower the complexity of this tool by integrations.

  • Kedgify - https://github.com/kedgeproject/kedgify/ The most important thing for Kedge right now is to get user adoption. What better than a tool that takes any Kubernetes and OpenShift definition and converts it a quarter of the original size in Kedge. How can you showcase the value addition in a better way than this. In half a second, 2000 lines of Kubernetes YAML are now less than 400 lines with 100% integrity and 0% lossy conversion. Kedgify does exactly this and takes away the manual toll of rewriting applications to Kedge by hand. Imagine moving teams after teams in minutes to Kedge. Let's do this for the blessings we'll get.

Clone this wiki locally