3 ms·
The immediate thought looking at that diagram is that while on first glance serverless runtimes seem to promise that you don't have to care about the details, t
by davnicwil 6y ago
The immediate thought looking at that diagram is that while on first glance serverless runtimes seem to promise that you don't have to care about the details, turns out you really do have to care a lot about the details!
You're not really relieving yourself of concerns by using serverless runtimes, just shifting them around. Sure, you don't have to care about managing state at the leaves, but you very definitely do now have to come up with a way to hold state globally with ephemeral/stateless leaves, and it turns out that's... a really hard problem with a really complex solution space.
Not to be overly dismissive or say that one way is better than the other, it definitely depends on the usecase and probably the underlying business model of the usecase. Just to point out that when it comes to engineering abstractions, there really isn't any free lunch. It's all tradeoffs.
- scarface74 6y agoHow is that any different than a typical web server? Hopefully you don’t maintain state on your web server either. This isn’t a new concept. Even in the early 2000s when I was maintaining two web servers behind a physical load balancer we knew to maintain session state separately from the web server.
- joana035 6y agoSoon we will be feeding plants with energetic drinks.
- mickotron 6y agoIt has what plants crave
- voz_ 6y agoI had the same question - if this guy has each web request adding to local state on his web server, I have some bad news...
- scarface74 6y agoI hate to be “that guy”. But “the cloud” is no more than someone else managing servers and services at varying levels of abstraction. I have no idea why some people hear AWS/Azure and they act as if the same architectural principles that have always applied still apply, just on a more granular scale in the case of “Serverless”.
- voz_ 6y agoNot sure I understand the point you are making? > and they act as if the same architectural principles that have always applied still apply, They do still apply...
- scarface74 6y agoI was agreeing with you. More of a rant about the person who complains about not being able to maintain state at a tier that you never maintain state at in even a traditional architecture.
- voz_ 6y agoah, gotcha! Very good :)
- xiwenc 6y agoIt’s nice to see the serverless movement and its applications. However the fact every (public) cloud provider does it differently is killing it (incompatible logic/interfaces). Right now, serverless is merely shifting complexity of apps to cloud services. Cloud services with a lot more logic (lines of code) that does a million other things than what your application needs. That oftens means much more (uncovered) bugs. In order to have better control and predictability there has to be standards and minimizing depth of code. I’m convinced serverless is the next after containers; but only if it becomes a standard that can encapsulate services in building blocks that you can easily connect with each other and very predictably behavior. We are not there yet, hopefully soon.
- scarface74 6y agoThe only think that you need to make your code work with Lambda is a function that takes in an event body and a Lambda context. If you are following standard architectural best practices, your lambda entry point should just be validating your event, mapping it to your business domain and remapping the result. You should treat your lambda event just like you would an action in your controller in most MVC frameworks aka “skinny controllers”. This is a standard “onion architecture” with “ports and adapters”. Sound development principles don’t get thrown out of the window just because you “move to the cloud”.
- carlsborg 6y agoIf you're running a stateless containerized architecture you need to hold state globally too, right?