Processes, Rules and Events: kogito

Showing posts with label kogito. Show all posts

Friday, April 24, 2020

Virtual Red Hat Summit 2020, April 28-29

Next week Red Hat Summit 2020 will be held, not in San Francisco as we were hoping, but as a virtual event. While this unfortunately won't give us the possibility to meet in person, a lot of the keynotes and breakout sessions will be held online.

Virtual Red Hat Summit is completely FREE, so if you haven't done so yet, register today!

Below is an overview of various sessions around business automation. So if you're looking for the latest news on Kogito, our next gen cloud-native business automation toolkit, or how to leverage Red Hat Process Automation Manager and Decision Manager for use cases that involve microservice orchestration or machine learning, or to hear from our customers. But take a look at the full agenda as well.

There will also be an opportunity to come and chat with us in the community area. After signing in, click Explore and open up the "Middleware & cloud applications" Community Central chat room to ask questions! Or you can just join our KIE chat channels we announced recently anytime.

Below is the list of presentations around business automation that I am aware of !

The state-of-the-art of developer tools to build business-intelligent apps for RHPAM v7 and Kogito
Eder Ignatowicz (Red Hat), Alex Porcelli (Red Hat)

Empowering Amadeus’ competitive advantage with cloud-native decision making on Quarkus
Matteo Casalino (Amadeus), Giacomo Margaria (Amadeus), Mario Fusco (Red Hat)

Modern business workflows as microservices: How we won with Red Hat Process Automation Manager
Mauro Vocale (Red Hat), Giovanni Marigi (Red Hat)

Why building intelligent cloud-native business applications is easier with Kogito
Kris Verlaenen (Red Hat)

Cloud, sweet cloud: Feeling at home with serverless decision making using Kogito and Camel-K
Daniele Zonca (Red Hat), Edoardo Vacchi (Red Hat), Luca Burgazzoli (Red Hat)

Integrating scalable machine learning into business workflows
Rui Vieira (Red Hat)

Solve the unsolvable: Why artificial intelligent systems can solve planning problems better than humans
Satish Kale (Red Hat), Geoffrey De Smet (Red Hat)

Transforming decision automation to be cloud-based and FaaS-like at BBVA
Antonio Valle Gutierrez (BBVA), Beatriz Alzola (BBVA), Marcos Regidor (Red Hat)

This is available on demand so no specific timing.

Wednesday, April 22, 2020

Kogito 0.9.1 released

We are glad to announce the Kogito 0.9.1 release is now available! This goes hand in hand with the Kogito Tooling 0.3.1 release.

From a feature point of view there are only minor changes compared to 0.9.0, but on top of bug fixing we have also spent quite some time on following areas:

Kogito documentation is now available
Kogito website was updated with updated getting started and community sections
Kogito examples were updated and improved

This is a milestone for us as we wanted to bring an end-to-end story and focus on our documentation and getting started experience to help you with your first steps on Kogito. Take a look and let us know if you have further questions or recommendations!

New to Kogito?

Check out our website https://kogito.kie.org/

Click on the "Get Started" button.

All artefacts are available now:

Kogito runtime artefacts are available on Maven Central
Kogito examples can be found here
Kogito images are available on quay
Kogito operator is available in the OperatorHub in OpenShift
Kogito tooling 0.3.1 artefacts are available here

As announced last week we've also introduced a chat channel where you can reach the core team or interface with the community, so hope to see you all there !

Detailed release notes for 0.9.1 in JIRA can be found here.

Thursday, April 16, 2020

New community channels on Zulip Chat

We're happy to announce the immediate availability of a new public channel for all projects under the KIE umbrella, i.e. the Kogito, Drools, jBPM and Optaplanner communities !

Zulip Chat channels: https://kie.zulipchat.com/

Inside our KIE organization you will find various streams where you can follow any of the topic discussions, create your own topic to ask a question or even help out others. Since most of the developers use this for their day to day discussions as well, you will find a lot of experts there, and a ton of information.

Please join our community of Kogito, Drools, jBPM, and OptaPlanner experts, hang out, learn and become part of the next generation of cloud-native business automation!

Wednesday, November 20, 2019

Kogito deep dive video from Devoxx

