Imagine a banking software application. The Events are obvious: deposit, withdrawal, interest, name and address, contact info, mortgage application, mortgage approval, mortgage rate, mortgage payment, cheque cleared, cheque insufficient funds, etc., etc. Over time, the immutable event records will accumulate for each active account. It is always possible to calculate the account balance by sorting and calculating these records. Nothing is missing. It does not matter how many other accounts exist, since accounts are independent and isolated.
Functions (aka: Microservices) are required to format and publish the Event records. Other Functions create any sort of Report that may be desired, exclusively by analyzing the Event Records in the Archive. There is no need for any other Functions or programs.
We focus on learning: “What is of interest†in the space. Each Event becomes defined by the fields of an Event Record. Change orders will arrive and will require new Records and new fields. This is the normal evolution of the application. It is “living softwareâ€.
As described above, the only logic that is needed is the code that formats and published the Event Records, plus the Reports.
Change orders will arrive and will require new Records and new fields, and/or modifications to the logic in the Functions. This is the normal evolution of the EventzApi application. It is “living softwareâ€.
The Write-Once-Read-Many (WORM) Archives of the immutable Event Records are safe. After a crash, we simply restart the Functions. There is no local data that is at risk of being lost.
EventzApi is Reactive Functional programming. There are no assignment statements and (almost) no side effects.
When computer resources were expensive, we needed Databases. But those days are over and we are better served by immutable tuple archives of event records. It is time for new methods.
You are not Netflix so scaling up is probably not huge. The record count can rise, but we have high throughput and large capacity. Each user brings the computing power that is required to service his needs. So scaling is self-provisioned. “Bring your own computer.â€
Yes. EventzApi applications tend to run with no central servers. All the action is at the edge.
All the logic is in the Functions (aka Microservices). All the data is in the immutable Event Records. The Stakeholders can and will define the Events and the Records required in their system. And they can and will define how the Functions will need to calculate the fields of each new Event Record. This process is completely different from Scrum.
The specification is basically, “Publish an Event Record with these fields when this event happens.â€
Testing is done using a reference Archive and test Event Records which test the edge cases. There is a correct result set of published ERs which means the test suite passes. This process can easily be automated and run anytime. This may qualify as TDD.
All we do is publish and subscribe using Event Records. If we can turn off all other network ports then we dramatically reduce our attack surface.
We like to build GUIs for a browser running HTML5, bootstrap, CSS, JavaScript. This separated the GUI from the logical Functions, which is a welcome separation of concerns.
The Eventz Functions can be written and tested using low to medium skills. The work is not demanding, because the design is pre-determined in the Function description documents. We only require “code that fits in my headâ€. This is a major advantage!
This was a goal of the original Agile Manifesto in 2001 and it has remained elusive. Happily, the Eventz SDLC gives control to the Stakeholders, not the programmers.
There is nearly no need for a central Server to execute application code. The Functions can reside on the network Edge.
Brooks’ Law states that more devs make a late project later. But in Eventz the devs are in independent silos, and do not conflict. The specification work is done by stakeholders working the process of the SDLC diagram.
Progress happens as Event Records are identified and defined with their fields. Then the Functions are the logic which forms and publishes these event records. The Functions are programmed and tested and then they go on the shelf as fished work. We expect changes to be made to the Event Records and their fields, so this maintenance work needs to be done. In all of this, progress is steady.
Projects that have gone off the rails can always be recovered. How? By analyzing the Event Records and correcting any errors that are found. Then process the old Archive into records in the new improved Archive.
We used Eventz to build a payroll system for a collective agreement. This succeeded. So we do not see any ceiling for Eventz applications.
Who is on the original Developer team? What is the role of the programmers? Who are the key stakeholders – business staffers who understand their events, or programmers? The documentation is the dictionary of Event Records and their fields and versions. This stays current as time passes.
State is expressed in Event Records. Say my payroll hours must gain manager approval before my cheque is processed. Approval takes the form of an Event Record published by the manager’s terminal. This is a change of state.
Early adopters are using Eventz. We have built a few reference applications. Eventz is quick and inexpensive to try, perhaps in a skunk works?
The documentation is the dictionary of Event Records and their fields and versions. This stays current as time passes.
The Archive of Event Records is the 24/7 log file for the application. If we are hunting a bug we are free to put a Function on high watch so it will publish more granular log messages.
Projects that have gone off the rails can always be recovered. How? By analyzing the Event Records and correcting any errors that are found. Then process the old Archive into records in the new improved Archive.
Eventz is an excellent choice for Internet of Things. IoT messages can be formatted as Event Records to be published to the Archive. Other Functions can subscribe to these ERs and take some corrective action as required by their algorithm. The complete history of every IoT ER is safe in the Archive for further study anytime in the future. One of the challenges of IoT is to trigger some corrective or responsive action somewhere in the business. This is a perfect fit for Eventz.
Event Records are Data stored in the Archive in near real time. Information is distilled from many ERs to draw some conclusion or trigger some action. Separating Data from Information leads to “A delightful separation of concernsâ€.
A bug in Eventz amounts to an incorrect ER. Because the complete history of ERs is logged in the Archive, it is generally possible to diagnose the conditions that triggered the bug. So it is possible to identify the flawed Function, and then repair it.
Design competitions are always possible in Eventz. This is the process of programming multiple Functions for the same task, and then comparing them for speed and accuracy.
Orchestration is the business of launching the required Functions and monitoring their health in production. Eventz has a System Monitor to do this.
Whenever an Event happens it is important that an ER be published in near real time. If this is not done, then Events will be missing from the Archive and this can cause troubles.
We believe that Eventz is a good choice for critical systems like nuclear reactors. This is because the Archive exposes every Event to system-wide analysis. So we can create multiple-vote systems, for example.
TD happens when code is created quickly to meet a time deadline, but not every edge condition is handled, for example. More time is required to do a good job. Often this TD accumulates and is never paid back. Eventz avoids TD because Functions are small in scope so “the code fits in the programmer’s head.†Edge conditions are specified in the test records that accompany the specification. Functions are not accepted until they pass all their tests. In addition, we can follow up with an improved version anytime in the future. So TD is not inevitable in Eventz systems.
Any Eventz Function can be swapped at any time. If a bug is found, it is easy to roll back to the previous Function. The resulting ERs are always in the Archive.
Most systems have startup data that must be processed into the Archive as ERs. This typically means exporting from the old database in CSV form, say, and then converted into ERs as required in the Eventz system. Errors can be detected in Production and the original ERs can be updated. So the data can converge to high accuracy.
The Eventz Functions can be written in your language of choice. We have used both Python and JavaScript. What matters is the Event Records that are published, and it matters not what language was used to form and publish the ER with its prescribed fields.
When you are tracking an elusive bug you can publish extra ERs that are debug trace records. This can give you a fine-grained view of the operation of your code.
When we analyze our computing system using Event Records, the mystery of IT seems to drain away. The business stakeholders working with the SDLC gain a high degree of confidence in their creation.
Eventz is highly accessible to every stakeholder. This encourages high participation and pride-of-authorship. Reports can be created from the Archive by individuals using simple programs. It seems that a high percentage of “change orders†is for Reporting.
Eventz is highly accessible to every stakeholder. The concepts are simple so the learning curve is short.
Eventz is open source. No more fees need be paid for the large commercial databases.
The large commercial databases tend to require consultants to make modifications, and they never leave. Eventz avoids this syndrome.
With Eventz development it is possible to start Greenfield projects. This is because the Events in your application space are your own and are well understood by the business stakeholders. There is no need and no benefit to starting with a commercial off the shelf (COTS) software package.
BBoM is thought to be universal, inevitable and inescapable in software today. Can Eventz be exempt? We believe it is exempt for these reasons:
1. The documentation stays current in the form of the Immutable Archive and the definition of each Event Record ever published.
2. The only data persistence is the Archive.
3. The only programming is the Functions which publish the ERs.
4. The strategy is always clear and explicit, and enforced.
5. There are no key man dependencies.
6. Updates are incremental
Daniel Bohm explains the difference.
http://davidbau.com/archives/2003/11/12/encapsulation_or_representation.html
1. The Immutable Archive of Event Records is data representation.
2. Databases are data encapsulation.
Eventz systems expose a small attack surface because:
1. AMQP publish & subscribe messages are the only authorized network traffic and this can be enforced using custom firewalls.
2. There is no database used.
3. A Web browser is optional.
4. We can close most ports.
We aim to minimize dependencies.
Eventz is highly accessible to every stakeholder. The concepts are simple so the learning curve is short.
An important goal of the 2001 Agile Manifesto was to remove the barriers between Business and Programmers. We believe that Eventz achieves this goal! The main stakeholders are the business staffers who identify the Events that happen in their business space. This is their domain and does not require programming skills.
The documentation stays current in the form of the Immutable Archive and the definition of each Event Record and their fields and versions ever published.
Maybe not, because all the tasks are simple, so nobody is "punching above their weight". The Business stakeholders need to identify the events in their space, and specify all the data fields that will be needed. If some fields are missed, they can always be added later. Programmers need to create the specified ERs containing the required fields, using the Archive of previously published ERs plus the new Event data. This can normally be done using basic Python operators.
https://www.youtube.com/watch?v=6vuGRu_YuJQ&feature=em-uploademail
Essential complexity is just spreadsheet arithmetic. Accidental complexity is all the rest of the stuff.
“I don’t know of any way to sustainably remove accidental complexity.â€
https://www.youtube.com/watch?v=DtRy79jIsS8 at 8:00
55. Who recommends event-driven systems?
Jonas Bonér — Designing Events-First Microservices
https://www.youtube.com/watch?v=1hwuWmMNT4c
Jonas Bonér — How Events Are Reshaping Modern Systems
https://www.youtube.com/watch?v=ycxvmOKDHMQ
Hugh McKee — 7 Reasons why your microservices should use Event Sourcing & CQRS
https://www.youtube.com/watch?v=wBvH7foXXUY
Allard Buijze — Pragmatic Event-Driven Microservices
https://www.youtube.com/watch?v=vSd_0zGxsIU
David Schmitz — Event Sourcing You are doing it wrong
https://www.youtube.com/watch?v=GzrZworHpIk
Greg Young — Design Patterns: Why Event Sourcing?
https://www.youtube.com/watch?v=rUDN40rdly8
Martin Fowler — Making Architecture Matter
https://www.youtube.com/watch?v=DngAZyWMGR0
Eberhard Wolff — Event-based Architecture
https://www.youtube.com/watch?v=Ecg7lvvm8aU
Ranga Karanam — Microservices Architectures: Event Driven Approach
https://dzone.com/articles/microservices-architectures-event-driven-approach?edition=492291&utm_source=Daily%20Digest&utm_medium=email&utm_campaign=Daily%20Digest%202019-06-21
Vinicius Gomes — When Microservices Meet Event Sourcing
https://www.youtube.com/watch?v=cISNDnwlSgw
Martin Kleppmann — Event Sourcing and Stream Processing at Scale
https://www.youtube.com/watch?v=avi-TZI9t2I
Greg Young — Event Sourcing is actually just functional code
https://www.youtube.com/watch?v=kZL41SMXWdM
Jan Stenberg — The Importance of Event-First Thinking
https://www.infoq.com/news/2019/02/event-first-architecture?utm_source=infoqEmail&utm_medium=editorial&utm_campaign=ArchitectNL&utm_content=03292019
Copyright @ 2025. EventzAPI All rights reserved.
