Golang and Event-Driven Architecture

On March 31, 2022, I gave a talk at Conf42:Golang about using Go in an event-driven architecture entitled "Gopher in an Event-Driven Playground." You can check out the talk here or read along to know more about event-driven systems and how different messaging protocols are used in Go!

What's All the Hype About?

For all of us Go enthusiasts out there, we truly understand the beauty of using Go in applications and microservices because of its lightweight, high performance, and elegant syntax, to name just a few (let the debate start! ).

Realtime Challenges for Audience Engagement

What Is Audience Engagement?

A simple example of online audience engagement could be a Livestream with a host and a chat system for audience members to interact with each other in real-time. Other audience engagement solutions include features such as chat or QAs for participants to communicate while sharing an experience, such as a Watch Party, polls, quizzes, and leaderboards.

Typical audience engagement features

Device and User Presence

One aspect of audience engagement is the ability to know who’s participating in a virtual event or a user’s “presence”. Closely linked to presence is the user’s state, for essential functionality such as indicators when someone is typing a message into a chat window, or the real-time location of a device.

The Real-time Web: Evolution of the User Experience

Over the last few years, companies have used real-time updates to add new experiences and features and increase their market share.

It's now standard to expect a page within an app or browser to update parts of itself without forcing it to refresh. For example, a news page of live sports scores updates with the latest goal scored, or an app shows a change as you track your taxi on a map.

Apache Kafka in Cybersecurity for Threat Intelligence

Apache Kafka became the de facto standard for processing data in motion across enterprises and industries. Cybersecurity is a key success factor across all use cases. Kafka is not just used as a backbone and source of truth for data. It also monitors, correlates, and proactively acts on events from various real-time and batch data sources to detect anomalies and respond to incidents. This blog series explores use cases and architectures for Kafka in the cybersecurity space, including situational awareness, threat intelligence, forensics, air-gapped and zero trust environments, and SIEM/SOAR modernization. This post is part three: Cyber Threat Intelligence.

Blog Series: Apache Kafka for Cybersecurity

This blog series explores why security features such as RBAC, encryption, and audit logs are only the foundation of a secure event streaming infrastructure. Learn about use cases,  architectures, and reference deployments for Kafka in the cybersecurity space:

Event-Driven Architecture: 5 More Myths

In a previous post, I discussed what event-driven architecture (EDA) is and the common claims associated with it. Since EDA is not a common concept and has been around in the industry for over 20 years now (yes that's right!), it has accumulated a lot of claims associated with it and, over the years, some of these claims have been busted as myths or proven as facts.  

In this post, I will discuss 5 more claims about EDA and providing an argument as to whether each is a myth or a fact. Let's get started!

Event-Driven Architectures: 5 Myths

Event-Driven Architecture: Bust or Fact?

Alright, let's face it—there is a lot of content talking about how REST vs messaging APIs and how one is more fir than the other for a microservices architecture design. I wrote a blog post about My journey to learning EDA that highlights what event-driven architecture is. Whether you are new to event-driven architecture (EDA) or have some background with it via dabbling with gRPC, kafka, rabbitMQ, Solace, or whatever messaging API, I am here to share with you 5 claims about EDA that I will be busting or confirming. 

I Will Have to Re-Design My Rest-Heavy Architecture From Scratch To Adopt EDA

MYTH

Advanced event brokers allow for protocol translation within the broker. What does this mean you might ask? Well, it is very common in any software architecture design approach to have a polyglot of protocols and APIs in an application. Whether you are using REST, or different messaging protocols (MQTT, AMQP, Solace, Kafka...etc) you would want your different microservices to communicate with each other. 

ETL and How it Changed Over Time

What Is ETL?

ETL is the abbreviation for Extract, Transformation, and Load. In simple terms, it is just copying data between two locations.[1]

  • Extract: The process of reading the data from different types of sources including databases.
  • Transform: Converting the extracted data to a particular format. Conversion also involves enriching the data using other data in the system.
  • Load: The process of writing the data to a target database, data warehouse, or another system.

ETL can be differentiated into 2 categories with regards to the infrastructure.

WebSockets vs. Long Polling

Sometimes we need information from our servers as soon as it’s available. The usual AJAX request/response we’re all used to doesn’t keep the connection open for this sort of use case. Instead, we need a push-based method like WebSockets, long polling, server-sent events (SSE), or, the more recently created, HTTP2 push. In this article, we compare two methods: WebSockets and long polling.

An Overview of Long Polling

In 1995, Netscape Communications hired Brendan Eich to implement scripting capabilities in Netscape Navigator and, over a ten-day period, the JavaScript language was born. Its capabilities as a language were initially very limited compared to modern-day JavaScript, and its ability to interact with the browser’s document object model (DOM) was even more limited. JavaScript was mostly useful for providing limited enhancements to enrich document consumption capabilities. For example, in-browser form validation and lightweight insertion of dynamic HTML into an existing document.