This year at Devoxx Belgium, Maciej, Edoardo and Mario held a 3h deep dive on Kogito. Since Devoxx is so awesome to share the recordings of all their presentation online, wanted to give everyone the opportunity to go and watch this!

I also had the opportunity to help out at the Red Hat booth for 2 days, and it was a great opportunity to sync up with a lot of people and do some Kogito evangelization. And was there live for the big announcement of Quarkus doing its 1.0 release !

Wednesday, September 18, 2019

Etymology of Kogito

After writing up an introduction to our Kogito effort, it seems people are interested in hearing a little but more about the name, where it comes from, what the logo means, and (what seems to be the most important question) how to pronounce Kogito? Yes, there even was a JIRA issue [KOGITO-284] opened to address this issue!

First, the name Kogito itself comes from:

"Cogito, ergo sum"

a Latin philosophical proposition by René Descartes usually translated into English as "I think, therefore I am" [Wikipedia]. So Kogito simply means "I think", and refers to how users are encoding business knowledge using various formats (processes, rules, constraints, etc.). The 'c' was replaced with a 'k' as a reference to Kubernetes, our target cloud platform, and Kie where the k stands for knowledge.

"Kogito, ergo automate" therefore means, "I think, therefore I automate" and refers to the use of business automation to encode business knowledge.

Our logo is a reference to Odin, the Norse God that gave up an eye for wisdom [Wikipedia].

“According to mythology, Odin ventured to the mystical Well of Urd at the base of the world-tree that holds the cosmos together. The well was guarded by Mimir, a shadowy being who becomes all knowing by drinking the magical waters. Odin asked for a drink and Mimir replied that Odin must sacrifice an eye for a drink. Odin gouged out his own eye, dropped it into the well, and was allowed to drink from the waters of cosmic knowledge.”

Finally, how do I pronounce Kogito? Since it comes from the Latin phrase "Cogito, ergo sum", the obvious first question could be, how do I pronounce that? As it turns out, not an easy question to answer, but in the end the Italians in our team proclaimed this to be the only correct pronunciation:

[ˈkoː.d͡ʒi.to]

so that's with the emphasis on the first syllable, and the 'g' pronounced as 'dji', or (if you're not skilled in phonetic language at all like me ;)) just listen to the video below:

Some good news though, because it seems no mortal person is able to consistently pronounce it this way, other pronunciations are completely fine too!

Monday, September 16, 2019

An intro to Kogito

The KIE team has been working for quite a few months on the Kogito project, our next-gen solution leveraging processes and rules for building intelligent cloud-native applications.

What are we trying to achieve? Basically, when you as a developer or team are trying to build intelligent cloud-native applications, Kogito wants to help you with that by letting you use processes or rules in this context in a way that matches that ecosystem (!). Kogito is focusing on make it as easy as possible for developers to turn a set of processes and/or rules in your own domain-specific cloud-native (set of) service(s).

This is a continuation of the efforts of the KIE team (including the Drools, jBPM, Optaplanner and AppFormer teams) to offer pure open-source solutions for business rules, business processes and constraint solving. The KIE team however decided to have a new effort targeting specifically this goal, for the following reasons:

Technology-driven: As you will see below, there's a lot of great technology available for building cloud-native applications, but to be able to fully leverage these technologies in the context of business automation, we had to make a few radical changes.
Focus and innovation: We wanted to focus specifically on what is needed to build next-gen cloud-native applications, and how you can leverage processes and rules in this context. This allows us to offer something that really fits this ecosystem and doesn't bring in additional baggage that isn't relevant.

So while this effort builds on years of experience and battle-tested capabilities, this also allowed us to leave some baggage behind and focus 100% on the problem at hand.

Kogito, ergo cloud

