BELHABIB ⠃⠑⠇⠓⠁⠃⠊⠃AMINE ⠁⠍⠊⠝⠑

Still one of my fav quotes. Every time someone tells me "serverless has servers!" this shuts them up good. Thanks @gojkoadzic!

The whole cloud repatriation movement didn't make sense to me. But I get it now. Thanks to Wardley Maps. The problem is not that these people don't "get" the cloud or that they are misguided. DHH is a smart man (as much as I don't agree with a lot of what he says). The problem is that we're building products that are at different stages along the evolution axis. (see this for the definitions of "genesis", "custom built", etc. learnwardleymapping.com/clim…) Most of the people in my circle are building things that are on the genesis / custom-built stage. Where there are a lot of uncertainties and opportunities to differentiate against the market incumbents. We're still discovering market fit and our product requirements can pivot at any moment. So we need technologies that offer a lot of flexibility and agility. The cloud and especially serverless technologies are great for these. If you need a new capability (e.g. add AI features to your app), you can just start using a new service and write a few lines of code in a Lambda function to hook things up. In some of my previous jobs, we'd sometimes come up with an idea or experiment, and we'd implement and ship it on the same day. But if you're building an email or instant messenger service then the picture is very different. These are very much known product categories and possibly governed by industry standards and protocols. The product requirements aren't going to change daily. And by nature of them being commodities, it's a competitive space and you need to compete on cost. When you need to be ruthless about efficiency, cloud repatriation makes sense. It's more cost-efficient to run on your own datacenter than renting virtual machines from the cloud IF you have the in-house expertise to do that. Again, you should be thinking in total cost of ownership terms. That's all well and good, but where this movement becomes dangerous is when we extrapolate what works for 37signals and apply that to other businesses on the other end of the evolutionary scale! Anyway, I hope you find some value in this rambling. Here's an article by Simon Wardley that helped me understand what's going on and inspired this post. In this article, Simon talks about why it doesn't make sense to use Agile, Lean or Six Sigma for everything. Because they work better for components at different stages of the evolution. blog.gardeviance.org/2015/06… If you want to learn more about Wardley Maps, you should check out learnwardleymapping.com or read Simon's other blog posts. Have a great weekend. #aws #cloud

Here are some trade-offs you should consider when choosing between API Gateway and Lambda Function URLs. 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗨𝗥𝗟𝘀 𝗣𝗿𝗼𝘀 1. Works naturally with Lambdaliths 2. No API Gateway latency overhead 3. No API Gateway-related costs 4. Response streaming 5. Simplicity - fewer things to configure 6. Can run for 15 mins 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗨𝗥𝗟𝘀 𝗖𝗼𝗻𝘀 1. You HAVE to use Lambdaliths (and all the shortcomings that come with that) 2. No per endpoint metrics & alarms 3. No direct integration with WAF (but possible through CloudFront) 4. Only AWS_IAM auth 5. Cannot configure different auth per endpoint 𝗪𝗵𝗲𝗿𝗲 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗨𝗥𝗟𝘀 𝗺𝗮𝗸𝗲 𝘀𝗲𝗻𝘀𝗲 If you WANT to (ie. not forced into it by the choice to use Function URLs) build a Lambdalith and you’re not using any of the additional features that API Gateway offers. Then Function URLs make sense - it’s cheaper, faster and has fewer moving parts. Similarly, if you need to return a large payload (> 10MB) or to run for more than 29s, then Function URLs also make sense IFF you can’t refactor the client-server interaction. Given the limited support for authentication & authorization, its use case is limited to public APIs or internal APIs (ie. not user-facing) in a microservices architecture. 𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 𝗽𝗿𝗼𝘀 1. Works with both Lambdaliths and single-purpose functions 2. Direct integration with most AWS services 3. Can proxy any HTTP API 4. LOTs of additional features - cognito authorizer - usage plans (great for SAAS applications that offer tiered pricing) - built-in request validation with request models - detailed per-endpoint metrics - mock endpoints (useful for endpoints that return static data) - request and response transformation (useful for integrating with 3rd party APIs) - & lots more 𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 𝗰𝗼𝗻𝘀 1. Additional latency overhead 2. Additional cost 3. No response streaming 4. 29s integration limit 5. 10MB response limit 𝗪𝗵𝗲𝗻 𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 𝗺𝗮𝗸𝗲𝘀 𝘀𝗲𝗻𝘀𝗲 Given the vast array of features that API Gateway supports, it makes sense in most cases if you’re OK with the additional cost that comes with the convenience. The 29s and 10MB response limits can be problematic, but they can be mitigated with patterns such as “decoupled invocation” and S3 presigned URLs. When it comes to REST APIs, I prefer API Gateway over Function URLs and ALB. ----- If you liked this, then you might also enjoy the tips and tutorials I publish every week about AWS and serverless. Subscribe to my free newsletter and level up your AWS game: theburningmonk.com/subscribe… #aws #serverless #awslambda