Forem: Conor Shirren

Designing Event Driven Architectures

Conor Shirren — Mon, 16 Jan 2023 15:20:48 +0000

Introduction

Event-driven architecture (EDA) is a modern architecture pattern built from small, decoupled services that publish, consume, or route events.

An event represents a change in state, or an update. For example: an item placed in a shopping cart, a file uploaded to a storage system, or an order becoming ready to ship. Events can either carry the state (such as the item name, price, or quantity in an order) or simply contain identifiers (for example, “order #8942 was shipped”) needed to look up related information.

Unlike traditional request-driven models, EDA promotes loose coupling between producer and consumer services. This makes it easier to scale, update, and independently deploy separate components of a system.

What is a decoupled architecture important?

Many organizations find that monolithic applications, databases, and technologies negatively impact innovation and improvement of the user experience. Legacy applications and databases reduce your options for adopting modern technology frameworks and constrain your competitiveness and innovation. However, when you modernize applications and their data stores, they become easier to scale and faster to develop.

A decoupled data strategy improves fault tolerance and resiliency, which helps accelerate the time to market (TTM) for your new application features.

Benefits of an event-driven architecture

Event-driven architecture (EDA) promotes loose coupling between components of a system, leading to greater agility. Microservices can scale independently, fail without impacting other services, and reduce the complexity of workflows. Events can be flexibly routed, buffered, and logged for auditing purposes. Push-based flows of events can operate in real time, cutting costs associated with creating and operating code that continuously polls systems for changes.

1. Scale and fail independently

By decoupling services, components in an event-driven architecture can scale and fail independently, increasing the resiliency of an application. This becomes increasingly important as the number of integrations between services grows. If one service has a failure, the rest can keep running.

Event-driven architecture can also make it easier to design near real-time systems, helping organizations move away from batch-based processing. Events are generated when an application state changes. As events scale up, so can the layer that processes the events.

Events are typically published to messaging services that behave like an elastic buffer between microservices and help handle scaling. Events might also be sent to a router service that can filter and route messages based on the content of the event. As a result, event-based applications can be more scalable and offer greater redundancy than monolithic applications.

2. Develop with agility

With event-driven architecture and event routers, developers no longer need to write custom code to poll, filter, and route events. An event router automatically filters and pushes events to consumers. The router also removes the need for heavy coordination between producer and consumer services, which increases developer agility.

Event-driven architecture is push-based, meaning that everything happens on demand as events are sent to the router and downstream systems, without needing to inform dependent services. Because of this, infrastructure and resources can scale up and down with event volume, which reduces costs to process workloads and operate deployed applications.

3. Build extensible systems

Event-driven architecture is also highly extensible. Other teams can extend features and add functionality without impacting the existing microservices. By publishing events, an application can integrate with existing systems—and future applications can integrate easily as event consumers—without changing the existing solution.

Event producers have no knowledge of event consumers, so extending the system has less friction, and new features or integrations do not add dependencies that slow down future development.

4. Reduce module complexity

Microservices enable developers and architects to decompose complex workflows. For example, they can break down an ecommerce monolith into order acceptance and payment processes with separate inventory, fulfillment, and accounting services.

A workload that might be complex to manage and orchestrate in a monolith becomes a series of simple, decoupled services that are managed independently and communicate asynchronously through event messages.

An event-driven approach makes it possible to assemble and orchestrate services that process data at different rates. In the following example, an order acceptance microservice interacts with a payment processing system via a queue.

How it works: example architecture

Here's an example of an event-driven architecture for an e-commerce site. This architecture enables the site to react to changes from a variety of sources during times of peak demand, without crashing the application or over-provisioning resources.

How does event-driven architecture (EDA) improve applications?

Event-driven architecture (EDA) promotes loose coupling between components, which makes it a good approach to build modern, distributed applications.

Event producers are unaware of, unconcerned by, and unburdened by any activity of downstream consumers of the events that they produce. The events themselves represent a change in state and may or may not contain data. Events are unaware of consequences of their existence. Consumers listen and process events of interest. You can bring new consumers online to provide new functionality without disrupting existing workflows.

EDAs promote decomposition of monolithic systems into smaller domain models. Developers can get up to speed with less cognitive load and become productive quicker. When critical functions are decoupled, there is also less risk to deploy updates and new features.

What is Humane Tech? 🪴

Conor Shirren — Sun, 15 Jan 2023 17:43:34 +0000

Introduction

Whether we like it or not, a significant amount of the technology we use is exploitative to some degree. Humane tech is an idea that aims to shift the focus to creating socially-responsible technology that doesn’t exploit the user. It’s a noble idea, and one that becomes more important as our dependence on various forms of tech increases.

The Center for Humane Technology

The Center for Humane Technology (CHT) was co-founded by Tristan Harris (you may know him from the Netflix show The Social Dilemma), who previously pushed the ‘Time Well Spent’ movement after originally working for Google, where he produced an internal presentation in 2013 entitled “A Call to Minimize Distraction & Respect Users’ Attention”. Along with Google, he namechecked Apple and Facebook, highlighting their responsibilities to their users.

While the CHT freely admits that benefits do derive from social media and mobile tech to some degree, they also bring up various issues that have begun to affect society on a wider scale. These include:

Digital Addiction: Many people are addicted to technology, with digital slot machines compounding the issue.
Mental Health: Digital addiction and increased social media use can have a negative impact on mental health.
Breakdown of Truth: It’s becoming harder to tell what’s real and what isn’t, especially if spending a lot of time online.
Polarisation: Has it become more difficult to co-operate with others due to polarising online ideologies?
Political Manipulation: This is caused either by creating rifts and sowing seeds of doubt, or by people directly impacting elections themselves.
Superficiality: By focusing on looks and likes, have we become more superficial?

These issues indicate a “mismatch between our natural human sensitivities and the exponentially growing power of technology”, a problem likely to escalate in future.

The CHT provide a free, self-paced online course for professionals that are shaping tomorrow's technology. This course can be be found here , and I would highly recommend that you check it out for yourself.

Instead of exploiting our vulnerabilities, there are endless ways in which tech could be used to improve society, as well as our overall quality of life. It’s still a small movement, but hopefully humane tech will continue to grow!

Demystifying AWS Lambda Functions

Conor Shirren — Sat, 14 Jan 2023 20:54:19 +0000

Introduction 👋

In the previous blog post of this series, I introduced the concept of the serverless mindset, and how adopting serverless could best suit you and your company's needs. In this blog post, I'm going to dive a little deeper into AWS Lambda, which is at the core of AWS Serverless.

What is AWS Lambda?

AWS Lambda is a compute service. You can use it to run code without provisioning or managing servers. Lambda runs your code on a high-availability compute infrastructure. It operates and maintains all of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring, and logging. With Lambda, you can run code for almost any type of application or backend service.

Some benefits of using Lambda include the following:

You can run code without provisioning or maintaining servers.
It initiates functions for you in response to events.
It scales automatically.
It provides built-in code monitoring and logging via Amazon CloudWatch.

AWS Lambda Features

The following the six main features of AWS Lambda:

You can write the code for Lambda using languages you already know and are comfortable using. Development in Lambda is not tightly coupled to AWS, so you can easily port code in and out of AWS.
Within your Lambda function, you can do anything traditional applications can do, including calling an AWS SDK or invoking a third-party API, whether on AWS, in your datacenter, or on the internet.
Instead of scaling by adding servers, Lambda scales in response to events. You configure memory settings and AWS handles details such as CPU, network, and I/O throughput.
The lambda permission model uses AWS IAM (Identity & Access Management to securely grant access to the desired resources and provide fine-grained control to invoke your functions.
Because Lambda is a fully managed service, high availability and fault tolerance are built into the service without needing to perform any additional configuration.
Lambda functions only run when you initiate them. You pay only for the compute time that you consume. When the code is invoked, you are billed in 1-millisecond (ms) increments.

What is a Lambda Function?

The code you run on AWS Lambda is called a Lambda function. Think of a function as a small, self-contained application. After you create your Lambda function, it is ready to run as soon as it is initiated. Each function includes your code as well as some associated configuration information, including the function name and resource requirements. Lambda functions are stateless, with no affinity to the underlying infrastructure. Lambda can rapidly launch as many copies of the function as needed to scale to the rate of incoming events.

After you upload your code to AWS Lambda, you can configure an event source, such as an Amazon Simple Storage Service (Amazon S3) event, Amazon DynamoDB stream, Amazon Kinesis stream, or Amazon Simple Notification Service (Amazon SNS) notification. When the resource changes and an event is initiated, Lambda will run your function and manage the compute resources as needed to keep up with incoming requests.

How AWS Lambda Works

To understand event driven architectures like AWS Lambda, you need to understand the events themselves. This section dives in to how events initiate functions to invoke the code within.

Invocation models for running Lambda functions

Event sources can invoke a Lambda function in three general patterns. These patterns are called invocation models. Each invocation model is unique and addresses a different application and developer needs. The invocation model you use for your Lambda function often depends on the event source you are using. It's important to understand how each invocation model initializes functions and handles errors and retries.
There are three different invocation models for AWS lambda functions:

Synchronous invocation
Asynchronous invocation
Polling invocation

Synchronous invocation

When you invoke a function synchronously, Lambda runs the function and waits for a response. When the function completes, Lambda returns the response from the function's code with additional data, such as the version of the function that was invoked. Synchronous events expect an immediate response from the function invocation.

With this model, there are no built-in retries. You must manage your retry strategy within your application code.

The following diagram shows clients invoking a Lambda function synchronously. Lambda sends the events directly to the function and sends the function response directly back to the invoker.

Asynchronous invocation

When you invoke a function asynchronously, events are queued and the requestor doesn't wait for the function to complete. This model is appropriate when the client doesn't need an immediate response.

With the asynchronous model, you can make use of destinations. Use destinations to send records of asynchronous invocations to other services. (Select the Destinations tab for more information.)

The following diagram shows clients invoking a Lambda function asynchronously. Lambda queues events before sending them to the function.

Polling invocation

This invocation model is designed to integrate with AWS streaming and queuing based services with no code or server management. Lambda will poll (or watch) these services, retrieve any matching events, and invoke your functions. This invocation model supports the following services:

Amazon Kinesis
Amazon SQS
Amazon DynamoDB Streams With this type of integration, AWS will manage the poller on your behalf and perform synchronous invocations of your function.

With this model, the retry behavior varies depending on the event source and its configuration.

Invocation model error behavior

When deciding how to build your functions, consider how each invocation method handles errors. The following chart provides a quick outline of the error handling behaviour of each invocation model.

Performance optimisation

Serverless applications can be extremely performant, thanks to the ease of parallelisation and concurrency. While the Lambda service manages scaling automatically, you can optimise the individual Lambda functions used in your application to reduce latency and increase throughput.

Cold and warm starts

A cold start occurs when a new execution environment is required to run a Lambda function. When the Lambda service receives a request to run a function, the service first prepares an execution environment. During this step, the service downloads the code for the function, then creates the execution environment with the specified memory, runtime, and configuration. Once complete, Lambda runs any initialisation code outside of the event handler before finally running the handler code.

In a warm start, the Lambda service retains the environment instead of destroying it immediately. This allows the function to run again within the same execution environment. This saves time by not needing to initialise the environment.

Reducing cold starts with Provisioned Concurrency

If you need predictable function start times for your workload, Provisioned Concurrency is the recommended solution to ensure the lowest possible latency. This feature keeps your functions initialsed and warm, ready to respond in double-digit milliseconds at the scale you provision. Unlike on-demand Lambda functions, this means that all setup activities happen ahead of invocation, including running the initialisation code.

Conclusion 💡

In this post we covered a lot of content on what AWS Lambda is, how it can be used, and some best practices when doing so.

Although there is a whole lot more to serverless than just lambda functions, it really is at the core of AWS Serverless and an understanding of how you can utilise lambdas in your architecture design is crucial to your adoption of the serverless-first mindset.

In further blog posts in this series, I will dive into some other AWS services that you can use in your serverless journey, as well as showing you just how easy it is to get set up and start building lambda functions for yourself!

Getting Into the Serverless Mindset

Conor Shirren — Fri, 13 Jan 2023 14:45:27 +0000

Introduction 👋

In chapter one of the AWS Serverless Learning Path, you will be introduced to the key concepts of the AWS Serverless Platform, as well as discussing a little bit about the differences between traditional infrastructure designs and serverless architectures.

The Familiar Architecture 👴🏻

Let us take a look at a very simple web service that most devs would be familiar with:

a simple client
an EC2 Instance to host the service
a database to persist data

In a scenario where your service starts gaining traction, and you need to scale up to handle the traffic you are receiving, you would need to do something like the following:

To handle the load in this traditional architecture, you would need to horizontally scale your EC2 instances to handle requests and use a load balancer to divert traffic.

This option will work fine, although you now have an issue with cost management. You might get more traffic midday during the week than you do in the middle of the night on a weekend for instance, and with the current architecture you have to provision for your peak load and continue to pay for those servers even when they are idle.

But in a cloud environment, this problem is easy enough to solve. You can simply add an Auto Scaling group to automatically provision and terminate instances based on your application’s traffic patterns.

So now you can handle all the traffic when your service is under heavy load, but minimize your costs when it’s not getting as much traffic. Now, in addition to elastically scaling your app, you probably also want to ensure it’s highly available and fault tolerant.

You want to make sure that you’re spreading your instances across multiple availability zones in order to ensure that, even if there's a failure of a single data center, your users will still be able to access your service. This is also easy to implement. You just make sure the load balancer and auto scaling group are configured to spread your instances across availability zones.

So now you’ve got a highly available architecture that elastically scales to handle your peak traffic load while still saving costs during off-peak hours. This is a very, very common architecture that's been successfully deployed thousands of times by many different companies.

However, there are multiple things that you as an application architect or developer need to be concerned with when you build and operate a system like this.

Introducing the Serverless Architecture 🙌🏽

If you take a look at the list below, I have outlined some of the concerns that a developer would have to consider when building out the architecture in the previous section:

What’s interesting about this list on the right is that the best practices for how to handle these are very, very similar across companies. There's very little that’s business specific about how you would approach most of these issues.

And this is exactly the kind of undifferentiated lifting that can be offloaded to AWS allowing you to focus more on the things that are unique to your particular business.

This is really the driving force behind the AWS serverless platform.

Lets take a look at how you could rearchitect this service using the serverless mindset. Looking at the image below it can be broken down into three simple phases

a client invocation
some form of business logic being applied to that request
a data store to persist information from the request

To look at this through a serverless lens, it could look something like this:

the the source of the event (in our case, a HTTP request from a client)
a lambda function which we will use to execute our business logic
a dynamodb which we will use to persist request data (this could also be replaced with a call to another API or service)

In this architecture, all of the concerns around cost, scalability, and availability are offloaded to AWS through the use of their serverless services. We as developers can focus on what matters, the application code and core business logic. Both the lambda and dynamodb will automatically scale to handle load during peak hours, as well as being fault tolerant across availability zone (spread across different AWS data centres that are separately geographical). As well as this, lambda uses a pay-per-execution pricing model which means we do not pay for idle-server time during off-peak hours.

This is just one of many examples of where we can use AWS Serverless services to offload undifferentiated heavy lifting to AWS, some of which I will discuss as part of further bog posts in this series.

Conclusion 💡

In this post we briefly introduced some of the core concepts of serverless, and why it might be beneficial to consider rearchitecting your systems to make use of its many advantages. Some of these include:

No need to provision or manage servers
Automatic scaling
Pay-per-execution pricing model
Reduced operational costs
High availability and fault tolerance
Easy integration with other AWS services
Shortened development and deployment cycles
Improved security
Increased developer productivity
Flexibility in building and deploying applications

Although I have only discussed a couple of these benefits in this post, I plan to dive deeper into why Serverless-First is the way forward in 2023, stay tuned!

The AWS Serverless Badge

Conor Shirren — Tue, 10 Jan 2023 08:23:35 +0000

Introduction 👋

Amazon Web Services recently announced at Re:Invent an all-new way to demonstrate your AWS Serverless knowledge and skills with a verifiable, digital badge.

This Serverless Learning Plan has been designed to help you get started building with Serverless technology. AWS experts designed the content to provide a clear learning path to help you develop the skills you need quickly (and best of all, it's completely free!).

Over the holiday period I decided to take some time to sit down and complete the AWS provided learning path and I am happy to say that I received my AWS Serverless Skill Builder Badge from AWS, which you can view here.

The Course 📚

This learning plan consists of the following chapters:

Getting into the Serverless Mindset
AWS Lambda Foundations
Designing Event-Driven Architectures
Architecting Serverless Apps
Scaling Serverless Apps
Deploying Serverless Apps
Amazon API Gateway for Serverless Apps

Most of the sections take around 1-2 hours of both written and video content so a good size to set yourself a goal of one per day or weekend etc.

The Exam 📝

To obtain your serverless badge from Credly, you will need to complete the assessment at the end of the learning path with a passing score of 80%. The exam consists of 50 multiple choice questions which you have unlimited time to answer (you may also save your progress and resume the exam at a later time).
One thing to keep in mind is that if you fail an attempt, you must wait 24 hours before you can reattempt the exam. Thankfully, you have unlimited attempts so use these 24 hours to your advantage and do some revision on the areas of the assessment that let you down (at the end of a failed exam, you are not shown which questions you failed on, but you are provided with some guidance on chapters you should focus on).

Conclusion 💡

Overall I think the Serverless Learning Plan is a fantastic way to dive right into the serverless mind sight. Whether you're already an AWS Solutions Architect or a Cloud Newbie, this course will walk through a lot of the architect and design best practices that most official documentation just doesn't cover.

Over the next few weeks I will be continuing to publish blog posts that delve into each chapter provided by this course, so please stay tuned 🤠🚀