To Nha Notes | Sept. 10, 2024, 12:08 a.m.
Event-driven architectures are an architecture style that can help you boost agility and build reliable, scalable applications. Serverless services like EventBridge, Step Functions, SQS, SNS, and Lambda have a natural affinity with event-driven architectures - they are invoked by events, emit events, and have built-in capabilities for building with events.
Learn more about event-driven architectures, including key concepts, best practices, AWS services, and getting started resources.
Published by O'Reilly Media, Inc.
Jeremy Daly is an AWS Serverless Hero who has been managing the development of complex web and mobile applications for over 25 years. He is currently the CEO of Ampt, a developer productivity platform reinventing how we build applications in the cloud with Infrastructure from Code (IfC). Jeremy writes about serverless and shares thoughts about programming, product management, entrepreneurship, and productivity; he publishes the popular weekly serverless newsletter Off-by-none and hosts the Serverless Chats podcast.
Serverless has certainly become more mainstream as it’s matured over the years, and as we’ve seen an abundance of success stories and case studies, it’s become a less risky choice for organizations. Many of the services we consider “serverless” have already been widely adopted by organizations, even if only as part of their larger cloud technology stacks.
For start-ups and greenfield projects, I think a “serverless-first” approach has become the clear choice for most. However, there are a number of reasons why serverless still faces scrutiny from CTOs and other technology leaders, especially among established companies. There is a lot of technological inertia within organizations that have already begun their cloud journey. Containerization is still the standard, especially for larger organizations that have adopted Kubernetes as their platform of choice. We’ve recently seen a trend toward hybrid strategies that combine serverless and other more traditional approaches. While this is a step in the right direction, it often prevents companies from taking full advantage of the benefits of serverless architectures.
Serverless implementations let organizations focus on their core business rather than technology, but it’s also very developer-centric, which requires both upskilling developers and cooperation with existing operations and security teams. So while I think the robust ecosystem, widening vendor support, cost optimizations, and reduced time to market make serverless a clear technology choice for CTOs, the skills gap and complexity of migration still create friction that can complicate the decision-making process.
Most of the fundamental patterns we’ve been using for years are still highly relevant in today’s cloud architectures. The main difference is that many of those patterns have become more explicit, requiring a deeper understanding of how they need to be implemented in distributed cloud systems. The vast majority of serverless primitives are rock solid and for the most part have removed the undifferentiated heavy lifting of managing their complexity. However, configuring the plumbing between these primitives (event mappings, IAM permissions, failover behavior, etc.) falls on the implementer, and with a plethora of options to choose from, this can dramatically affect the success of any given pattern.
We’ve also seen a major resurgence of event-driven applications thanks to serverless and the patterns it enables. I think this is a good thing, but most developers grew up in a synchronous world of request/response. Asynchronous events and eventual consistency are core to distributed workloads, which often adds more cognitive overhead to understanding how modern cloud patterns work.
Awareness of patterns will be just as important in the future as it is today, but the hope is that we can find the right level of abstraction to avoid reinventing the wheel every time we need to implement one. There are hundreds of published patterns and Cloud Development Kit (CDK) constructs available; however, choosing the right one isn’t always straightforward. Even highly experienced architects need to experiment to find the combinations and configurations that best suit their workloads.
Also, off-the-shelf patterns may be easy to publish, but they’re not always easy to manage and maintain. Patterns need to evolve as throughput increases, and different patterns have very real trade-offs when it comes to cost and performance. Static architectures produced by traditional IaC require manual optimizations, updates to business logic, and multistep migrations. This is inefficient, adds complexity, and introduces significant technical debt.
Abstractions have eliminated managing memory and setting up physical servers. It seems like removing the need to write low-level machine code for the cloud is the next logical step. IfC is a step toward autonomous software delivery and management that automatically selects, deploys, and upgrades productized patterns on the developer’s behalf. This doesn’t necessarily negate the need to be aware of the underlying patterns, but it does democratize them and dramatically reduces operational complexity.
There is a massive library of predefined patterns and CDK constructs available across the internet. Though some are better than others, they can be extremely helpful starting points that get you up and running very quickly. However, my advice is that before you blindly trust them with production workloads, you should take the time to learn what each pattern does, what primitives it interacts with, its security configurations, and what it will cost to run. This includes understanding the underlying managed services, their limitations, and their supported use cases.
Learning from others’ work is great, but patterns generally need to be adapted to your specific situations. Run a lot of tests, ask for help when you need it, and gather the experience for yourself to successfully implement and operate your workloads.
Diversity of ideas, diversity of opinions, and diversity of perspective. One of the reasons why I started the Off-by-none newsletter was to amplify the voices of others, even if I didn’t agree with them. Communities can quickly become echo chambers that too easily drown out differences of opinion that would otherwise lead to healthy debate and further innovation. The serverless community is one of the greatest I’ve had the privilege to be part of, and over the years I’ve seen it continue to grow and diversify. This only happened because dedicated people did the necessary work to reach out, educate, and inspire. More needs to be done, and I hope others will keep up the amazing work they are doing to create an inclusive environment for everyone.
https://serverlessland.com/patterns
https://offbynone.io/issues/293/