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.
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
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.
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.
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.
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.
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.
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.
I've been writing PHP for almost a decade and I've never come across any PHP hosts that bill by the request. Not explicitly, anyway -- there were always those hosts where if you got over some threshold of traffic and it caused a certain amount of load on the servers, they'd cut you off with no warning/notice. Those hosts suck. Never seen anything like Lambda for PHP, though. Care to share?
Well, there was a host – they shut down years ago, though – which did it.
And there were always the kind of hosts which had no quota, and no fee, but where you’d pay based on how much you wanted to in a given month, but you’d be expected – honor system – to pay more the more you used, with a rough formula how much would be expected from you (but you’d never be terminated).
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.
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!
> What are you building that needs to be split up in such a way?
"Need" is such a fickle word...
I'm using the Lambdas to build an event sourced system on top of microservices. Because I can hoist so much infrastructure from each service, it makes each service significantly easier to write and manage. This allows the application specific code to change without rewriting the routing/auth(z)/provisioning code along the way. I can even rip out whole services and the others are blissfully unaware.
Because Lambdas are only charged when invoked, it keeps the costs down. RDS is my biggest expense by far, but I'm under a Standard 1X Heroku instance. If you have a service that isn't used much, Lambda's can bring your costs to near-zero. An added benefit is I can be fairly liberal with deployed lambdas because I'm not thinking about machine/hour costs. Multiple staging environments? SURE!
After a little while in the Lambda world, I started to see them as little lightweight workers. They can be told to listen to nearly anything under the AWS umbrella, and AWS is _chatty_. Pair it up with the API gateway and you can build 3rd party integrations. Before I had to set up a TON of infrastructure to have these abilities. It's pretty liberating.
Finally, I feel like the ideas in Serverless are both interesting and not well explored. I hope to share what I've found with others as we chart this new territory.
> And how many people access the system?
I'm not sure about what you mean by people. Users? Developers? I'll answer both.
For now I'm the only developer, but I expect that to change within a year. The local Docker powered dev environment keeps me sane with a simple `docker-compose up -d` to bring it up. The infrastructure hoisting significantly reduces the service's LOC, making them easier to grok. Isolated development environments and very light mocking ease local development and testing. I do pay a penalty when doing integration tests locally, however, but I'm punting that into my staging environment for the moment.
I have some pre-alpha users that are helping me shape the product. I admit at first glance it looks foolish/overkill/wat for my user size. Before Lambda, this architecture _would_ be too complex, and pricing would be prohibitively expensive, for the size of the product as it exists. That's what Lambda (and Serverless in my mind) brings to the table. It leans on Cloud Infrastructure and it's charge-by-use model to bring architectures like microservices to the hobbyist and small businesses. As the tooling and docs improve, I expect it to further blur the lines in "DevOps".
Could you tell I'm a little excited by Serverless/Lambdas?
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.
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.
Migration between infrastructures is always painful, so I don't think vendor lock in is that big a deal, if you keep APIs small and their I/O well documented (and designed).
Migration between a OVH VPS, a local server, or a Hetzner rootserver is not really painful.
I choose a preinstalled distro, deploy my script to automatically handle dependencies and set up the container infrastructure, pull the containers, and I have a server set up and able to run my containers in about 3 minutes, and connected to a central server so it can be provisioned containers to run.
The entire infrastructure can obviously be moved to another hoster in days, because the hoster is just providing a machine.
> Migration between infrastructures is always painful, so I don't think vendor lock in is that big a deal, if you keep APIs small and their I/O well documented (and designed).
hmm, not if the only thing you have to do it upload an image on a server, there is nothing difficult with it. And yes the vendor lock in is a big deal unless all you write is throw away code. But it looks like it's the purpose of "Serveless servers", throw away apps ...
That's a bit different, you have a different technology (although it still contains a key as a backup) and call it 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.
Not if you build things in a thoughtful way. The code behind a REST call shouldn't really be all that different when deployed to Lambda vs run in a standalone binary on a rackspace server.
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.
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 with over 20 hibernate/ebj beans . The load time was horrendous. I had to eliminate all beans not needed by the microservice.
I did the Alexa Skill tutorial[1] and hosted the skill on AWS Lambda. It was really easy, fun, and I recommend it to anyone who wants to mess around with Lambda.
If anyone is not interested in vendor lock-in to Amazon for Lambda and API Gateway, I just released an open-source multi-language microservice backend today.
Is it feature-compatible with Lambda? Like can I take a Lambda and run it via this stack? As a Lambda user the reality is, sure, at the moment there is a bit of vendor lock-in, but I don't think at all about hardware, which is the point.
This specific tool `stack` has a minimal feature-set for taking a function in any language and putting it on an HTTP endpoint. Nothing else included ( by design ).
It supports the same style of coding microservices as Lambda, except `stack` also provides actual HTTP streaming interfaces.
> There seems to be some issue applying privileges that I can't seem to figure out. Your lambda function will fail to execute because API Gateway does not have permissions to execute your function.
This stuff is definitely confusing. I think I "reverse-engineered" from applying things via the web interface and then looking at the policy when I created Gimel[0] - an AWS Lambda A/B testing backend. Take a look here[1] for the policy. I think that's what you're looking for, but I can't say I'm confident it is... (it's confusing).
There are some more general-purpose tools to help you deploy to Lambda. Kappa[2] and Apex[3] are worth looking into.
How in the world is this considered something new? It was in fact the default mode of operation for small to midscale webhosting that rendered pages dynamically in the dotcom bubble burst era (late 1990-ies).
You'd upload your HTTP attached executables to cgi-bin or similar, register other stuff in crontab and usually also got access to a MySQL or PostgreSQL. Some hosters were actually fancy and deploy your stuff on a MOSIX cluster; but simply load balancing toward the httpd machines and your application talking to a dedicated DB machine worked as well.
My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php.
Generally if you were in a shared hosting environment, your DB and webapp lived on the same physical server (Probably a Cobalt RAQ or Netra T1, but maybe a Sun Ultra AXi in an ATX case on a bread rack). Rarely was there any form of multi-host redundancy for a given application. If something broke, you're down while the hosting company swaps disks to a new chassis, and down even longer when the disks die and you need to reproduce the app config/state changes that happened in the 2 days since the last server backup happened.
> My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php.
At the core of it this is not so different.
> So yeah. This is a slightly different model.
No, not really. What's changed is our understanding of how to run this kind of infrastructure. And we now have a little bit more sophistication in how we organize process runtime environments (sandboxes, cgroups on Linux, jails on FreeBSD). But if you tear down all the PR and get past the nice decoration it boils down to a glorified shell access.
Back in the boom it sucked because nobody knew then, how to do these things properly.
I recently threw together a benchmark to measure latency with different requests per second and request concurrency. It bypasses API gateway and just calls the lambda directly. The p50 is very close to the minimum latency I can see to US-WEST-2.
Lambda seems like a neat concept, but is it really worthwhile? Conceptually, an infinitely scalable backend for whatever thing I'm working on sounds great, but in practice, there are some downsides. For instance, your client requests hits the API Gateway, which then initiates another HTTP request to whatever Lambda is supposed to be called, at which point, a container is started to run your code. By this point, you've added some overhead to every single request, and it's completely impossible to get rid of it because that's how Lambda is designed. Am I off base here? Does it really work like that? If so, what's the performance hit that you've seen compared to running e.g. ExpressJS directly on a VM or bare metal?
The idea is that containers are started to support the load of your application. If the load of your application is so low you have zero containers running most of the time you're not the target audience for this kind of service.
If you have zero containers running most of the time, AWS Lambda is attractive because it costs $0 when there is no activity, unlike instances that costs all the time even when idling.
Sure, but even if your traffic is bursty, this would be a problem, no? If one container is already running and you suddenly need ten containers, that delay is still present.
Also, I'm not sure your assertion is accurate. Amazon's entire selling point around Lambda is that you don't pay for the time that your code isn't running, which implies that the service was built around not having code running sometimes. If my code was going to be running all the time anyway, why not just run an EC2 instance?
54 comments
[ 1.8 ms ] story [ 123 ms ] threadCertainly 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.
I'd like better ways to collect execution data for debugging and more visibility all round. With those it would definitely be a contender.
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.
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.
And there were always the kind of hosts which had no quota, and no fee, but where you’d pay based on how much you wanted to in a given month, but you’d be expected – honor system – to pay more the more you used, with a rough formula how much would be expected from you (but you’d never be terminated).
Then again, here a lot of things are honor model or volunteer based, and society still works.
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.
It seems like there's a lot to be said for the cost and time savings of having it done for you...
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!
"Need" is such a fickle word...
I'm using the Lambdas to build an event sourced system on top of microservices. Because I can hoist so much infrastructure from each service, it makes each service significantly easier to write and manage. This allows the application specific code to change without rewriting the routing/auth(z)/provisioning code along the way. I can even rip out whole services and the others are blissfully unaware.
Because Lambdas are only charged when invoked, it keeps the costs down. RDS is my biggest expense by far, but I'm under a Standard 1X Heroku instance. If you have a service that isn't used much, Lambda's can bring your costs to near-zero. An added benefit is I can be fairly liberal with deployed lambdas because I'm not thinking about machine/hour costs. Multiple staging environments? SURE!
After a little while in the Lambda world, I started to see them as little lightweight workers. They can be told to listen to nearly anything under the AWS umbrella, and AWS is _chatty_. Pair it up with the API gateway and you can build 3rd party integrations. Before I had to set up a TON of infrastructure to have these abilities. It's pretty liberating.
Finally, I feel like the ideas in Serverless are both interesting and not well explored. I hope to share what I've found with others as we chart this new territory.
> And how many people access the system?
I'm not sure about what you mean by people. Users? Developers? I'll answer both.
For now I'm the only developer, but I expect that to change within a year. The local Docker powered dev environment keeps me sane with a simple `docker-compose up -d` to bring it up. The infrastructure hoisting significantly reduces the service's LOC, making them easier to grok. Isolated development environments and very light mocking ease local development and testing. I do pay a penalty when doing integration tests locally, however, but I'm punting that into my staging environment for the moment.
I have some pre-alpha users that are helping me shape the product. I admit at first glance it looks foolish/overkill/wat for my user size. Before Lambda, this architecture _would_ be too complex, and pricing would be prohibitively expensive, for the size of the product as it exists. That's what Lambda (and Serverless in my mind) brings to the table. It leans on Cloud Infrastructure and it's charge-by-use model to bring architectures like microservices to the hobbyist and small businesses. As the tooling and docs improve, I expect it to further blur the lines in "DevOps".
Could you tell I'm a little excited by Serverless/Lambdas?
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.
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.
I choose a preinstalled distro, deploy my script to automatically handle dependencies and set up the container infrastructure, pull the containers, and I have a server set up and able to run my containers in about 3 minutes, and connected to a central server so it can be provisioned containers to run.
The entire infrastructure can obviously be moved to another hoster in days, because the hoster is just providing a machine.
hmm, not if the only thing you have to do it upload an image on a server, there is nothing difficult with it. And yes the vendor lock in is a big deal unless all you write is throw away code. But it looks like it's the purpose of "Serveless servers", throw away apps ...
BTW: I really hate the marketing inventions. There's no cloud, or serverless, you still run your software on someone's server.
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.
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.
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.
[1]https://developer.amazon.com/public/community/post/TxDJWS16K...
https://github.com/Stackvana/stack
Cheers!
It supports the same style of coding microservices as Lambda, except `stack` also provides actual HTTP streaming interfaces.
Check out the echo examples here: https://github.com/Stackvana/stack/tree/master/examples/serv...
An additional interface over `stack` could be used to support any cloud function style ( including Lambda's )
This stuff is definitely confusing. I think I "reverse-engineered" from applying things via the web interface and then looking at the policy when I created Gimel[0] - an AWS Lambda A/B testing backend. Take a look here[1] for the policy. I think that's what you're looking for, but I can't say I'm confident it is... (it's confusing).
There are some more general-purpose tools to help you deploy to Lambda. Kappa[2] and Apex[3] are worth looking into.
[0] https://github.com/Alephbet/gimel
[1] https://github.com/Alephbet/gimel/blob/master/gimel/deploy.p...
[2] https://github.com/garnaat/kappa
[3] https://github.com/apex/apex
You'd upload your HTTP attached executables to cgi-bin or similar, register other stuff in crontab and usually also got access to a MySQL or PostgreSQL. Some hosters were actually fancy and deploy your stuff on a MOSIX cluster; but simply load balancing toward the httpd machines and your application talking to a dedicated DB machine worked as well.
My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php.
Generally if you were in a shared hosting environment, your DB and webapp lived on the same physical server (Probably a Cobalt RAQ or Netra T1, but maybe a Sun Ultra AXi in an ATX case on a bread rack). Rarely was there any form of multi-host redundancy for a given application. If something broke, you're down while the hosting company swaps disks to a new chassis, and down even longer when the disks die and you need to reproduce the app config/state changes that happened in the 2 days since the last server backup happened.
So yeah. This is a slightly different model.
At the core of it this is not so different.
> So yeah. This is a slightly different model.
No, not really. What's changed is our understanding of how to run this kind of infrastructure. And we now have a little bit more sophistication in how we organize process runtime environments (sandboxes, cgroups on Linux, jails on FreeBSD). But if you tear down all the PR and get past the nice decoration it boils down to a glorified shell access.
Back in the boom it sucked because nobody knew then, how to do these things properly.
https://github.com/spullara/lambdabenchmark
Also, I'm not sure your assertion is accurate. Amazon's entire selling point around Lambda is that you don't pay for the time that your code isn't running, which implies that the service was built around not having code running sometimes. If my code was going to be running all the time anyway, why not just run an EC2 instance?