The world is a highly concurrent and distributed place to live. We have to learn how to decrypt every moment, and to put all pieces together. This is a continuous learning tough. I want to describe the beginning of a journey full of analogies and patterns.

In computer science when it comes to design software we usually start with an abstraction to model and explain a given real-world behaviour and connection between components. This shapes our perception of problems and the solutions to address them. In addition to that, a metaphor can easily describe a countless of scenarios and situations in software (and many other fields).

"Metaphor dictates the way we understand the world" - Metaphors We Live By
By Lynsey Irvine & Peter Storey about the use of the internet by radicals and activists

For instance, Object-oriented programming is a paradigm which approaches a solution with the concept of object. Everything is an object. So a piece of software creates, connects and destroys many object to give us an expected outcome. A car, a house, an invoice, a person, are objects within a software domain.

We can invert that approach: we are systems interacting with others. A system needs a bunch of components to properly work. In real-world, the social iteration is Critical for Mental and Physical Health. Over the years, research has demonstrated the importance of having strong network of support and how the quality of our lives is highly connected. Our personality, our hobbies, our opinions, everything is affected by others. We act because of this. We think because of that. The power of choice is still ours but it is highly influenced by the context around. That's is fine and that's the reason because I believe it's important to be receptive, to be kind, and to live as many experiences as possible, mainly in our youth.

There is a field in Software Engineering which I find very interesting as analogy with the social iteration: Distributed Systems.

A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable. - Leslie Lamport, May 1987
Cluster (source: geralt via Pixabay)

In a high level description, some properties of a distributed system are:

  • Many entities/node/processes trying to solve a problem
  • Partial knowledge
  • Uncertainty

In addition to this a Distributed System should aim to support:

  • Availability / Fault Tolerance: keep operating even though some nodes fail.
  • Scalability: ability to handle increased workload adding more nodes or improving the capabilities of the existing ones. under high workload, the system can add scale and add more nodes.

Doesn't it sound familiar? Our world is a distributed system where we are the nodes interconnected to achieve different goals. If a person fails, the world continue operating. If a person is overwhelm, another person would collaborate to relieve the pressure somehow. There is a thousand of examples as analogy (and it's kind of fun looking for "the right one")

🌎 A world full of Entities

We live and behave as entities looking for something: happiness, pleasure, love, and so on. We need other entities to reach a certain state.

🤷 We know that we know nothing

Even though you have a PhD in Space Physics, our knowledge is limited. If you are an architect, you would likely know everything about constraining factors such as town planning legislation, environmental impact and project budget but maybe you don't know about shock Propagation and Associated Particle Acceleration in the Presence of Ambient Solar-Wind Turbulence (wow 🤯). We know what we should know for achieve our goals, if we don't know, we will learn it.

🔦 There is nothing certain but the uncertain

In a world where there are so many people it's impossible to know the current state at a given point of time about everything. We might know how our friend feel in winter, or what is the most efficient way to travel from Stockholm to Gothenburg, but we can't know what is eating right now an unknown farmer in Perthshire, Scotland.

So the metaphor is bi-directional and funny: We use the Software to explain the real world and also we use the real world(s) to explain the Software ∞.

Global Population Density by @undertheraedar

⚡️ Reacting to an Event-Driven World

As the same way we find patterns in nature which can be modelled mathematically we can find patterns in software to describe the social behaviour. Let's imagine that we live in a distributed (spherical) world where every single person is an autonomous "process" or "service" running in a huge space and a replicated version of us is doing the same in another dimension most likely 😅. We can model this world as the main system with billion of people as interconnected nodes.

This system might be many things: a payment platform, a marketplace, a social network, and so on. The main goal of the world as analogy is not just one, but a plenty: Increasing access to water, Improving energy efficiency, Increasing access to education and so on. That makes the world a very complex system, huh?

Events, Events, Events


Some philosophers said that life is all about events and decisions. We react to events in a distributed, highly concurrent, and data-intensive world. We live in an event-driven social architecture and we need to protect ourselves in order to recover quickly and stay responsive in the face of failure.

In Software Engineering, an event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices. An event is a change in state, or an update, like an item being placed in a shopping cart on an e-commerce website. Events can either carry the state (the item purchased, its price, and a delivery address) or events can be identifiers (a notification that an order was shipped).

