6 ms·

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 serv

by adamors 10y ago

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.

autotune 10y ago
Container based architectures like Mesos are definitely being considered for production use, at least in the startup scene (look up jobs on AngelList for examples). Plenty of companies still sticking with the virtual server route though and plenty more who haven't even reached the virtual server stage yet. iRobot is a good case study for Lambda at least: https://twitter.com/awssummits/status/753325988717604864 https://twitter.com/awssummits/status/753325988717604864
stevekemp 10y ago
I think more bubble than substance for serverless, but I can easily see the appeal and expect that they'll become more useful over time. Certainly the idea of microservices is a good one, for me and a lot of my use-cases, and that's the start of the journey towards an API-gateway. (The big downsides being less control, and a central point of failure, obviously.) Containers I think are different, and are used in production a lot.
bio4m 10y ago
I wrote a set of internal use systems using Lambda and API Gateway. I'm in two minds about it; its handy but at the moment I dont think its mature enough for a critical live system. I'd like better ways to collect execution data for debugging and more visibility all round. With those it would definitely be a contender.
- cscharenberg 10y ago
  Indeed. Debugging them is painful at the moment. I'm using Apex to deploy a few and running "apex logs" gets me all recent logs, but that's pretty far from being actually debugging.
mintplant 10y ago
Serverless is pretty big in the PHP world, but people there tend to call it "shared hosting".
- takeda 10y ago
  That's quite good observation, I did not even thought about it. It's another marketing hype of just repackaging old solution with a cooler name.
- runako 10y ago
  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.
  - niftich 10y ago
    This, and, in shared hosting you're paying for an instance and if you overload your traffic or utilization you're done. 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.
  - kuschku 10y ago
    There used to be quite a few PHP hosts that billed by the request in the past, so, yes?
    - runako 10y ago
      Interesting -- would love to compare one of these to e.g. Lambda. Would you mind sharing a link to one of these services? 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.
michaelbuckbee 10y ago
I'm sure as a percentage of deployed products or services that a full serverless architecture is miniscule. What I have seen in production are systems made better by use of certain AWS/Lambda integrations. One crisp example of this is with S3 storage of images. When each new image it pushed into S3, S3 kicks off a Lambda function which resizes the image into thumbnails. This S3+Lambda system replaced a much more involved image processing pipeline with EC2, queues, a data store, etc. The end result was a system much easier to manage, support and reason about.
fragsworth 10y ago
Won't setting up good auto-scaling and deployment procedures result in something just like Lambda, but you had to orchestrate it yourself? It seems like there's a lot to be said for the cost and time savings of having it done for you...
- buckbova 10y ago
  Plus you don't have the cost of running all that infrastructure 24/7 to have the ability to scale or provide proper security.
JamesLeonis 10y ago
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 with all of AWS and event triggers are popping up all over their infrastructure. For me, Serverless is more about "not writing server boilerplate/provisioning" than "not having servers". The largest hurdle conceptually has been hoisting tangential concerns from the application into the infrastructure primitives. Here are some examples in my current work: * The API Gateway does routing, some payload modification for headers, as well as authentication and authorization. * I'm also relying more on security groups and specialized IAM roles instead of application specific authorization code. This leaves me with only the application specific code to be called. * Lambdas communicate with each other through SNS (and only when authorized via IAM). * All of my application code (currently) exists as Lambdas. This comes at a cost of infrastructure complexity and a learning curve. I'm also not using several services that AWS provides just to keep my cognitive load from exploding. Serverless Overall: Like exploring the jungles of Africa! Lots of really cool ideas and deployments, but here be lions! Containers are on the march of maturation. For me, the most useful part of Docker is decoupling the local application needs with the deployment environment. I exploit that decoupling to make sterile local development environments with Docker/Compose. The recent Docker OSX/Windows support smooths out the last few bumps in my dev workflow. The deployment, however, is still maturing. To be fair, it's mostly a distributed computation problem and not unique to Docker. Kubernetes is a bear, but an improving one. Same with E2C from what I've heard from friends. On a smaller scale, it significantly opens up the playing field for less popular languages/tools. Heroku's Docker support, for example, allows for any language to be deployed as long as it accepts the Docker contract. Docker Overall: a) Local is AWESOME! b) Deployment is the Wild West. Still largely unsettled but the Oregon Trail is OPEN!
- collyw 10y ago
  What are you building that needs to be split up in such a way? And how many people access the system?
akvadrako 10y ago
In my experience, they are steps towards the future. VM's are now the baseline; containers are better; server-less is even more so; something like Urbit is a step further. However, the level of maturity is reversed. Docker is usable now, but you will run into many quirks and inefficiencies. On top of that, it's not standardised in a meaningful way. Only starting this year would I choose it for a new project. Server-less is even less standard and efficient, but in five years I expect tooling to be usable, though still rough around the edges. For some reason, we can't just jump to the most ideal architecture but have to evolve there step by step. That's what I would say is the essence of the "worse is better" philosophy.
- collyw 10y ago
  Why do you define containers as better? Server-less even more so?
  - akvadrako 10y ago
    In my ideal situation, if I write a function, it's immediately usable wherever I want. As long as it's fast, reliable, scalable, inexpensive and all that jazz, I don't want to think about support infrastructure. Doing the infrastructure yourself has no benefit if it's done right - it's not the end goal. So server-less is closest to that ideal. Containers are better than VMs because they are faster and lighter weight. So much so, that people develop new ways of working that would be cumbersome with VMs.

