"Serverless sucks!"... or does it?
Вставка
- Опубліковано 12 бер 2024
- Serverless sucks... or does it? There is a neverending supply of people saying that serverless is trash and has no value. The issue often with these statements is they need to provide more context. As always, context is king, and understanding the use case to make decisions on when serverless might be appropriate.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - Наука та технологія
Want to learn more about software architecture and design? Join thousands of developers getting weekly updates!
🚀mailchi.mp/63c7a0b3ff38/codeopinion
Love the focus on “scaling down”. With the advent of cloud computing we have all become all too comfortable spending money for scale up, but we focus less on scale down and scaling strategies that account for expansion and contraction.
Yup. Just a way I've always thought about the use-case for serverless. Autoscaling is all over the place for most services but scaling up has a lot of implications to other downstream services as I mentioned.
The Amazon video example is so overused and misrepresented. Their original architecture was insane, not because it was serverless but because they were extracting every frame of video and storing it separately, which is always going to be absolutely enormous. If you do it that way, a single video will be terrabytes of data and millions of requests/messages. They fixed it by changing their unit of work from frames to videos so that they could process the video in memory, not really by changing the architecture that it was hosted on.
Also people act like it's the whole of Amazon video, but it was actually just some random internal service.
Yup,.that's what I covered in my video.
My go to for API development is API Gateway + Lambda (either with proxy integration or having a lambda for each endpoint) + some sort of connection pool to connect to the database (e.g., RDS proxy).
Agree, this works well for many use cases and it is very cost effective. It really depends on the situation.
I don't know, I've found the feedback loop to be really slow. I'm much faster developing with a full stack framework, where I have behavioral tests run while I code.
The point about accounting for low peaks scaling against cost was interesting. Good point
As mentioned I think it's just not as though about but relevant. Thanks for the comment
I'm curious how you manage to avoid direct synchronous communication between lambdas. In the traditional programming model, we often need to fetch data from another microservice for calculations or business logic. In the case of serverless, this is an antipattern. Do you then build an API for the microservice as a shared library, or is there another approach?
make it work, when it's slow, optimize it, when its optimized enough, scale it.
I didn’t know this discussion was even a thing 😂. Fortunately, my Twitter timeline has a minimum of sanity.
I would love to get your opinion on feature flags. We use trunk based development and we are also undergoing refactoring. With the refactoring happening across multiple files in a critical service, feature flags may not be the most efficient. I am considering using A/B testing instead.
Great suggestion
Serverless has its uses, too. Especially for an asynchronous event-driven Microservice Architecture.
For me the biggest advantage of using serverless is the ease of integrating many services: it's way easier to use for example SQS-Lambda integration than to make the polling yourself, and SQS is just one of the miriad of examples. Ofc you need to then watch out for vendorlocking and make your business code abstracted out of it, and at the same time embrace the cloud for the integrations, which is quite a mental and dev-experience shift, but from my experience it really pays off in the early >years< of a product.
Also I think that this "ease of serverless" in general - how it's being often sold by cloud providers, can be often misleading for the developers, who then do not architect their solutions correctly, and just try to "go with the flow" - one can get burnt this way quite easily ;)
Yes, SQS is a great example. Just image the amount of effort you need to setup a working queuing system with the same amount of redundancy and performance as SQS on your own.
Yes, agree'd this is an advantage.
Do you really get that much more with SQS than a RabbitMQ cluster? So far I've always preferred to avoid proprietary serverless infrastructure, but clearly it must offer something special to a lot of people.
@@pdgiddie The ease of use of SQS is phenomenal. I start it up, the name becomes the URL to fire messages into. And that's it. You fire JSON payloads with a put request against the URL, and retrieve them with get requests from the URL. It is that dead simple.
Assigning Authentication via OAuth tokens is a bit finicky, because AWS Role and Access Management is fairly complex, and making it work with your own service via federation is a major undertaking.
But rolling your own MQ cluster is several orders of magnitude more effort and more expensive.
Great points right here!
Hovewer, in the context of expanding an application's functionality with a new process or job, how does one decide between deploying it as a separate serverless function or integrating it into an existing deployable unit, considering the implications on resource usage? Should the decision be primarily guided by the principles of segregation of the context to maintain clear boundaries? How do factors like cohesion, coupling, scalability, operational complexity, and cost efficiency play into making an informed choice between these two architectural options?
Good questions, which are not specific to serverless. In a traditional server world, you should ask the same questions: add to existing one or hosting on it's own?
I would look at the whole process and check: is this a variation of an existing step, likely extend the existing one. Is this a complete new step, likely a dedicated function.
Cohesion I see very important due its natural guiding to meaningful units. Like an address validation with an external API: separating both in separate functions doesn't make much sense from my point of view.
I just wrote a long reply and have no idea where it went. Thanks YT. Ultimately physical isn't logical so you can choose how to deploy based on needs. you may have some job that is very CPU intensive and you don't want it to run within another deployable unit/process as it will affect other work. For that reason maybe it's deployed as a separate unit. Or maybe that's not an issue and it's just deployed along with an HTTP API that you have running in a container.
Context is king for sure. I've dabbled with serverless, however it doesn't fit my bill, main as my company is developing systems for air-gapped offline environments, of course it would be technically possible to do some "serverless" there too, but that is not even remotely realistic. Nice video, proves a good point.
I was working for a company running a big e-commerce marketplace. Their system was build around a stream of events passing from one serverless microservice (Azure Function) to another. During that process, the data was enriched, and stored in databases along the way.
This architecture was created by consultants that came from a renowned Swedish consulting firm. After that, they left it for the company to maintain.
Although the architecture seems useful in certain cases, in this instance it just necessarily complicated stuff. When you had to change data contracts then you had to makes changes across all services and deploy - I had to do that during my short tenure there. Another problem was that sometimes they had to re-run all events - like when they had to update product data. That could take a long time. So clearly not ideal.
They should have used regular microservices in an ordinary event-driven architecture.
Ouch. That sounds like a distributed monolith. The worst of both worlds. Also way, way too tight coupling between services.
@@dominikvonlavante6113 Exactly. What people don't think when building this kind of stuff is that what technically makes something a "microservice" is that it is independently deployable + all the things that come with it in terms of versioning contracts. Given that this system was built by consultants, this was probably so experimental to them. They were not even worried about maintaining it later.
was there even a point in having microservices?
@@lukassinkus6162 There certainly was a need for scaling, as it is a big e-commerce site. The part that I'm talking about might have started as a convenient way of dealing with data processing - processing and enriching data as events passing through Azure Functions. There were a couple of change being made as they went from selling stuff themselves to being a marketplace. Grouping offers by product. That added more complexity. Other than that, the actual site was split into different parts hosted separately - so that checkout still should work even if the catalog was down. Which you could have dealt with in other ways, having true microservices. Anyway! I learned a lot!
@@marna_li That's what you get with consulting, they're all agile, they start knowing jack shit about what the business needs and they end that way.
Lovely. They are agile.
What does 'serverless' even mean these days? I can run lambdas in ecs with a monolithic docker image but powered by my own managed ec2 instances. Where does this fall?
From what I can tell, "serverless" as a concept I think would entail anything that's spun up on-demand per request and is somewhat atomic. This probably gets really loosely goosey in production but I think that's the idea. So it could totally apply to what you are doing.
#whynotboth ?!?!
Google Cloud Run. Good for all that ails ya!
Right Derek?? 🤩
Ugh. It's been _so_ buggy for us.
@@pdgiddie Willing to bet you're doing something wrong then.
@@lost-prototype hehe it's a fair bet, but I don't think so. If you're wondering, we've seen random network hiccups, revision numbering weirdness, old revisions continuing to run for a significant time, fresh instances of old revisions being booted up. There are probably reasons for it all, but the overall feeling is that in the process of trying to make everything just work, they've actually made everything hard to reason about.
And this is not Cloud Run's fault, but by design it does not allow communication between containers, and offers no remote console. Which in our tech stack is a huge deal. But that's an inherited decision 😅