Nat  Grady

Nat Grady


Serverless Diary: Your Way to A Successful Event-Driven Architecture

I. Introduction

Carrying on from where I left sharing my experience of implementing microservices in a serverless style in my previous blogs, the focus of this blog is to understand how to approach event-driven design. This blog takes the understanding of core principles of event-driven architecture and demonstrates how to use them in your serverless architecture.

II. What and Why of Event-Driven Architecture

Event-driven architecture (EDA) can be seen as a way of wiring all your microservices together. In this architecture, a microservice publishes an event when something notable happens, such as when it updates a business entity. Other microservices subscribe to those events. When a microservice receives an event it can update its business entities, which might lead to more events being published.

In the last decade, event-driven architectures have gained more popularity as more organizations and businesses have moved to the cloud. In the context of serverless cloud-native architectures, where the goal is to move to more managed services without worrying about manual intervention for scaling your infrastructure, I find event-driven architecture usage more compelling because of the following benefits:

  • Automatic Scaling — Since individual components in your serverless landscape are capable of auto-scale. Bottlenecks due to increased load or traffic are identified and taken care of automatically by the virtue of managed service usage, wherein only your affected component auto-scales and not your entire infrastructure.
  • Asynchronous style Communication — avoids all bottlenecks caused by synchronous architectures where an increase in traffic is proportional to the responsiveness of your application.
  • Decoupled — Each microservice/component can be independently developed, tested, and deployed, helping with business agility and speed to market.

#microservices #aws #architecture

What is GEEK

Buddha Community

Serverless Diary: Your Way to A Successful Event-Driven Architecture

Serverless Vs Microservices Architecture - A Deep Dive

Companies need to be thinking long-term before even starting a software development project. These needs are solved at the level of architecture: business owners want to assure agility, scalability, and performance.

The top contenders for scalable solutions are serverless and microservices. Both architectures prioritize security but approach it in their own ways. Let’s take a look at how businesses can benefit from the adoption of serverless architecture vs microservices, examine their differences, advantages, and use cases.

#serverless #microservices #architecture #software-architecture #serverless-architecture #microservice-architecture #serverless-vs-microservices #hackernoon-top-story

Ellie Windler

Ellie Windler


Why Serverless Architecture Is The Future Of Software Architecture?

Any business when thinking of scaling business applications in a cost-effective way goes for a cloud computing approach. Even leading technology companies like Quora, Facebook, LinkedIn, Pinterest, and Spotify are also getting benefits offered by cloud computing infrastructures.

In this article, we are going to deeply understand the concept of serverless and how it works and why it is useful for your business.

#Serverless Architecture #What is Serverless Architecture #Serverless

Serverless Eventing Architecture

Serverless is all about providing service on a provision as-used basis. Combining both you get the best of both worlds.

Event-Driven Architecture (EDA) is a way of designing applications and services to respond to real-time information based on the sending and receiving of information about individual events. Serverless is all about providing service on a provision as-used basis. Combining both you get the best of both worlds.

  • Loose coupling of services - For better fault tolerance, and can add/remove functionality on the go without affecting others.
  • Near real-time streaming process - No more polling but react immediately when the event occurred
  • Fine-grained scaling - Independently scaled up and down to ZERO, to meet the event volume.

OpenShift Serverless Eventing

There are many options when it comes to serverless, but if you are already a firm believer of open source, none vendor lock-in solution on the cloud, then the best is going to be Kubernetes. Knative runs on Kubernetes and enables serverless capabilities. Knative Eventing is built for systems that want to adopt EDA in a serverless world.

Here are some of the components in Knative Eventing that you need to know before designing the Serverless Integration.

brokersChannel and Brokers in terms of functionality are doing the same thing. (But when it comes to installation, you will need to set up Channel before Broker). Both are forwarding cloud events to its subscribers. As a pure Knative Developer you will use Subscription to get all events from the Channel and Triggers to get a selection of events from the Brokers.

#serverless #serverless architecture #eventing

Ron  Cartwright

Ron Cartwright


Getting Started With Azure Event Grid Viewer

In the last article, we had a look at how to start with Azure DevOps: Getting Started With Audit Streaming With Event Grid

In the article, we will go to the next step to create a subscription and use webhook event handlers to view those logs in our Azure web application.

#cloud #tutorial #azure #event driven architecture #realtime #signalr #webhook #azure web services #azure event grid #azure #azure event grid #serverless architecture #application integration

Event-Driven Architecture as a Strategy