by adamors 10y ago

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.

autotune 10y ago

Container based architectures like Mesos are definitely being considered for production use, at least in the startup scene (look up jobs on AngelList for examples). Plenty of companies still sticking with the virtual server route though and plenty more who haven't even reached the virtual server stage yet. iRobot is a good case study for Lambda at least: https://twitter.com/awssummits/status/753325988717604864 https://twitter.com/awssummits/status/753325988717604864

stevekemp 10y ago

I think more bubble than substance for serverless, but I can easily see the appeal and expect that they'll become more useful over time. Certainly the idea of microservices is a good one, for me and a lot of my use-cases, and that's the start of the journey towards an API-gateway. (The big downsides being less control, and a central point of failure, obviously.) Containers I think are different, and are used in production a lot.

bio4m 10y ago

I wrote a set of internal use systems using Lambda and API Gateway. I'm in two minds about it; its handy but at the moment I dont think its mature enough for a critical live system. I'd like better ways to collect execution data for debugging and more visibility all round. With those it would definitely be a contender.

cscharenberg 10y ago
Indeed. Debugging them is painful at the moment. I'm using Apex to deploy a few and running "apex logs" gets me all recent logs, but that's pretty far from being actually debugging.

mintplant 10y ago

Serverless is pretty big in the PHP world, but people there tend to call it "shared hosting".

takeda 10y ago
That's quite good observation, I did not even thought about it. It's another marketing hype of just repackaging old solution with a cooler name.
runako 10y ago
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.
- niftich 10y ago
  This, and, in shared hosting you're paying for an instance and if you overload your traffic or utilization you're done. 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.
- kuschku 10y ago
  There used to be quite a few PHP hosts that billed by the request in the past, so, yes?
  - runako 10y ago
    Interesting -- would love to compare one of these to e.g. Lambda. Would you mind sharing a link to one of these services? 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.

michaelbuckbee 10y ago

I'm sure as a percentage of deployed products or services that a full serverless architecture is miniscule. What I have seen in production are systems made better by use of certain AWS/Lambda integrations. One crisp example of this is with S3 storage of images. When each new image it pushed into S3, S3 kicks off a Lambda function which resizes the image into thumbnails. This S3+Lambda system replaced a much more involved image processing pipeline with EC2, queues, a data store, etc. The end result was a system much easier to manage, support and reason about.

fragsworth 10y ago

Won't setting up good auto-scaling and deployment procedures result in something just like Lambda, but you had to orchestrate it yourself? It seems like there's a lot to be said for the cost and time savings of having it done for you...

buckbova 10y ago
Plus you don't have the cost of running all that infrastructure 24/7 to have the ability to scale or provide proper security.

JamesLeonis 10y ago

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 with all of AWS and event triggers are popping up all over their infrastructure. For me, Serverless is more about "not writing server boilerplate/provisioning" than "not having servers". The largest hurdle conceptually has been hoisting tangential concerns from the application into the infrastructure primitives. Here are some examples in my current work: * The API Gateway does routing, some payload modification for headers, as well as authentication and authorization. * I'm also relying more on security groups and specialized IAM roles instead of application specific authorization code. This leaves me with only the application specific code to be called. * Lambdas communicate with each other through SNS (and only when authorized via IAM). * All of my application code (currently) exists as Lambdas. This comes at a cost of infrastructure complexity and a learning curve. I'm also not using several services that AWS provides just to keep my cognitive load from exploding. Serverless Overall: Like exploring the jungles of Africa! Lots of really cool ideas and deployments, but here be lions! Containers are on the march of maturation. For me, the most useful part of Docker is decoupling the local application needs with the deployment environment. I exploit that decoupling to make sterile local development environments with Docker/Compose. The recent Docker OSX/Windows support smooths out the last few bumps in my dev workflow. The deployment, however, is still maturing. To be fair, it's mostly a distributed computation problem and not unique to Docker. Kubernetes is a bear, but an improving one. Same with E2C from what I've heard from friends. On a smaller scale, it significantly opens up the playing field for less popular languages/tools. Heroku's Docker support, for example, allows for any language to be deployed as long as it accepts the Docker contract. Docker Overall: a) Local is AWESOME! b) Deployment is the Wild West. Still largely unsettled but the Oregon Trail is OPEN!

collyw 10y ago
What are you building that needs to be split up in such a way? And how many people access the system?

akvadrako 10y ago

In my experience, they are steps towards the future. VM's are now the baseline; containers are better; server-less is even more so; something like Urbit is a step further. However, the level of maturity is reversed. Docker is usable now, but you will run into many quirks and inefficiencies. On top of that, it's not standardised in a meaningful way. Only starting this year would I choose it for a new project. Server-less is even less standard and efficient, but in five years I expect tooling to be usable, though still rough around the edges. For some reason, we can't just jump to the most ideal architecture but have to evolve there step by step. That's what I would say is the essence of the "worse is better" philosophy.

collyw 10y ago
Why do you define containers as better? Server-less even more so?
- akvadrako 10y ago
  In my ideal situation, if I write a function, it's immediately usable wherever I want. As long as it's fast, reliable, scalable, inexpensive and all that jazz, I don't want to think about support infrastructure. Doing the infrastructure yourself has no benefit if it's done right - it's not the end goal. So server-less is closest to that ideal. Containers are better than VMs because they are faster and lighter weight. So much so, that people develop new ways of working that would be cumbersome with VMs.