Serverless Architectures
martinfowler.com
Serverless Architectures
1–10 of 215 posts
Re: Serverless Architectures
#2The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
Re: Serverless Architectures
#3Previous (recent) discussion at https://news.ycombinator.com/item?id=11921208
Re: Serverless Architectures
#4The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
I got burned by Parse on this already. One of the nice things about Zappa (https://github.com/Miserlou/Zappa) is that you can return to a non-serverless architecture if you want to.
Re: Serverless Architectures
#5Previous (recent) discussion at https://news.ycombinator.com/item?id=11921208
I submitted this link: http://martinfowler.com/articles/serverless.html#drawbacks with the title "Serverless Drawbacks", as that was the recently added section. Guess someone changed it, but it's not a dupe :)
In any case, it seems that "Benefits" has also been added since the last HN discussion (revision history: http://martinfowler.com/articles/serverless.html#Significant...).
Re: Serverless Architectures
#6The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.
Re: Serverless Architectures
#7I'm cautiously optimistic that the vendor lock-in will fade away over time. Hopefully open source frameworks can provide a jQuery-like abstraction layer over all of the vendor-specific implementation details. Of course, there are lots of challenges when you start getting into deeper architectures - queues triggering layers of lambdas interacting with various caches and data stores. But I we'll see best practices emerge that help people keep things simple and flexible.
For testing it should be possible to run everything in a mock vendor system on your local machine - not that such a system exists today, but theoretically it could.
Overall, my sense is that Serverless architectures will never be useful for everyone. They'll always be better for smaller, simpler systems that don't see tons of traffic. The Serverless community should focus on these use cases. The thing is, there are tons and tons of apps that are over served by all the flexibility EC2 provides. And there is another set of unborn apps that haven't been created only because the barrier to setting up and managing the backend was a _little_ too high. I'm really excited to see serverless bring these apps to life.
Re: Serverless Architectures
#8If successful this could lead reduction in developers needed in companies that use say AWS lambda.
Re: Serverless Architectures
#9The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.
You may be misunderstanding the concept of Lockin. It says you are stuck with whichever vendor you used that created the lockin. Benefits of services always seem to increase. So, whatever benefits exist for a current service isn't worth forgoing all potential benefits of all future competitors. That's what lock-in creates. That's why it's always bad for anything meant long-term.
Now, short-term projects that can disappear in a few years or less have less risk for lock-in. We still see those disrupted on occasion when the vendor abruptly disappears. Users had to redo their work, which wouldn't have been necessary in lock-in free approach.
Re: Serverless Architectures
#10The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.
Well, the point is that the benefits don't outweigh the drawbacks because of the vendor lock-in. Whenever you hit a limitation there is NOTHING you can do. No duct tape! Also on long term the vendor roadmap may not align with your business(i.e. pricing, features etc). Do you have a migration roadmap? Of course you don't... you are already too busy dealing with the BaaS restrictions/APIs. Definitely BaaS have their place along with PaaS, DBaaS and IaaS but if you are locked-in to a specific vendor your options become quite limited very quickly. Maybe when something like Docker for BaaS appears I would reconsider this.
The BaaS is not really more than a framework with various constrains so there is nothing stopping you to implement your own BaaS on top of an existing PaaS(to avoid managing servers). I'm actually doing just this and it works well but I can see how Lambda or any other vendor offer would not work due the amount of customisation required.