TL;DR notes from articles I read today.
Serverless pitfalls: issues with running a startup on AWS Lambda
- Functions with less RAM have slower CPU speed. Take both CPU and RAM into account (as well as the related costs: you save no money once execution time drops below 100ms) when allocating resources to Lambda functions.
- Hosting your backend behind an API gateway can result in latency issues. If you want <50ms response times, you need dedicated infrastructure.
- Lambdas in a VPC cannot connect to outside services like S3 unless you install a NAT gateway, with the associated charges. It’s best to run either completely inside or outside a VPC, even if it means less security and more latency and bandwidth costs.
- Due to their distributed queues, AWS can execute Lambdas more than once per request. So be aware of and work around their idempotency.
- You’ll find it hard to identify and debug functions that hang or get deadlocked because they automatically disappear over the limit. You’ll need to look to Cloudwatch for them.
- Executing a Lambda from another Lambda is slow. Either launch a task specifically to launch a large number of other tasks or use threads to launch multiple tasks simultaneously.
- To work around the dreaded cold start, you can move front-end requests facing the end user off Lambda and try to containerize.
Full post here, 10 mins read
Break a monolith to microservices - best practices and design principles
- Figure out how to segregate the data storage according to the constituent microservices, using a CQRS (command and query responsibility segregation) architecture so that data is not shared between microservices and is accessed only via APIs.
- Break down the migration into steps, applying domain-driven design, rather than overhauling all repositories, deployment, monitoring, and other complex tasks at once. First, build new capabilities as microservices, then break down the monolith, starting with transforming any known pain points and troublesome gaps.
- Allocate dedicated teams to every microservice to scale linearly and efficiently, as each team will be familiar with the nuances of its own service. Recognize this is as much a cultural shift as an operational one.
- Pair the right technology with the right microservice for maintainability, fault tolerance, scalability, economy, and ease of deployment, and choose languages based on the team’s existing skillset.
- Use ‘build and release’ automation to independently deploy each microservice.
- Use a REST API so you need not install additional software or libraries and can handle multiple types of calls and data formats.
- Isolate runtime processes with distributed computing - containerization, event architectures, HTTP management approaches, service meshes, circuit breakers, etc.
- Distinguish between dedicated and on-demand resources, moving between them to reduce response time and deliver a superior customer experience; also reduce dependency on open-source tools.
Full post here, 8 mins read
Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().
Oldest comments (0)