211–220 of 670 posts
Dare I say that it might even be possible to run twitter at scale with just a simple NoSQL database and some scripts?
Serverless is really just a specialized niche of PaaS. Smaller lighter functionality akin more to scripts rather than full applications, with more billing and scaling flexibility, and typically leveraging other cloud services to get things done. Another big reason it's stalled is because PaaS has rapidly improved and now deploying a Docker container running whatever you want is just as fast and easy. No need for all…
I tend to agree. This is not helped by the fact that cloud providers are approaching (and even in some cases surpassing) the complexity and price of running standard compute instances again. It can be a lot trickier to navigate the nuances of ECS+Lambda than it is to run standard EC2 instances. Even GCP is not immune, though I find it better in these areas, a common problem I have with cloud run for instance; is cont…
I've never had to do anything special to access Firestore for instance.
"Limited Programming Languages" AWS Lambda can run all programming languages via layers. Cloudflare Workers can run all programming languages that compile to WebAssembly. "Vendor Lock" True, but being locked into Kubetnetes isn't a cakewalk either. "Performance" Cold-starts aren't a thing for Cloudflare Workers and can be mitigated for AWS Lambda. AppSync and API Gateway don't even have them if you directly integrate…
> AppSync and API Gateway don't even have them if you directly integrate with AWS services. I was quite impressed when I exposed Kinesis via API Gateway, it just worked, although the Kinesis requirement that data be b64 encoded did require some fiddling about with mapping templates.
Sure, a container is better than a serverless function in many ways, but the function isn't what the container is competing with.
I love how we're going back to PHP's original model (effectively stateless "functions") and giving it a hot new name. People have tried to convince me (unsuccessfully) that this is entirely different. Somehow. If you really want serverless, install apache with mod_php and call it a day.
Ok, but do I have to update this host? Do I have to pay for it when it's not being used? How quickly can I quadruple my capacity?
If you already have a server somewhere you could consider spinning up a container instance or kubernetes ( assuming you have at least linux 1 server with excess ram available )
If you deploy your service on kubernetes than you should be able to scale effectively.
I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to th…
Infrastructure is always much harder to maintain (and test) than application code. Serverless architectures can risk moving complexity from (easy-to-test) application code to (hard-to-test) infra.
Actually, re-reading your comment, I'm not sure what you were trying to say. I may be agreeing with you.
---
I think it is possible for serverless to supplant PaaS et al, but I don't know if it's quite mature enough yet.
Is there a way to use one "serverless" framework in one place and then use another in another place?
For example, I love dokku. It is so easy to have the heroku like experience on the cheap.
But I wonder: what happens if I need to scale my application bigger than the dokku server it's on right now? I really like the immediate prototyping possibilities of dokku but the long term plan seems less exact when I read their documentation.
So, is anyone else using dokku locally and Google Cloud Run globally? Or another combination?
This is why I dislike firebase (maybe this has changed). It's incredibly powerful, magic. But, you have to go all in both locally and globally, and there were gaps that caused me a lot of pain.
The tendency would be to use a framework that gives you the best of both worlds, local/dev plus production.
But, why couldn't we use the best solution in one place and the other best solution in another.
Is that a naive question?
I've read through a bunch of comments but don't see anything to answer this question. Is there a way to use one "serverless" framework in one place and then use another in another place? For example, I love dokku. It is so easy to have the heroku like experience on the cheap. But I wonder: what happens if I need to scale my application bigger than the dokku server it's on right now? I really like the immediate protot…
Earlier quoted context omitted.
Yes, it (Python) was chosen because we could leverage existing internal code that was written in Python and it happens to be my strongest language. If I could do it all over, I would still choose Python. That being said, I have been working professionally (building apps like this) for almost 14 years so my willingness to bite off a homebrew Python framework endeavor as I did here is a lot different than someone just…
Could you elaborate on why you dislike Django? Would be great to hear from someone with extensive Python experience.
Earlier quoted context omitted.
> Serverless provides a solution for that case as well, since you have almost unlimited resources. Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic. Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.
multiple seconds?? what platform?
It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together):
* Want to run a quick ETL process to refresh some tables or pull some data down from a third-party endpoint?
* Want to expose a quick usage report for the project manager?
* Want to send a slack message when a build finishes from TeamCity so QA can jump on it?
* Want to monitor the rate of Crashlytics logs and send a warning to slack if it breeches a threshold?
There are tons of "one-off" little processes that now just automatically run and don't require server upkeep. Most of them are functionally independent, so having them as separate functions makes sense (when we do need to coordinate, that's done through Step Functions).
Note: I still don't think that they are a great fit for production services (and more fits one-off and cron usage patterns)