When you're building cloud-native applications, there's a lot of great technology out there (some of it you're probably already using). Kogito is closely aligned and leveraging these technologies, so you can build highly scalable cloud-native services, with extremely quick startup times and low footprint. Picking up some of these technologies and truly taking advantage of them sometimes required quite radical changes (so this definitely not a lift-and-shift of our existing engines but built from the ground up).

For example:

Kubernetes is our target platform for building and managing containerized applications at scale.

Quarkus is the new native Java stack for Kubernetes that you can leverage when you build Kogito applications and it's a game changer. But don't worry, if you are building your applications with Spring Boot, we will help you with that as well!

GraalVM allows you to use native compilation, resulting in extremely quick startup times (a native Kogito service start about 100x faster ~ 0.003ms) and minimal footprint, which is almost a necessity in this ecosystem nowadays, especially if you are looking at small serverless applications. If you're interested in what's behind this, I would recommend to read Mario's blog about this.

Building serverless applications? Leverage Knative and Kogito together so your applications can scale up or down to zero based on the need.

Kogito applications behave like any other service you build, so you can instantly leverage technologies like Prometheus and Grafana for monitoring and analytics with optional extensions.

Internally we leverage quite a lot of other core middleware technogies like Kafka, Infinispan, KeyCloak, etc. This means we take care of setting these up (on demand, for our internal messaging, persistence and security requirements for example) but we strongly encourage you to start leveraging these technologies for your own use cases as well.

Kogito, ergo developer

We want to make the life of developers easy, by offering them instant productivity and making sure we integrate well with how they are building their applications. So rather than asking developers to come to us with their requirements, we are coming to them !

The tooling required to build your processes and rules needs to be closely integrated with the workflow the developer is already using to build cloud-native services. Therefore we have spent a lot of time on allowing this tooling to be embeddable. For example, we just released the first alpha release of our VSCode extension (see video below, credits to Alex) which allows you to edit your processes (still using BPMN 2.0 standard) from within VSCode, next to your other application code. We're working on a similar experience for Eclipse Che.

Instant productivity means it should be trivial to develop, build and deploy your service locally so you can test and debug without delay. Both Quarkus and Spring Boot offer a dev mode to achieve this, Quarkus even offering live reload of your processes and rules in your running application (extremely useful in combination with the advanced debug capabilities).

Once you're ready to start deploying your service into the cloud, we take advantage of the Operator Framework to guide you through every steps. The operator automates a lot of the steps for you. For example, you can just give it a link to where your application code lives in git, and the operator can check it out, build it (if necessary including native compilation) and deploy the resulting service. We are working on extending this to also provision (on demand) more of the optional services that you might need (like for example a KeyCloak instance for security, or Infinispan for your persistence requirements). We also offer a Command Line Interface (CLI) to simplify some of these tasks.

Kogito, ergo domain

Kogito has a strong focus on building your own domain-specific services. While we hope you can leverage our technology to significantly help with that, we want developers to be able to build the service they need, exactly how they want it. As a result, the fact that Kogito is leveraged to do a lot of the hard work is typically hidden and your service exposes itself as any other with its own domain-specific APIs.
To achieve this, Kogito relies a lot on code generation. By doing so we can take care of 80% of the work, as we can generate a domain-specific service (or services) for you, based on the process(es) and/or rule(s) you have written. For example, a process for onboaring employees could result in a remote REST api endpoints being generated that you can use to onboard new employees or get information on their status (all using domain-specific JSON data).

Additionally, domain-specific data can also be exposed (through events or in a data index) so it can easily be consumed and queried by other services.

Architecture

When using Kogito, you're still building a cloud-native application as a set of independent domain-specific services, collaborating to achieve some business value. The processes and/or rules you use to describe the behavior are executed as part of the services you create, highly distributed and scalable (no centralized orchestration service). But (by using this additional compilation step) the runtime your service uses is completely optimized for what your service needs, nothing more.

If you need long-lived processes, runtime state can be persisted externally in a data grid like Infinispan. Each service also produces events that can be consumed. For example using Apache Kafka these event can be aggregated and indexed in a data index service, offering advanced query capabilities (using GraphQL).

What's coming next?

At this point, Kogito 0.3.0 is the latest release (from August 23rd), but we have much more coming on our roadmap before our 1.0.0 release which is targeted towards the end of the year.

Get started

And now I believe you are ready to give it a try yourself, so please do and let us know! You can start with building one of the out-of-the-box examples, or by creating your first project from scratch. Follow our getting started documentation here ! You will see you can build your own domain-specific service in minutes.

Or if you want to watch a small presentation (and demo!) from Maciej, check out his latest DevNation Live talk here.

Processes, Rules and Events