Event-driven architectures have three key components:

  • event producers: publish an event to the router.
  • event routers: filter and push the events to consumers.
  • event consumers. process the event to trigger one or more actions.

Producer services and consumer services are decoupled, which allows them to be scaled, updated, and deployed independently.

This a perfect analogy to explain how a chain of events in my life have triggered my decision of moving abroad.

🎶  Should I Stay or Should I Go?
🛫  Why did I make the decision to move aboard?

The answer for every decision: Events, Dear Boy Events (I strongly recommend this talk by @tlberglund).  

Looking back to look forward

Two years ago I was moving from Argentina 🇦🇷 to Sweden 🇸🇪. Back in the days the decision was pretty easy. No child and a beautiful wife in the same mood and a new adventure of a few years ahead. Of course I knew I would miss my family and friends. I really do. Two years away makes us to reflect and get a better perspective about everything.


To be fair, the decision was a long process. My days at University plus my first jobs in Software consolidated my decision. I walked through System Engineering with ups and downs. I was excited in my first weeks at the University: maths, algebra, algorithms. So new, so great. At that time Java 5 was the trend (applets!!!) in programming. I remember 2 things that caught my attention about Java: first, I loved that coffee logo because at that time I drunk so much coffee to keep me up preparing exams and second, my dad had a Newspaper and Magazine Store and I saw the Java logo everywhere: magazines, 3.5 inch diskettes, hats, and so on. It was a strong connection. One day I was reading some notes before a class in the main hall at the University when I saw a poster on the wall: "Java Course" something. I signed up right away as a spontaneous and associative act. It turned out the institution called me back and I achieved a place to learn Java Programming. I was in my first month in System Engineering and I was learning Java for free!
I got my first skills in Java programming which injected me enough enthusiasm to look for my first "official" Job in Software. I received several offers. First clue that the market was getting a hot thing. I joined a company in a Research Market coding polls. That was the entrance to this world.

🤔 But, what did it push me to study System Engineering?...

I spent an important part of my youth playing football, with friends just for fun but also in amateur teams. I met a ton of people there. Some of them became in truly friends. At that time I met an older guy who played in same club, but different level. It turned out we also shared same Secondary school. He was finishing whereas I had one year left. He had decided to go for a degree in System Engineering. He was really convincing right in time when I was struggled in thoughts about my future. Classic struggling at the end of the secondary school. That moment when you want to be an Economist, an Architect, a Writer, a Doctor, to play the guitar every day and every night or just follow a trending career because everybody does. I didn't know what I want but I felt with energy to keep studying. I knew that I could skip the University, I've never felt like a social mandate or a burden. Maybe the fact I saw my uncle enjoyed his profession encouraged me. I don't know.  The thing was that in my case it was a long talk with a friend which made me decided to follow Engineering.

"You can’t connect the dots looking forward; you can only connect them looking backwards", Steve Jobs - Stanford University in 2005.


🤔 But, what did it push me to even have that conversation?...

Secondary school gave me a bachelor's degree in economics. The only software I used was Office, DOS. At that time I had another small a formation on Economy a Something happened before that conversation. It was before that when during secondary school I helped my dad to sell newspapers on weekends and a customer traded computer magazines for teaching me computer basics. My first lines of code. It was awesome. The feeling of waiting the startup of the computer for minutes!!, I can't believe that today I think it's annoying a mac OS's update (my patience and tolerance have been changing too). I found out the computer was so powerful (it is, but it's not a silver bullet). I remember my fear of not getting a proper job and the certain of whether I really knew about anything about computer every problem would be solved (now I know that's not true 😄).

🤔 But, why did I even accept my first computer classes?...

When I was a kid and I lived with my parents I had a neighbour: The Magician. I remember my joy when he invited me to play Duke Nukem on his computer, or to use a dial-up internet access (too noisy) or to code a game in QBasic. I would say those events triggered my first computer classes which triggered my career choice.

Everything event has shaped my path to move abroad. Probably there are other events in between, but those are the ones which remain fresh in mind.
I will never know what would have happened if The Magician did not exist. In fact I noticed there were events which pushed him as well. This is endless.

