This chapter is from the book
This chapter is from the book
This chapter is from the book
This Book Is Not About…
Service-Oriented Architectures
Serverless applications generally have service-oriented architectures (SOAs), with some custom code calling managed services and other custom code acting as a service (as opposed to using a lot of repeated code in different, similar features).[11] Using unnecessarily repeated code or repeated bespoke functionality within Serverless applications is difficult because leveraging managed services is native and simple within Serverless architectures.
However, this book does not spend significant time talking about SOAs in the context of building Serverless applications. Much of the discussion surrounding SOAs is predicated on older, non-Serverless methods of building software. Once an organization adopts a Serverless mindset, developers are highly unlikely to stray from SOA patterns because of how natural the patterns are in Serverless.
Monoliths and Microservices
The monolith vs. microservice debate has raged for more than a decade. That age is increasingly apparent when viewed in light of Serverless development. Serverless architectures tend to muddy the definitional waters between the two strategies; many Serverless applications, including those at Branch, have characteristics of both.
For example, one factor that drove a lot of initial microservice development was concern about the uptime and scalability of databases. Netflix famously implemented microservices to increase the resilience of other systems, giving stateful microservices their own databases to prevent other database failures from impacting their uptime.[12] However, many Serverless applications use managed, resilient, global databases such as AWS DynamoDB that have incredible historical uptime and low latency. When using DynamoDB, the traditional microservice motivations for separation of concerns around the datastore no longer exist.
Another operational motivation for separation of concerns within microservices has been preventing cascading failures due to traffic overload on a particular service. However, if service code is running on a service such as AWS Lambda, Google Cloud Functions, or Azure Functions, those cloud providers have proven that they can prevent any kind of cascading failure because of the capacity and architecture they have built for running code.
Nevertheless, Serverless applications often feel more like microservice applications because of how they use services and how they tend to separate business concerns. In my experience, most Serverless applications are too broken up into separate functions (more on this in Chapter 3, “Serverless Architectures”). Branch’s architecture at the time of publication consists of around 100 Lambda functions and 5 React applications, but all in a monorepo designed to be deployed monolithically. Definitionally, that’s not a monolith or a microservices architecture, and I don’t think the distinction is helpful when building Serverlessly.
No-Code/Low-Code Platforms
This book is built on the assumption that the organization has software developers who will use software development languages, frameworks, and environments. My experiences with no-code and low-code platforms have led me to believe that the only ones that really work are those that use standard languages and function as a higher-level framework that can be “ejected” (for example, Expo for React Native, or AWS Amplify for web applications)[13] so that the application can continue development in a more traditional development and/or hosting environment.
I believe that no- and low-code platforms have their place. We used one to build our initial interactive demo for Branch, which was a much faster and easier route than building it in code (and also less likely to lead us to technical debt). But ultimately, there is no comparison between what is possible with no- and low-code platforms versus fully fledged languages and frameworks. Building a customer-facing, business-critical application in a no- or low-code platform is risky because of how inherently limited the platforms are. Therefore, this book does not address any tools or services that I consider no- or low-code (that is, proprietary language and/or IDE combined with proprietary hosting and no ability to eject).