Event-driven architecture enables building highly available and reliable applications that can scale to handle traffic spikes. However, there are some misconceptions around its use. This article discusses some of these misconceptions and debunks them with some practical examples.

Myth #1: Difficult to Manage

Event-driven applications are designed around event brokers, which connect event producers and consumers. However, having to include an event broker has created an impression that it increases the complexity of the deployment and raises management and monitoring overhead.

When cloud computing rose in popularity, IT teams started to abandon on-premises event brokers in favor of cloud-hosted, managed messaging services such as AWS SQS/SNS, Azure Event Grid, Event Hubs and Google PubSub. These services eliminated the burden of managing and scaling event brokers.

With the rise of serverless computing, this reached another level. Organizations moved their entire event-driven applications into cloud infrastructure-as-a-service (IaaS) platforms, to save money and lessen management complexity. Then functions-as-a-service (FaaS) platforms, such as AWS Lambda and Google Cloud Run, seamlessly integrated with existing messaging services to provide an improved developer experience. This further motivated developers to move their event production and consumption logic into cloud platforms.

Today, there are many organizations using cloud infrastructure to build and deploy their event-driven applications. Lower management complexity, reduced total cost of ownership (TCO) and improved developer experiences are key factors that have contributed to organizations making the switch.

So, we can no longer say that event-driven applications are complex to manage.

Figure 1: Cloud native programming languages like Ballerina use serverless technologies to build event-driven applications. (Source: Imesh Gunaratne)

#devops #microservices #technology #contributed #sponsored