At Airspot, we have drawn inspiration from various sources while building Krules. It is difficult to acknowledge and name all the contributors and authors who have influenced our work. However, we would like to share three key resources that have greatly shaped our approach. The first is Martin Fowler's insightful explanation of Event Sourcing. The second is the Event-Driven Architecture Manifesto authored by Kris Van Vlaenderen, which emphasizes the importance of event-driven design principles in building scalable and resilient systems. Lastly, we recommend exploring the Reactive Manifesto, co-authored by Jonas Bonér, Dave Farley, Roland Kuhn, and Martin Thompson, which outlines the principles of reactive systems and guides our development of highly responsive and resilient applications. These resources serve as valuable references for understanding the concepts and principles that underpin our solution.
Today you can think of KRules like and event sourcing tool based on Google Cloud infrastructure. However different technologies have shaped it
Basically KRules is built upon CloudEvent standardization. It provides a common structure for event data, making it easier to exchange and process events across different systems and platforms. CloudEvent enables interoperability and decoupling of event producers and consumers, allowing them to communicate effectively in event-driven architectures.
While KRules has evolved to become independent from Knative eventing, it has been greatly influenced by the concepts and principles behind Knative eventing. The idea of event-driven architectures and the importance of events in triggering actions and workflows have deeply shaped the development of KRules.
While KRules has become independent from the Kubernetes infrastructure, the foundational concepts of Kubernetes have significantly influenced its development. The core principles of scalability, containerization, and orchestration have shaped the design and functionality of KRules.
A common terminology is essential when explaining tech tools. It allows for clear and concise communication, ensuring that everyone understands the purpose and functionality of the tool. We hope with this very short glossary to promote clarity but please feel free to contact us and make questions!
A subject is a unique and distinguishable entity within a system that possesses properties (also known as attributes) and can participate in relationships with other entities. Basically with KRules you have the implementation of a reactive properties store within a CloudEvent eventing system. This implementation can be beneficial for handling state property changes and producing corresponding events. This component act as a concrete implementation of the "subject" component in the observer design pattern. In CloudEvents, the "subject" field represents the subject or the identifier of the event. It provides additional contextual information about the event, helping to identify the specific resource or entity that the event pertains to. The subject field can be used to specify the unique identifier of the resource being affected, such as an object ID, a user ID, a device ID, or any other relevant identifier in the domain of the event. The subject field is optional in a CloudEvent and its usage depends on the specific event and the needs of the event producer and consumer. It can enables more granular event routing, filtering, and processing by providing a specific identifier for the event's subject. Now what we did is to give consistency to the subject field of a CloudEvent using a reactive property store. This means that the subject field becomes a component that can react to changes in its state and ensure the consistency of the events it generates.
Subject state refers to the current information or data associated with that entity at a particular moment. This can include the values of its attributes or the relationships with other entities. In the context of CloudEvent, event sourcing, and reactive programming, the concept of subject state plays a crucial role. CloudEvents represent the occurrence of significant events in a system, and they often include the subject of the event. The subject state refers to the current data or information associated with the subject entity at the time of the event. Event sourcing leverages subject state to capture and store the series of events that have affected the subject's state over time, enabling reconstruction and analysis. Reactive programming, on the other hand, utilizes subject state to react and respond to changes in real-time, ensuring that the system can adapt and process events efficiently. Overall, subject state serves as a fundamental building block for understanding and managing data, events, and interactions in the context of CloudEvent, event sourcing, and reactive programming paradigms.
We mainly think to events that can influence the state of a subject. An event could be something that happens to the entity, such as a user making a purchase, or it could be something that the entity itself does, like a server going offline. When an event occurs, it can result in a change in the entity's attributes or its relationships with other entities, thereby altering its state. In the context of CloudEvent and reactivity, an event represents a specific action or occurrence that can trigger a reaction or response.
Discover the application of Krules: Explore how our platform leverages real-time data, reactive logic, and event sourcing to provide unparalleled automation capabilities and drive business innovation