Hamilton: "Every action's an act of creation!"
Jefferson: "Every action has it's equal opposite reaction."
Hamilton Musical

I like the idea of thinking we are reactive systems. We react to events which are in constant jumping around us. We consume and process them.

So, today I can highlight and sort the events that made me to accept a job and life abroad:

  1. My dad as distributor of Software magazines.
  2. The customer as consumer of Software magazines.
  3. The customer as professor of Software basics.
  4. My neighbour, The Magician.
  5. The Football Player introduction to System Engineering.
  6. Java for Free.

The fact we are facing more and more challenges around the world should be enough to encourage us to act as Reactive Systems and be more robust, more resilient, more flexible and better positioned to meet modern and global challenges.....and be kind too.

We can start following these 8 principles:

🙌 I. Stay Responsive

Always respond in a timely manner.

Even when I failed I continued. This consistent behaviour builds confidence, and encourages further actions.


🤷‍♂️ II. Accept Uncertainty

Expect things to go wrong and design for resilience.

As soon as I took that plane, I entered a vast and endless ocean of non-determinism. It is a scary world of uncertainty in which everything could fail.

💥 III. Embrace Failure

Expect things to go wrong and design for resilience.

At University I used to be one of those "bad" students to be honest. It took me lots of years above the average. I really sat down to study but I got distracted by so many things. Now I realised every failure was good. For instance, the decision to live abroad was a shared decision of course. My wife had the perfect job in the perfect timing. This job (in a different event broker) put her next to me in this journey. The tiny failures gave me time and put me also in a perfect job to prepare to go forward.

🙋 IV. Assert Autonomy

Design components that act independently and interact collaboratively.

Even though I was immersed in maths, physics and algorithms, I jumped into a new activity, I act totally free when I signed up to learn Java programming. Just connected dots.

🏋️ V. Tailor Consistency

Individualize consistency per component to balance availability and performance.

Everything is changing around us, but it's important to focus on small units of consistency. I started to look for a job abroad once I got graduate. This was a learning process. I started my path doing so many things at the same time and it was hard to complete something, but I finished (at least the University step) being more consistent in my goals.

VI. Decouple Time

Process asynchronously to avoid coordination and waiting.

We process events asynchronously, always. Even in a face to face conversation. Every event I mentioned above was processed in a async fashion for me. It took me some time to put all pieces together. To wait should mean to process.

🚲 VII. Decouple Space

Create flexibility by embracing the network.

Definitely I became more resilient living abroad. I need to distribute the parts across space. Once distributed, I get a better perspective and a single abstraction for all interactions with my peers. I miss everyone every single second but to miss is good too. This capability to fail-over is essential to avoid our disruption.

🏂 VIII. Handle Dynamics

Continuously adapt to varying demand and resources.

There is not better example than: weather and different language. I don't speak Swedish yet, but fortunately English is well-distributed in the country. The darkness in winter is something quite different and interesting and when I found myself having the Vitamin D in breakfast. I had to adapt.

Sea Monsters (source: Wikipedia)

Conclusion


Further application of Reactive principles will make our diverse and distributed civilisation more robust. What was the reason behind every decision? The Convergence of Events. We live and react to events constantly. Every single event matters and they shape us. We should aim to decrypt them and put the pieces together. It's a process.

All things change: you step back into the river, the river is different, so are you. Centrality of change. You think about how things change, not about what things are. There is not a world out there. There is a desert and only events that happen to us. We act as event processor in the universe.

References

The Reactive Principles :: The Reactive Principles
IBM Garage Event-Driven Reference Architecture
This project represents the body of knowledge around event-driven architecture and can be considered as a live book, we are writing from our consulting engagements
Reacting to an Event-Driven World - Confluent
“Kafka Streams, Apache Kafka’s stream processing library, allows developers to build sophisticated stateful stream processing applications which you can deploy in an environment of your choice.
What is event-driven architecture?
Event-driven architecture is a software architecture model for app design. The capture, communication, and processing of events make up an event-driven system.
Event-Driven Architecture
Event-driven architecture is an integration model built around the publication, capture, processing, and storage of application or service events.
Advantages of event-driven architecture