201–210 of 215 posts
Compare to working with level of abstraction of "entity" (function, could be bigger) and have it running when needed and scale as needed.
Aren't we kind of already there (serverless)? A lot of web frameworks enforce the shared-not-that-much (not quire "shared nothing", but close) style of programming where every HTTP request is essentially just an "event" that hooks into a controller-handler? And if you want anything to stick around from one request to the next, you keep it in memcache/db/BaaS/third-party service, not your own process? I don't think th…
Earlier quoted context omitted.
> If history is a guide. Could you elaborate on this ? I agree the size and complexity could increase, but so could the number features in the apps. Since all such apps would be reusing the same code base, wouldn't this increase abstraction and reduce implementation hours ?
I think it's something like a big monolithic app is less complex than a n-tier client server app which is less complex than a microservices distributed app which could be less complex than a purely FaaS implemented app, yet to be determined.
The main problem I see here is the problem we run into with every hot new abstraction of a thing that some people find troublesome as developers. Someone already mentioned virtual hosting. I'd like to bring up ORMs. There's this idea that you can forget about the datastore--abstract it away, manage it in code, whatever. You don't have to learn about databases, table structures, or SQL if you don't want to. Just think…
I honestly think people should learn to build standard apps the standard way - (SQL) database, application layer, html / view layer -then learn to scale the parts as needed. Its well understood. There are good frameworks and tools available and plenty of historical examples of how to do things.
Everyone seems to want to jump on the shiny new way of doing things as soon as they come out. I often ask peoples reason for choosing their architecture - "thats how we do things these days" or "relational databases don't scale" seem to be the standard answers.
Please, let's not accept this redefinition of a fundamental and well known term.
Earlier quoted context omitted.
Is it cost effective? I mean roughly.
Very very cheap, as long as you're writing your lambdas as performant as possible we've costed our app at ~2c / user / month with heavy api / database / lambda usage
Earlier quoted context omitted.
Lock-in is fine if it has value.
People keep saying that without a context. Non-lock-in usually has value too. Many times for similar or lower cost. And with way less risk. So, the question instead is "With these requirements, which products and services meet them with good, cost-benefit analysis? And which is best when benefits and liabilities are considered?"
I have seen people waste precious time and energy on "open" solutions, and lose focus on other, important things. I'd rather be stuck extricating myself from some lousy vendor relationship than not selling my product.
For my first serverless project, I built a service that manages an advertising account, by analysing ads and optimising the spend spread for a configured goal. I was surprised to find that one of the most difficult aspects, was in throttling outgoing API requests. Basically, I needed to avoid abusing a 3rd party service by hammering it with parallel or rapid fire requests. I discovered all kinds of weird solutions: -…
> "- Push a "please wait" message onto an SQS queue, and set a Cloud watch alarm to fire when the queue length was >= 1 for at least one second. Have a variety of lambdas respond to the alert by checking if the have any work to do, and then racing to pop the queue and do one operation. I think I needed SNS in there too, for some reason. Fanout?" Did you want AWS Kinesis? The integration with Lambda polls the queue ev…
In the spirit of treating this like Lego, I suppose that maybe I could have uses SES to email itself an HTTP request description, and counted on the email lag to keep requests spread out over time. But at this point, things are getting so weird that I think it's time to just admit that "work on something at a specific pace, then go to sleep for a few hours" isn't the sort of task that the serverless architecture is well suited for. Serverless is for tasks that you want done on demand, as quickly as possible, imo.
Earlier quoted context omitted.
> "- Push a "please wait" message onto an SQS queue, and set a Cloud watch alarm to fire when the queue length was >= 1 for at least one second. Have a variety of lambdas respond to the alert by checking if the have any work to do, and then racing to pop the queue and do one operation. I think I needed SNS in there too, for some reason. Fanout?" Did you want AWS Kinesis? The integration with Lambda polls the queue ev…
I did look at Kinesis too, but for my use case, it didn't really help much over SQS. There is still no way to put a Kinesis event "in the future" so that I won't see it for a second, and I would have had to set the batch size to 1, if I was using Kinesis as a means to throttle an activity. In the spirit of treating this like Lego, I suppose that maybe I could have uses SES to email itself an HTTP request description,…
Earlier quoted context omitted.
Parent post didn't say anything about abstracting away "serverless". Lock-in refers to (as the OP article discusses) the fact that if you use AWS Lambda, you are tied to their APIs and deploy mechanisms. If you want to move to Google's FaaS offering, you have a lot of work to do, and may need to restructure your app logic as well.
And that's wrong; a complete misunderstanding of how both serverless in general and Lambda specifically works. You provide an entry point to your application. AWS provides you with an `event` and `context` object, both of which are nonstandard. You extract, out of those objects, the data you care about... and you pass it down to whatever it is you want to run. The extraction is very simple. Here, take a look at a SNS…
If you've designed your client-side javascript (or swift or whatever it is) properly, you've abstracted out the API calls to say, AWS Lambda, and wrapped them such that the implementation is not tightly coupled to the calling code. Eg you write a generic Storage class and call Storage.Save, which wraps whatever API you use to save stuff, be it Lambda or otherwise. Change vendor and you just change your Storage class's implementation without needing to alter client functions..