Event-driven architecture, or EDA, is an integration pattern where applications are oriented around publishing events and responding to events. It provides five key benefits to modern application architecture: scalability, resilience, agility, data sharing, and cloud-enabling.

This article explores how EDA fits into enterprise integration, its three styles, how it enables business strategy, its benefits and trade-offs, and the next steps to start an EDA implementation.

Although there are many brokers you can use to publish event messages, the open-source software Apache Kafka has emerged as the market leader in this space. This article is focused on a Kafka-based EDA, but much of the principles here apply to any EDA implementation.

Spectrum of Integration

If asked to describe integration a year ago, I would have said there are two modes: application integration and data integration. Today I’d say that integration is on a spectrum, with data on one end, application on the other end, and event integration in the middle.

A spectrum with event integration on the left, application integration on the right, and event integration in the middle.

The spectrum of integration.

Application integration is REST, SOAP, ESB, etc. These are patterns for making functionality in one application run in response to a request from another app. It’s especially strong for B2B partnership and exposing value in one application to another. It’s less strong for many data use cases, like BI reporting and ML pipelines, since most application integrations wait passively to be invoked by a client, rather than actively pushing data where it needs to go.Data integration is patterns for getting data from point A to point B, including ETL, managed file transfer, etc. They’re strong for BI reporting, ML pipelines, and other data movement tasks, but weaker than application integration for many B2B partnerships and applications sharing functionality.

Event integration has one foot in data and the other in application integration, and it largely gets the benefits of both. When one application subscribes to another app’s events, it can trigger application code in response to those events, which feels a bit like an API from application integration. The events triggering this functionality also carry with them a significant amount of data, which feels a bit like data integration.

EDA strikes a balance between the two classic integration modes. Refactoring traditional application integrations into an event integration pattern opens more doors for analytics, machine learning, BI, and data synchronization between applications. It gets the best of application and data integration patterns. This is especially relevant for companies moving towards an operating model of leveraging data to drive new channels and partnerships. If your integration strategy does not unlock your data, then that strategy will fail. But if your integration strategy unlocks data at the expense of application architecture that’s scalable and agile, then again it will fail. Event integration strikes a balance between both those needs.

Strategy vs. Tactic

EDA often begins with isolated teams as a tactic for delivering projects. Ideally, such a project would have a deliberative approach to EDA and a common event message broker, usually cloud-native brokers on AWS, Azure, etc. Different teams select different brokers to meet their immediate needs. They do not consider integration beyond their project scope. Eventually, they may face the need for enterprise integration at a later date.

A major transition in EDA maturity happens when the investment in EDA shifts from a project tactic to enterprise strategy via a common event bus, usually Apache Kafka. Events can take a role in the organization’s business and technical innovation across the enterprise. Data becomes more rapidly shareable across the enterprise and also between you and your external strategic partners.

EDA Styles

Before discussing the benefits of EDA, let’s cover the three common styles of EDA: event notification, event-carried state transfer, and event sourcing.

Event Notification

This pattern publishes events with minimal information: the event type, timestamps, and a key-value like an account number or some other key of the entity that raised the event. This informs subscribers that an event occurred, but if subscribers need any information about how that event changed things (like which fields changed, etc.), it must invoke a data retrieval service from the system of record. This is the simplest form of EDA, but it provides the least benefit.

Event-Carried State Transfer

In this pattern, the events carry all information about the state change, typically a before and after image. Subscribing systems can then store their cache of data without the need to retrieve it from the system of record.

This builds resilience since the subscribing systems can function if the source becomes unavailable. It helps performance, as there’s no remote call required to access source information. For example, if an inventory system publishes the full state of all inventory changes, a sales service subscribing to it can know the current inventory without retrieving from the inventory system — it can simply use the cache it built from the inventory events, even during an inventory service outage.

It also helps performance because the subscriber’s data storage can be custom-tuned just for that subscriber’s unique performance needs. Using the previous example, perhaps the inventory service is best suited using a relational database, but the sales service could get better performance from a no-SQL database like MongoDB. Since the sales services no longer need to retrieve from the inventory service, it’s at liberty to use a different DBMS than the inventory service. Additionally, if the inventory service is having an outage, the sales service would be unaffected since it pulls inventory data from its local cache.

The cons are that lots of data is copied around and there is more complexity on the receivers since they have to sort out maintaining all the state they are receiving.

#integration #microservices #data #kafka #enterprise architecture #event driven architecture #application architecture