31–40 of 55 posts
Are serverless and container based architectures really that popular in the real world, or is it yet another HN bubble? I'm still happy using virtual/cloud servers for anything/everything.
Serverless is pretty big in the PHP world, but people there tend to call it "shared hosting".
Are serverless and container based architectures really that popular in the real world, or is it yet another HN bubble? I'm still happy using virtual/cloud servers for anything/everything.
Here are my opinions from working with both over the last year: Serverless is brand new, and has all the burrs of a freshly cut service. Expect sharp corners, like bizarre documentation and lack of examples. I think it goes without saying that tooling and Best Practices are still immature. In my work (Lambdas) I've found they do well when organizing small pieces of work and event driven systems. They really do talk w…
Are serverless and container based architectures really that popular in the real world, or is it yet another HN bubble? I'm still happy using virtual/cloud servers for anything/everything.
Serverless is pretty big in the PHP world, but people there tend to call it "shared hosting".
Serverless is just shared hosting like S3 is just FTP.
Earlier quoted context omitted.
If you want to run it in aws you will still have to run it on a server. BTW: I really hate the marketing inventions. There's no cloud, or serverless, you still run your software on someone's server.
I hear ya. The keyless entry on my Prius still requires me to carry a key.
Anyway the serverless is essentially (as someone here pointed out) the same idea as shared hosting which is very popular with php. It just uses a different name.
Earlier quoted context omitted.
Serverless is pretty big in the PHP world, but people there tend to call it "shared hosting".
Are there shared PHP hosts that bill by the request? TFA indicates that is a key difference of serverless, and why it's not shared hosting. The billing model matters to some users as much as the implementation. Serverless is just shared hosting like S3 is just FTP.
In 'serverless' (awful, awful marketing name for function-calls-as-a-service), your computation will be executed on one among a pool of executor units from which you are abstracted away from; therefore in theory your throughput scales to accommodate demand (impacts on your wallet notwithstanding).
But this is there the name comes from -- there's no 'server' as in, a box you can ssh or sftp into and muck around with files or configurations.
Earlier quoted context omitted.
Serverless is pretty big in the PHP world, but people there tend to call it "shared hosting".
Are there shared PHP hosts that bill by the request? TFA indicates that is a key difference of serverless, and why it's not shared hosting. The billing model matters to some users as much as the implementation. Serverless is just shared hosting like S3 is just FTP.
Earlier quoted context omitted.
Are there shared PHP hosts that bill by the request? TFA indicates that is a key difference of serverless, and why it's not shared hosting. The billing model matters to some users as much as the implementation. Serverless is just shared hosting like S3 is just FTP.
There used to be quite a few PHP hosts that billed by the request in the past, so, yes?
Edit: Also, as a peer comment pointed out, Lambda (and the like) have other differences from traditional shared hosting as well. I'm not convinced Lambda is all that similar to the shared hosting I remember from the '90s.
In case someone is looking to move their java REST server to Lambda, here are a few lessons I learnt: a) fragment your REST war into smaller micro services wars. The load time for big REST application will impact your caller. Small micro services will boot up on Lambda much faster and respond quicker. b) If you use spring dependency injection, you may want to rethink that and tweak/optimize it. I had a database tier…
Also if you're going to use spring check out this guide. https://cloud.google.com/appengine/articles/spring_optimizat...
its relevant to aws lambda as well.
In case someone is looking to move their java REST server to Lambda, here are a few lessons I learnt: a) fragment your REST war into smaller micro services wars. The load time for big REST application will impact your caller. Small micro services will boot up on Lambda much faster and respond quicker. b) If you use spring dependency injection, you may want to rethink that and tweak/optimize it. I had a database tier…
aka "Going towards total vendor lock in by basing your system on a proprietary, non portable infrastructure service"
Check out Serverless https://github.com/serverless/serverless . It'll work for Lamba, google cloud, Azure, and IBM Whisk
If you look at AWS's own framework Chalice https://github.com/awslabs/chalice it basically has you import Chalice where you would otherwise import flask, making it fairly easy to switch to hosting yourself later if you want.