13 ms·

Microservices without the Servers

273 points by alexbilbie 11y ago

xchaotic 11y ago
It is pretty cool but not really serverless, you are still handling http requests via Amazon API gateway and in general you are relying and paying for quite a lot of Amazon services. Not sure how much better this approach is to serving image magic via PHP for example, it would be good to see some numbers.
- philsnow 11y ago
  This removes nearly all of "devops". You don't have to mess around with figuring out how many ec2 instances you need (or deal with auto-scaling groups), how to secure the linux or whatever you stick on the ec2 instances, etc. There's still a ton of creating zip file artifacts of your lambda payloads (instead of pushing to a magic git repository that amazon controls, say), so there's a bit of "build monkey"ing to do instead of "devops"ery. But I think a lot of shops will be happy to make that trade, as "build" is closer to their core experience than "devops".
  - maratd 11y ago
    Yes, you get rid of devops. You gain vendor lock-in. You are now tied to the Amazon platform. If they shut down or suspend your account, for any reason, you are out of business. You are also paying premium for the platform, with the cost of devops built in. I'll take an open ecosystem that gives me options to migrate my business anytime over a proprietary solution.
    - curiousjorge 11y ago
      pretty much this. amazon can at any point shut down any of these services or nerf it. if you built everything up to this point on amazon and they shut it down, it's more work.
      - maratd 11y ago
        To add to your point, they have done this before and are still doing it. There is no guarantee of continued service. http://recode.net/2015/03/18/amazon-will-shut-down-amazon-webstore-its-competitor-to-shopify-and-bigcommerce/ http://recode.net/2015/03/18/amazon-will-shut-down-amazon-we...
        duskwuff 11y ago
        Amazon Webstore wasn't part of AWS, though. It was part of their commerce wing - very different.
        curiousjorge 11y ago
        remember PiCloud? they shut down after I spent a quarter building around their API calls. I never want to repeat that mistake and you also get the bonus of being able to sell your source code or deploy local cloud if an enterprise are willing to pay extra for it.
    - andyidsinga 11y ago
      There's always this tension, its really interesting. I think the open ecosystem approach will work well for apps/systems that are more established and have a predictable and sustainable user base and related revenue stream to maintain the system. But for new ideas, early stage startups, the open eco-system approach will be a lot more work than using the high-level services providers like amazon are developing ...basically a no-stack approach can help one quickly find some product / market fit. Once some level of baseline level of utilization is understood then switching to a more difficult, but less-locked in approach would be smart. all that said, there's probably a middle ground here too (but arguably not) -- where one deploy's using docker containers, private registry & image repo, s3 for static immutable storage and some open database like PostgreSQL on RDS. All that could be layered on top of AWS and other providers -- but it will still be a PITA to move the whole thing. BTW -- take a look at the elasticbox product -- they really have an interesting approach to cloud that sort of obviates the lock-in issue by allowing one to build apps across clouds from the start using their "boxes" metaphor.
  - treve 11y ago
    I'd say that most people don't need auto-scaling, and this configuration is almost definitely harder to understand and learn than a simple php script that works everywhere.
    - jshen 11y ago
      NO it's not harder to understand. If you are doing anything remotely serious, then your php script needs to be on multiple servers for redundancy, it needs to be behind a load balancer, you have to be responsible for the security of the VMs the php script runs on, and on and on and on and on. Edit: well, unless you run your php script in a PaaS like Google App Engine.
      - treve 11y ago
        Yet, most people probably still FTP their php files onto a shared hosting environment. And for most people, that's actually good enough.
  - NDizzle 11y ago
    Maybe this statement will date me, but I don't really like this trend of having to deal with less things. I mean, sure, it's more simple to get started. But when things break you are screwed because nobody really knows what is going on.
  - andyidsinga 11y ago
    yep -- the devops part is valuable on the app creator/dev's side and this architecture is very valuable on the amazon/cloud service provider's side too. The smaller the scheduled unit of code is, the more densely they can pack the workloads and make more efficient use of their system ...squeezing out the pennies at their scale makes a lot of sense. I've seen some vendor lock in comments here -- but certainly the big 3 or 4 service providers will have these features figured out soon - and seems to me some open source to schedule functions across compute will appear in no time that could be used by the smaller providers. replicating all the other features is much harder -- this is a great moat amazon has built.
  - rycfan 11y ago
    Sorry, this is actually factually incorrect. As shown in another thread here, this service does not infinitely auto-scale (the recommendation was to use Kinesis), so you still have to know which services to choose, which is pretty much a full-time job with the number of different services offered these days.
- ahallock 11y ago
  The point is you don't provision your own servers, not that servers don't exist somewhere executing your code. People seem to be taking the marketing too literally.
  - larrys 11y ago
    It's good add copy and ranks high on the link-bait scale. They say after all: "and then unit and load tested it, all without using any servers." ...with a title of "Microservices without the Servers" when what they mean is "without provisioning any servers yourself" which is obviously much less attractive. My curiosity was peaked by the title the title, inserting "w/o provisioning" would have not gotten me anywhere near as interested in the topic.
    - angrow 11y ago
      Would you apply the same analysis if I claimed I could buy a t-shirt from a store without using any factories?
  - logn 11y ago
    No it's not taking this too literally. I re-read the architecture a few times then stepped through the source to make sure I wasn't missing something. I was thinking that maybe the servers were only used to deploy the image processing code to the client which could then run the code locally. But that's not the case. Serverless implies that a server is not required after an installation step and that you only need your local device. Or perhaps too that you only need a collection of like clients to do something P2P. Just because you as the developer don't have to think about the server doesn't make it serverless.
hackaflocka 11y ago
This is a misleading title. Managed cloud services run on servers. There has to be a better title. For a moment I thought they were proposing P2P hosting.
- ahallock 11y ago
  The implication is that you don't have to provision any servers to execute your code. That is the "serverless" part.
  - turing_bot_3c 11y ago
    But the name is terrible. It is like saying, going from A to B without a car by using a Taxi.
- stefantalpalaru 11y ago
  That's what you get when marketing relabels the cluster as "cloud" and a VPS interface as a "compute service". You start thinking it's buzzwords all the way down :-)
cptnbob 11y ago
Too much vendor lock in. Will keep my VMs thanks.
- bpicolo 11y ago
  Yeah, that's what I think too. This feels too far into the vendor-lockin, downtime death zone, as reliable as Amazon might be. Plus, while it might be cool for some microservices, it seems like it would be a lot more unwieldy trying to do a full scale application.
- SideburnsOfDoom 11y ago
  And language lock-in. So far Lambda supports only Node.js and Java.
  - brianwawok 11y ago
    Java gets you ruby via JRuby and Python via Jython... (Not sure how current they are these days). So missing C and Rust type stuff I guess?
    - alexbilbie 11y ago
      The AWS Lambda team wrote a blog post about how to use Python - https://aws.amazon.com/blogs/compute/using-python-in-an-aws-lambda-function/ https://aws.amazon.com/blogs/compute/using-python-in-an-aws-... You can also call native binaries so you therefore you can use languages like Go or C or anything else that statically compiles.
- alexbilbie 11y ago
  Lambda functions are just Docker containers. API Gateway could be replaced by something like Open Resty. S3 can be replaced by any other file storage solution.
- saintfiends 11y ago
  Exactly. What if amazon decides to close your account, because you know.. they can. Now you're pretty much screwed. With traditional VPS you just point ansible/salt/puppet to new servers and you're good to go.
seiji 11y ago
"Microservices without the Servers: the Uberization of IaaS as PaaS for SaaS" Like when you say you have no carbon footprint because you don't own a car, even though you call a taxi every time you want to go somewhere? Are microservices different from SOA? Or is it just a more modern, streamlined buzzword? You say "microservices," but all I see is "omg, you realize inter-node latency isn't a trivial component to ignore when building interactive services, right?"
- aikah 11y ago
  > Or is it just a more modern, streamlined buzzword? You'd be surprised how many people taking the "micro service" bait have never heard of an n-tier architecture or even SOA. I pity the next generation of developers that will have to maintain all that micro-servicing mess developed today. Instead of relying on a simple architecture with messaging and workers, micro-service evangelists are turning maintenance and deployment of applications into a nightmare for the sake of being hip. I won't even talk about amazon lambda which is the "acme" of vendor lock in .
- hyperpallium 11y ago
  Yes, microservices are just a rebranding of a SOA subset. http://martinfowler.com/articles/microservices.html#MicroservicesAndSoa http://martinfowler.com/articles/microservices.html#Microser... But I think this direction is inevitable, and we'll soon see freemium microservices. Amazon's "Lambda" page (esp scroll down to the "benefits" https://aws.amazon.com/lambda/ https://aws.amazon.com/lambda/ ) shows it's more like offloading some tasks (like worker threads in the cloud). I had a play with the second (linked) app, SquirrelBin http://squirrelbin.com/ http://squirrelbin.com/ which can edit and run javascript snippets. The latency is awful, 2-3 seconds for me (I'm in Australia, but that should only add 200ms roundtrip or so). They seem to spin up (reuse?) an entire instance for each request - it's incredible that it's as fast as it is. But the problem is the architecture of this specific app: the delay would be fine if you could edit-run-loop code locally, without the cloud. But they wanted to demonstrate quick development (for them) by just making a CRUD app, using AWS Lambda existing http endpoints for PUT, POST, GET, DEL. So after editing you have to save, load and run - and each one interacts with the cloud. BTW the article about SquirrelBin https://aws.amazon.com/blogs/compute/the-squirrelbin-architecture-a-serverless-microservice-using-aws-lambda/ https://aws.amazon.com/blogs/compute/the-squirrelbin-archite...
manigandham 11y ago
Are servers really that hard to manage these days? This seems like way more work and pretty limited in what it can really do, especially compared to a few lines of code in any decent web framework that can perform a lot faster.
- motoboi 11y ago
  I think biggest news here is the possibility to share a server with someone else, with amazon acting as a broker of CPU time. With virtual machines, we started to share physical resources which were otherwise wasted in dormancy. But even virtual machines were a waste of resources, as you need someone to set them up, keep them online and working. What if you could share the money you spent with those people and their knowledge? Amazon just did that to you. All some people want is to run code somewhere on the internet. Amazon gather them together to share a server and an admin team. In my point of view, Amazon Lambda is a huge improvement in efficiency for people around the world, as I (or someone else) can pay for a very tiny part of the work of a very specialized sysadmin and focus on my code.
  - manigandham 11y ago
    Yea I can see that. Lambda is cool and there are some niche cases where it's useful... However when talking about microservices, any non-trivial app quickly gets extremely complicated to setup and actually more inefficient in the amount of time it takes to execute each request. And probably more expensive since there still have to be servers somewhere, always ready to run your app and with all the management and orchestration layer on top. Also VM technology is sufficiently advanced that they can be multitenant on the same base hardware very efficiently and consume almost no resources while in a sleep state. With live-migration and auto-scaling advancements it's not a big deal.
  - twic 11y ago
    If your scale is small (you're in the 'two people in a garage' phase of your company), then the cost of having your own server is small, even though you waste most of it. Hetzner will rent you a real physical server with an x86 processor and 32 GB of RAM for about 40 euros a month. I'm sure you can get smaller virtual servers elsewhere for less. If your scale is large, you have enough work to make full use of however many servers you rent. Reducing infrastructure waste at small scale seems pointless to me. The actual cash money saving is just lost in the noise. The only way i can see that i could be wrong is if there's a suppressed demand for huge numbers of tiny-scale services. Is there?
amirmc 11y ago
Folks interested in this might like to know that ContainerCon also had a session on Containers and Unikernels. http://sched.co/3YUJ http://sched.co/3YUJ A write up and audio from that session is also available. http://thenewstack.io/the-comparison-and-context-of-unikernels-and-containers/ http://thenewstack.io/the-comparison-and-context-of-unikerne...
patsplat 11y ago
The current problem with this architecture is the network cannot be used as a security layer. Databases, search engines, etc need ports opened to the public rather than to selected servers.
- dikaiosune 11y ago
  If you're on a private network (like your own DC), I'd argue that network-based security is a poor idea because then an attacker just needs to plug in and have pretty easy access. If you're on the public cloud, I'd argue that this is an even bigger problem as you're then relying on VPC (or the equivalent) to always work correctly. Why not ignore the networking and just build in robust security? Pubkey authentication where possible, random long passwords where not? Retry limits for clients, network intrusion detection, etc. To me, relying on the network to keep you secure seems a bit like a crutch.
  - patsplat 11y ago
    This is an optimistic counterpoint. However realistically nearly all persistence services such as MySQL, Postgres, MongoDB, Memcache, ElasticSearch, etc either have been insufficiently hardened as a public service or flat out are not intended to be used on a public port and depend on the network for security. There is not currently an option to connect an RDS database instance to a Lambda function without opening said database instance up to the public. It's a problem. You are correct that SSH tunneling could be used to provide security but such usage is not yet a standard approach.
    - twagner 11y ago
      Totally agree. It's our most requested feature on the Lambda team and a priority to enable.
tw04 11y ago
Awesome, right up until you need a feature they don't want to offer, or they decide to sunset a feature you're the only one using, and you have absolutely 0 control over it.
- _Marak_ 11y ago
  If you are interested in a 100% open-source version of Amazon Lambda, you can check out http://hook.io/ http://hook.io/
jacques_chester 11y ago
Here's how I deploy code, without having to modify it: cf push myapp It figures out the language/runtime I'm using (Java, Ruby, Go, NodeJS, PHP), builds the code with a buildpack, then hands it off to a cloud controller which places it in a container. My code gets wired to traffic routing, log collection and injected services. I can deploy a 600Mb Java blockbuster using 8Gb of RAM per instance or I can push a 400kb Go app that needs 8Mb of RAM per instance. I don't need to read special documentation, I don't need special Java annotations. I just push. And it just works. I'm talking about Cloud Foundry. It runs on AWS. And vSphere. And OpenStack. It's opensource and doesn't tie you to a single vendor or cloud forever. I worked on it for a while, in the buildpacks team, so I'm a one-eyed fan. Seriously: why are we still talking about devops? It's a solved problem. Use Heroku. Install Cloud Foundry. Install OpenShift. And get back to focusing on user value, not tinkering. Disclaimer: I work for Pivotal Labs, part of Pivotal, which donates the largest amount of engineering effort on Cloud Foundry (followed by IBM).
- cpitman 11y ago
  Because DevOps != CICD, and a PaaS doesn't cover the most important parts of DevOps (creating feedback channels between your Dev and Ops teams and a structure for continuous process improvement). PaaS just makes life easier by reducing the amount of communication needed. It's more like a fancy wall that makes it easier for developers to throw code over it.
  - jacques_chester 11y ago
    I'm not sure I agree (insofar as CI is in our DNA and CD is what we're trying to make normal). To me the point of PaaS is to remove the need for a specialist gatekeeper in the feedback loop. It makes Ops happy by isolating the damage Devs can do. It makes Devs happy by removing Ops roadblocks and allowing Devs to see, immediately and directly, what their apps are doing. Classic ops culture emerged because computing was an expensive shared resource. Early tooling favoured utilisation over isolation because the latter is expensive. So it became possible for devs to accidentally or deliberately step on each other's toes. Ops was like the mature adult in a shared house: making sure everyone kept their junk out of the living room, restocking the bathroom, insisting that dishes get washed. With a PaaS that changes radically. Devs can't burst out of the box they assign themselves, subject to Ops-set resource pools. Ops hands Devs keys to personal apartments that are created on demand. What they do inside is up to them, Ops needn't worry or care.
jontro 11y ago
I made a pretty cool lambda this week converting using mandrill inbound email api, processing this through lambda, then posting it to my redmine docker server. After a lot of fiddling (lambdas doesnt support x-www-form-urlencoded) it now works great.
- athrun 11y ago
  Have you seen this? https://forums.aws.amazon.com/thread.jspa?messageID=673863 https://forums.aws.amazon.com/thread.jspa?messageID=673863 It's a mapping template for the AWS API Gateway you can use to convert both HTML form POSTed data and HTTP GET query string data to JSON.
  - jontro 11y ago
    Yeah, I used a mapping template similar to this. Sorry for the late reply
baconmania 11y ago
This is Amazon's wet dream. Your app isn't an app at all, it's just a collection of configs on the AWS Console. When and if the time comes to migrate off of AWS, you realize you don't actually have an app to migrate.
- impostervt 11y ago
  I made this, so you can run a Node Express app in the AWS API Gateway. If the API Gateway ever goes away, it wouldn't be too hard to host your express app elsewhere: https://github.com/johntitus/legerdemain https://github.com/johntitus/legerdemain
- arihant 11y ago
  Or, you realize that your processes are so minimalistic and well structured due to lack of options, that you only have to write a custom request router over the weekend to migrate. Also, Lambda-like options are available with most PaaS providers now. It is not much different and might be easier than migrating web app from a custom PaaS. The only issue is, and has always been, the migration of data. And I don't see that getting solved until some startup writes a bunch of layers on top of a bunch of providers. It's very tricky, for good reasons.
  - IanCal 11y ago
    > Also, Lambda-like options are available with most PaaS providers now. Which other ones are there? I used to use PiCloud until they were bought out by dropbox and it atrophied. Shame, it was exactly what I wanted in a service.
    - robbs 11y ago
      IronWorker from Iron.io is similar to Lambda.
      - ddorian43 11y ago
        ironworker is not per-request, it's like jobs that you schedule from a queue
sandGorgon 11y ago
Is there a particular reason why Amazon chose JavaScript? I'm seeing more and more PAAS services going nodejs first/only and am wondering if there's an underlying reason.
- twagner 11y ago
  AWS Lambda supports nodejs and jvm-based languages (Java, Scala, Clojure, etc.) directly, and lets you run Python, shell scripts, and arbitrary executables as well. We started with nodejs because it worked nicely for expressing our initial launch scenario, event handlers.
  - sandGorgon 11y ago
    yes - I am aware that you support Python, etc. .. but nodejs is your first class language. For example, even your docs only mention nodejs (and java recently) [1] what is even more interesting is that you felt it worked nicely for expressing event handlers. Can you talk a bit more about that - very interesting to see why not something like python or ruby. I know that nodejs is a callback-oriented framework... was it the fact that you can test locally on nodejs consistently versus what would be the expected output on Lambda ? [1] https://aws.amazon.com/lambda/faqs/ https://aws.amazon.com/lambda/faqs/
- coldtea 11y ago
  Popularity?
zkhalique 11y ago
I came here expecting to read about "distributed computing in the peer to peer network" and instead found a how-to for "servers-as-a-service" from Amazon. Check this out instead: https://crowdprocess.com/ https://crowdprocess.com/
paulspringett 11y ago
Interesting that the article talks about load tests but omits any results. I was trying out a Gateway API + Lambda + DynamoDB setup in the hope that it would be a highly scalable data capture solution. Sadly the marketing doesn't match the reality. The performance both in terms of reqs/sec and response time were pretty poor. At 20 reqs/sec - no errors and majority of response times around 300ms At 45 reqs/sec - 40% of responses took more than 1200ms, min request time was ~350ms At 50 reqs/sec - v slow response times, lots of SSL handshake timeout errors. I think requests were throttled by Lambda but I would expect a 429 response as per the docs rather than SSL errors. My hope was that Lambda would spin up more functions as demand increased, but if you read the FAQs carefully it looks as though there are default limits. You can ask these to be changed but that doesn't make scaling very realtime.
- balls187 11y ago
  Correct. Lambda isn't designed for high data through put. That's what Amazon Kinesis is for. Each Kinesis shard can handle 1000KB/s data injestion rates. You would write your data to a kinesis stream, then use Lambda to respond to the kinesis event to write data to your DynamoDB table.
  - paulspringett 11y ago
    Thanks for the info on this, I hadn't seen Kinesis before. I also tried something similar with S3 upload but Kinesis looks a much better solution for what I'm trying to do.
  - wildwood 11y ago
    Kinesis isn't a good idea for low-latency queueing. It can handle high throughput, but it can often take anywhere from one to ten seconds for a message to make it through the queue. Given that DynamoDB can reliably write in the 4-5ms range, a kinesis queue may not be necessary. Unless the point of the Kinesis layer is to keep the cost of DynamoDB provisioning low?
- scottdw2 11y ago
  Are you using Node.js or Java for your Lambda function? If you are using "Node.js", you may be seeing slow times if you are not calling "context.done" in the correct place, or if you have code paths that don't call it. Not calling context.done could either cause Node.js to exit, either because the node event loop is empty, or because the code times out, and Lambda kills it. When node exits, the container shuts down, which means Lambda can't re-use the container for the next invoke and needs to create a new one. The "cold-start" path is much slower than the "warm-start" path. When Lambda is able to re-use containers, invokes will be much faster than when it can't. Also, how are you initializing your connection to DDB? Is it happening inside your Lambda function? If you either move it to the module initializer (for Node), or to a static constructor (for Java), you may also see speed improvements. If you initiate a connection to DDB inside the Lambda function, that code will run on every invoke. However, if you create it outside the Lambda function (again in the Module initializer or in a static constructor) then that code will only run once, when the container is spun up. Subsequent invokes that use the same container will be able to re-use the HTTP connection to DDB, which will improve invoke times. Also, you may want to consider increasing the amount of RAM allocated to your Lambda function. The "memory size" option is badly named, and it controls more than just the maximum ram you are allowed to use. It also controls the proportion of CPU that your container is allowed to use. Increasing the memory size will result in a corresponding (linear) increase in CPU power. One final thing to keep in mind when scaling a Lambda function is that Lambda mainly throttles on the number of concurrent requests, not on the transactions per second (TPS). By default Lambda will allow up to 100 concurrent requests. If you want a maximum limit greater than that you do have to call us, but we can set the limit fairly high for you. The scaling is still dynamic, even if we have to raise your upper limit. Lambda will spin up and spin down servers for you, as you invoke, depending on actual traffic. The default limit of 100 is mainly meant as safety limit. For example, unbounded recursion is a mistake we see frequently. Having default throttles in place is good protection, both for us and for you. We generally want to make sure that you really want to use a large number of servers before we go ahead and allocate them to you. For example, a lot of folks use Lambda with S3 for generating thumbnail images, sometimes in several different sizes. A common mistake some folks make when implementing this for the first time is to write back to the same s3 bucket they are triggering off of, without filtering the generated files from the trigger. The end result is an exponential explosion of Lambda requests. Having a safety limit in place helps with that. In any case, if you are having trouble getting Lambda to scale, I'm happy to try and help.
balls187 11y ago
I built http://vat.landedcost.avalara.com/ http://vat.landedcost.avalara.com/ using this same architecture pattern. The site is served up via S3, and the back-end logic is a Lambda module that wraps a SOAP API.
daviding 11y ago
I'm playing with these exact things now and it is very enjoyable so far. My main worry is not on the technical side but on how things are charged for. If I build something that starts to get used I am covered in terms of scalability, but not in a way that protects me from 'cost scalability' so to speak. I know I can set up billing alerts and hit a big 'shutdown' button in response to high load, but what I don't think I can do is throttle these services based on the money I want to budget/spend. With my own services I have a hard cost limit, with a hard scalability limit, or rather I just accept that my response times will go down or fail once I've allocated all I can afford. If there something for AWS in terms of 'cost throttling'? It may be a gap in their services, especially for people want to build things that might get traction?
- ww520 11y ago
  Same worry about the cost. The API gateway seems pretty expensive.
- jsprogrammer 11y ago
  The other thing that would be interesting to look at would be the cost of running an alternative implementation on a more standard platform. What would be the cost of running the same application on AWS VM's, for example? Is Amazon trying to extract a profit? Unless they are using specialized hardware, can they really execute this service any cheaper than you could? Or do they pad the billing to fund Amazon? Why would I go with a likely much more expensive option (I'd be pretty surprised if Amazon's billings for this service scale linearly with their costs) instead of the option that provides more traditional cost scaling?
- bpicolo 11y ago
  As a small user, I've bemoaned the lack of 'cost throttling' for a while. I spend minimally and don't want to worry about e.g. private key leaks that cost a fortune, or some malicious traffic hitting my s3 hard.
  - daviding 11y ago
    As a thought exercise it is interesting to think through what we would 'trade' though. For the S3 case there could be a hard cap of allocation, but once it is reached then does the service just switch off? Could it just respond to, say, 100 requests per second, as a ratio of how much money you want to spend in some time period? For Lambda style services it's odd because if I was hosting them in my own container (or an AWS one even) then they would still accept requests but their responses would start to slow (but still work). Trading through-put for cost/scalability? The trouble with AWS services for that 'fear of success' type of budgeting (different from losing a key or malicious calls) is they are either on or off, with no in-between cost/latency/resource allocation ratio. I'm surprised this hasn't come up more actually (or I just missed it), considering the overlap between devs that would like less devops and devs with limited budgets..
pea 11y ago
Great to see Lambda stepping up their serverless game. We're big fans of this approach and are hacking on something similar to this at StackHut[1], but: * Mostly OSS to avoid lock-in * Git integration * Full stack specification (OS, dependencies, etc.) * Python/ES6 support (Ruby and PHP coming) * Client libs so you can call your functions 'natively' in other languages. It would be awesome to hear what people would like us to build for them. Here is a blog-post on how to build a PDF -> image converter: http://blog.stackhut.com/it-was-meant-to-be/ http://blog.stackhut.com/it-was-meant-to-be/ [1] https://stackhut.com https://stackhut.com
- Jake232 11y ago
  I think your pricing scheme[1] could put a lot of people off. I fall into the category where I'd be fine on the free tier (< 10 private services), and yet I don't want a free service. I know if it's free, then it's going to be under some kind of fair usage policy, and you're going to rate limit me or have some kind of restrictions eventually. There's no way it can be sustainably free if I start to push it really hard. I'd prefer to just know the limits upfront, or have some kind of usage based pricing. [1]. http://stackhut.com/#/pricing http://stackhut.com/#/pricing
  - pea 11y ago
    Hey Jake -- thanks for your feedback, that is really helpful. We're going to add some better pricing. How would you like this to work? - per month, flat rate, ups w/ usage - per request - per compute / storage We really like the idea of only paying for the compute you actually use a la lambda; one of my gripes with Heroku was having to pay $x when the server was only in use for short bursts. Why should I pay for downtime? That said, we've actually had many people say they would prefer per month, as it is more predictable and they are worried it could spiral out of control. I would be super interested to hear your thoughts.
    - viraptor 11y ago
      Different person, but I'd prefer per-request with N requests packaged for free and (N+1)th request charged if charging is enabled, or returning error if I want to stay free. (so there are no surprise charges for service spamming)
loafoe 11y ago
Beware, link-bait! Title should really be "Microservices without non-Amazon Services", which if you remove the double negate really says "Microservices with Amazon Services", which is well.. not that interesting IMO. I'd rather write against CloudFoundry which abstract away AWS.
- Animats 11y ago
  Also note the total absence of any reference to cost and billing. This isn't free.
  - scottdw2 11y ago
    Lambda has a fairly generous free tier. Here are the details on pricing: https://aws.amazon.com/lambda/pricing/ https://aws.amazon.com/lambda/pricing/ You get up to 1M requests / month and 400,000 GB-seconds of compute time per month. A default lambda function uses 128 MB of ram (0.125 GB), which gives you about 3.2 M seconds of compute time (time actually spent executing requests) every month for free. Thus if you have functions that take 500 ms on average, and use the default amount of RAM, you can process about 6.4 M requests in a month for a total bill of $1.20. Above the free tier limits you pay $0.20 per million requests, and $0.1667 per million GB-seconds. The pricing is fairly attractive.
droithomme 11y ago
This article only makes sense if you don't know what servers are, and believe "the cloud" doesn't use them.
drinchev 11y ago
I was thinking... How can you use server less webapp with SEO-friendly dynamic url structure, e.g. Ecommerce, social network, etc. does anyone have an idea on that?
- rev_bird 11y ago
  I don't think servers have a lot to do with this -- when you go to a URL, and a page gets returned, why does it matter where the data came from? For example: Say you've got an AngularJS app sitting in S3 or something, and your backend is a Node.js app running in Lambda. Google finds a link to "random-new-social-network.com/profile/drinchev" somewhere and tries to index it -- their request is routed to "random-new-social-network.com," where Angular recognizes "/profile/drinchev" as a route to a profile for some user named drinchev, pulls in the "profile" template, and spits out your profile, where Google can read it and call it a day. If you're talking about search engines getting along with Javascript-reliant sites, that's a different story, but I don't think I see the problem.
raspasov 11y ago
I see a lot of people disagreeing with the overall direction of "less servers, more services". I totally get it, I used to be one of those people, but I think the shift to "less hassle development" is inevitable. 5 years ago people used to debate whether we should use a virtualized server vs. a physical one. You still can see similar discussions but rarely - we all have more or less agreed that using AWS/Rackspace/etc. is good for a business in majority of use cases. I think 5 years from now we'll still be debating servers vs. services, but the prevailing wisdom will be that "services" have won.
- alexro 11y ago
  It may well be so that companies will run their private clouds on the colocated servers. What wins in that case?
  - raspasov 11y ago
    Maybe for some companies/use cases, however my feeling is that the setup time and dealing with hardware directly will always be too much hassle for the majority.
    - alexro 11y ago
      Except they will deal with hardware anyway - there are about several thousand different devices in our offices. How difficult is it to get another 2 admins - and two could be enough in the modern world of everything automated.
cdnsteve 11y ago
Lamda does not work inside a vpc nor can it connect to one. You cannot use RDS period. This severly limits options currently available from a database and security perspective.
- midnightjasmine 11y ago
  AFAIK the AWS team is working on this. It's one of the most asked for features.

273 points by alexbilbie 11y ago

It is pretty cool but not really serverless, you are still handling http requests via Amazon API gateway and in general you are relying and paying for quite a lot of Amazon services. Not sure how much better this approach is to serving image magic via PHP for example, it would be good to see some numbers.

philsnow 11y ago
This removes nearly all of "devops". You don't have to mess around with figuring out how many ec2 instances you need (or deal with auto-scaling groups), how to secure the linux or whatever you stick on the ec2 instances, etc. There's still a ton of creating zip file artifacts of your lambda payloads (instead of pushing to a magic git repository that amazon controls, say), so there's a bit of "build monkey"ing to do instead of "devops"ery. But I think a lot of shops will be happy to make that trade, as "build" is closer to their core experience than "devops".
- maratd 11y ago
  Yes, you get rid of devops. You gain vendor lock-in. You are now tied to the Amazon platform. If they shut down or suspend your account, for any reason, you are out of business. You are also paying premium for the platform, with the cost of devops built in. I'll take an open ecosystem that gives me options to migrate my business anytime over a proprietary solution.
  - curiousjorge 11y ago
    pretty much this. amazon can at any point shut down any of these services or nerf it. if you built everything up to this point on amazon and they shut it down, it's more work.
    - maratd 11y ago
      To add to your point, they have done this before and are still doing it. There is no guarantee of continued service. http://recode.net/2015/03/18/amazon-will-shut-down-amazon-webstore-its-competitor-to-shopify-and-bigcommerce/ http://recode.net/2015/03/18/amazon-will-shut-down-amazon-we...
      - duskwuff 11y ago
        Amazon Webstore wasn't part of AWS, though. It was part of their commerce wing - very different.
        curiousjorge 11y ago
        remember PiCloud? they shut down after I spent a quarter building around their API calls. I never want to repeat that mistake and you also get the bonus of being able to sell your source code or deploy local cloud if an enterprise are willing to pay extra for it.
  - andyidsinga 11y ago
    There's always this tension, its really interesting. I think the open ecosystem approach will work well for apps/systems that are more established and have a predictable and sustainable user base and related revenue stream to maintain the system. But for new ideas, early stage startups, the open eco-system approach will be a lot more work than using the high-level services providers like amazon are developing ...basically a no-stack approach can help one quickly find some product / market fit. Once some level of baseline level of utilization is understood then switching to a more difficult, but less-locked in approach would be smart. all that said, there's probably a middle ground here too (but arguably not) -- where one deploy's using docker containers, private registry & image repo, s3 for static immutable storage and some open database like PostgreSQL on RDS. All that could be layered on top of AWS and other providers -- but it will still be a PITA to move the whole thing. BTW -- take a look at the elasticbox product -- they really have an interesting approach to cloud that sort of obviates the lock-in issue by allowing one to build apps across clouds from the start using their "boxes" metaphor.
- treve 11y ago
  I'd say that most people don't need auto-scaling, and this configuration is almost definitely harder to understand and learn than a simple php script that works everywhere.
  - jshen 11y ago
    NO it's not harder to understand. If you are doing anything remotely serious, then your php script needs to be on multiple servers for redundancy, it needs to be behind a load balancer, you have to be responsible for the security of the VMs the php script runs on, and on and on and on and on. Edit: well, unless you run your php script in a PaaS like Google App Engine.
    - treve 11y ago
      Yet, most people probably still FTP their php files onto a shared hosting environment. And for most people, that's actually good enough.
- NDizzle 11y ago
  Maybe this statement will date me, but I don't really like this trend of having to deal with less things. I mean, sure, it's more simple to get started. But when things break you are screwed because nobody really knows what is going on.
- andyidsinga 11y ago
  yep -- the devops part is valuable on the app creator/dev's side and this architecture is very valuable on the amazon/cloud service provider's side too. The smaller the scheduled unit of code is, the more densely they can pack the workloads and make more efficient use of their system ...squeezing out the pennies at their scale makes a lot of sense. I've seen some vendor lock in comments here -- but certainly the big 3 or 4 service providers will have these features figured out soon - and seems to me some open source to schedule functions across compute will appear in no time that could be used by the smaller providers. replicating all the other features is much harder -- this is a great moat amazon has built.
- rycfan 11y ago
  Sorry, this is actually factually incorrect. As shown in another thread here, this service does not infinitely auto-scale (the recommendation was to use Kinesis), so you still have to know which services to choose, which is pretty much a full-time job with the number of different services offered these days.
ahallock 11y ago
The point is you don't provision your own servers, not that servers don't exist somewhere executing your code. People seem to be taking the marketing too literally.
- larrys 11y ago
  It's good add copy and ranks high on the link-bait scale. They say after all: "and then unit and load tested it, all without using any servers." ...with a title of "Microservices without the Servers" when what they mean is "without provisioning any servers yourself" which is obviously much less attractive. My curiosity was peaked by the title the title, inserting "w/o provisioning" would have not gotten me anywhere near as interested in the topic.
  - angrow 11y ago
    Would you apply the same analysis if I claimed I could buy a t-shirt from a store without using any factories?
- logn 11y ago
  No it's not taking this too literally. I re-read the architecture a few times then stepped through the source to make sure I wasn't missing something. I was thinking that maybe the servers were only used to deploy the image processing code to the client which could then run the code locally. But that's not the case. Serverless implies that a server is not required after an installation step and that you only need your local device. Or perhaps too that you only need a collection of like clients to do something P2P. Just because you as the developer don't have to think about the server doesn't make it serverless.

hackaflocka 11y ago

This is a misleading title. Managed cloud services run on servers. There has to be a better title. For a moment I thought they were proposing P2P hosting.

ahallock 11y ago
The implication is that you don't have to provision any servers to execute your code. That is the "serverless" part.
- turing_bot_3c 11y ago
  But the name is terrible. It is like saying, going from A to B without a car by using a Taxi.
stefantalpalaru 11y ago
That's what you get when marketing relabels the cluster as "cloud" and a VPS interface as a "compute service". You start thinking it's buzzwords all the way down :-)

cptnbob 11y ago

Too much vendor lock in. Will keep my VMs thanks.

bpicolo 11y ago
Yeah, that's what I think too. This feels too far into the vendor-lockin, downtime death zone, as reliable as Amazon might be. Plus, while it might be cool for some microservices, it seems like it would be a lot more unwieldy trying to do a full scale application.
SideburnsOfDoom 11y ago
And language lock-in. So far Lambda supports only Node.js and Java.
- brianwawok 11y ago
  Java gets you ruby via JRuby and Python via Jython... (Not sure how current they are these days). So missing C and Rust type stuff I guess?
  - alexbilbie 11y ago
    The AWS Lambda team wrote a blog post about how to use Python - https://aws.amazon.com/blogs/compute/using-python-in-an-aws-lambda-function/ https://aws.amazon.com/blogs/compute/using-python-in-an-aws-... You can also call native binaries so you therefore you can use languages like Go or C or anything else that statically compiles.
alexbilbie 11y ago
Lambda functions are just Docker containers. API Gateway could be replaced by something like Open Resty. S3 can be replaced by any other file storage solution.
saintfiends 11y ago
Exactly. What if amazon decides to close your account, because you know.. they can. Now you're pretty much screwed. With traditional VPS you just point ansible/salt/puppet to new servers and you're good to go.

seiji 11y ago

"Microservices without the Servers: the Uberization of IaaS as PaaS for SaaS" Like when you say you have no carbon footprint because you don't own a car, even though you call a taxi every time you want to go somewhere? Are microservices different from SOA? Or is it just a more modern, streamlined buzzword? You say "microservices," but all I see is "omg, you realize inter-node latency isn't a trivial component to ignore when building interactive services, right?"

aikah 11y ago
> Or is it just a more modern, streamlined buzzword? You'd be surprised how many people taking the "micro service" bait have never heard of an n-tier architecture or even SOA. I pity the next generation of developers that will have to maintain all that micro-servicing mess developed today. Instead of relying on a simple architecture with messaging and workers, micro-service evangelists are turning maintenance and deployment of applications into a nightmare for the sake of being hip. I won't even talk about amazon lambda which is the "acme" of vendor lock in .
hyperpallium 11y ago
Yes, microservices are just a rebranding of a SOA subset. http://martinfowler.com/articles/microservices.html#MicroservicesAndSoa http://martinfowler.com/articles/microservices.html#Microser... But I think this direction is inevitable, and we'll soon see freemium microservices. Amazon's "Lambda" page (esp scroll down to the "benefits" https://aws.amazon.com/lambda/ https://aws.amazon.com/lambda/ ) shows it's more like offloading some tasks (like worker threads in the cloud). I had a play with the second (linked) app, SquirrelBin http://squirrelbin.com/ http://squirrelbin.com/ which can edit and run javascript snippets. The latency is awful, 2-3 seconds for me (I'm in Australia, but that should only add 200ms roundtrip or so). They seem to spin up (reuse?) an entire instance for each request - it's incredible that it's as fast as it is. But the problem is the architecture of this specific app: the delay would be fine if you could edit-run-loop code locally, without the cloud. But they wanted to demonstrate quick development (for them) by just making a CRUD app, using AWS Lambda existing http endpoints for PUT, POST, GET, DEL. So after editing you have to save, load and run - and each one interacts with the cloud. BTW the article about SquirrelBin https://aws.amazon.com/blogs/compute/the-squirrelbin-architecture-a-serverless-microservice-using-aws-lambda/ https://aws.amazon.com/blogs/compute/the-squirrelbin-archite...

manigandham 11y ago

Are servers really that hard to manage these days? This seems like way more work and pretty limited in what it can really do, especially compared to a few lines of code in any decent web framework that can perform a lot faster.

motoboi 11y ago
I think biggest news here is the possibility to share a server with someone else, with amazon acting as a broker of CPU time. With virtual machines, we started to share physical resources which were otherwise wasted in dormancy. But even virtual machines were a waste of resources, as you need someone to set them up, keep them online and working. What if you could share the money you spent with those people and their knowledge? Amazon just did that to you. All some people want is to run code somewhere on the internet. Amazon gather them together to share a server and an admin team. In my point of view, Amazon Lambda is a huge improvement in efficiency for people around the world, as I (or someone else) can pay for a very tiny part of the work of a very specialized sysadmin and focus on my code.
- manigandham 11y ago
  Yea I can see that. Lambda is cool and there are some niche cases where it's useful... However when talking about microservices, any non-trivial app quickly gets extremely complicated to setup and actually more inefficient in the amount of time it takes to execute each request. And probably more expensive since there still have to be servers somewhere, always ready to run your app and with all the management and orchestration layer on top. Also VM technology is sufficiently advanced that they can be multitenant on the same base hardware very efficiently and consume almost no resources while in a sleep state. With live-migration and auto-scaling advancements it's not a big deal.
- twic 11y ago
  If your scale is small (you're in the 'two people in a garage' phase of your company), then the cost of having your own server is small, even though you waste most of it. Hetzner will rent you a real physical server with an x86 processor and 32 GB of RAM for about 40 euros a month. I'm sure you can get smaller virtual servers elsewhere for less. If your scale is large, you have enough work to make full use of however many servers you rent. Reducing infrastructure waste at small scale seems pointless to me. The actual cash money saving is just lost in the noise. The only way i can see that i could be wrong is if there's a suppressed demand for huge numbers of tiny-scale services. Is there?

amirmc 11y ago

Folks interested in this might like to know that ContainerCon also had a session on Containers and Unikernels. http://sched.co/3YUJ http://sched.co/3YUJ A write up and audio from that session is also available. http://thenewstack.io/the-comparison-and-context-of-unikernels-and-containers/ http://thenewstack.io/the-comparison-and-context-of-unikerne...

patsplat 11y ago

The current problem with this architecture is the network cannot be used as a security layer. Databases, search engines, etc need ports opened to the public rather than to selected servers.

dikaiosune 11y ago
If you're on a private network (like your own DC), I'd argue that network-based security is a poor idea because then an attacker just needs to plug in and have pretty easy access. If you're on the public cloud, I'd argue that this is an even bigger problem as you're then relying on VPC (or the equivalent) to always work correctly. Why not ignore the networking and just build in robust security? Pubkey authentication where possible, random long passwords where not? Retry limits for clients, network intrusion detection, etc. To me, relying on the network to keep you secure seems a bit like a crutch.
- patsplat 11y ago
  This is an optimistic counterpoint. However realistically nearly all persistence services such as MySQL, Postgres, MongoDB, Memcache, ElasticSearch, etc either have been insufficiently hardened as a public service or flat out are not intended to be used on a public port and depend on the network for security. There is not currently an option to connect an RDS database instance to a Lambda function without opening said database instance up to the public. It's a problem. You are correct that SSH tunneling could be used to provide security but such usage is not yet a standard approach.
  - twagner 11y ago
    Totally agree. It's our most requested feature on the Lambda team and a priority to enable.

tw04 11y ago

Awesome, right up until you need a feature they don't want to offer, or they decide to sunset a feature you're the only one using, and you have absolutely 0 control over it.

_Marak_ 11y ago
If you are interested in a 100% open-source version of Amazon Lambda, you can check out http://hook.io/ http://hook.io/

jacques_chester 11y ago

Here's how I deploy code, without having to modify it: cf push myapp It figures out the language/runtime I'm using (Java, Ruby, Go, NodeJS, PHP), builds the code with a buildpack, then hands it off to a cloud controller which places it in a container. My code gets wired to traffic routing, log collection and injected services. I can deploy a 600Mb Java blockbuster using 8Gb of RAM per instance or I can push a 400kb Go app that needs 8Mb of RAM per instance. I don't need to read special documentation, I don't need special Java annotations. I just push. And it just works. I'm talking about Cloud Foundry. It runs on AWS. And vSphere. And OpenStack. It's opensource and doesn't tie you to a single vendor or cloud forever. I worked on it for a while, in the buildpacks team, so I'm a one-eyed fan. Seriously: why are we still talking about devops? It's a solved problem. Use Heroku. Install Cloud Foundry. Install OpenShift. And get back to focusing on user value, not tinkering. Disclaimer: I work for Pivotal Labs, part of Pivotal, which donates the largest amount of engineering effort on Cloud Foundry (followed by IBM).

cpitman 11y ago
Because DevOps != CICD, and a PaaS doesn't cover the most important parts of DevOps (creating feedback channels between your Dev and Ops teams and a structure for continuous process improvement). PaaS just makes life easier by reducing the amount of communication needed. It's more like a fancy wall that makes it easier for developers to throw code over it.
- jacques_chester 11y ago
  I'm not sure I agree (insofar as CI is in our DNA and CD is what we're trying to make normal). To me the point of PaaS is to remove the need for a specialist gatekeeper in the feedback loop. It makes Ops happy by isolating the damage Devs can do. It makes Devs happy by removing Ops roadblocks and allowing Devs to see, immediately and directly, what their apps are doing. Classic ops culture emerged because computing was an expensive shared resource. Early tooling favoured utilisation over isolation because the latter is expensive. So it became possible for devs to accidentally or deliberately step on each other's toes. Ops was like the mature adult in a shared house: making sure everyone kept their junk out of the living room, restocking the bathroom, insisting that dishes get washed. With a PaaS that changes radically. Devs can't burst out of the box they assign themselves, subject to Ops-set resource pools. Ops hands Devs keys to personal apartments that are created on demand. What they do inside is up to them, Ops needn't worry or care.

jontro 11y ago

I made a pretty cool lambda this week converting using mandrill inbound email api, processing this through lambda, then posting it to my redmine docker server. After a lot of fiddling (lambdas doesnt support x-www-form-urlencoded) it now works great.

athrun 11y ago
Have you seen this? https://forums.aws.amazon.com/thread.jspa?messageID=673863 https://forums.aws.amazon.com/thread.jspa?messageID=673863 It's a mapping template for the AWS API Gateway you can use to convert both HTML form POSTed data and HTTP GET query string data to JSON.
- jontro 11y ago
  Yeah, I used a mapping template similar to this. Sorry for the late reply

baconmania 11y ago

This is Amazon's wet dream. Your app isn't an app at all, it's just a collection of configs on the AWS Console. When and if the time comes to migrate off of AWS, you realize you don't actually have an app to migrate.

impostervt 11y ago
I made this, so you can run a Node Express app in the AWS API Gateway. If the API Gateway ever goes away, it wouldn't be too hard to host your express app elsewhere: https://github.com/johntitus/legerdemain https://github.com/johntitus/legerdemain
arihant 11y ago
Or, you realize that your processes are so minimalistic and well structured due to lack of options, that you only have to write a custom request router over the weekend to migrate. Also, Lambda-like options are available with most PaaS providers now. It is not much different and might be easier than migrating web app from a custom PaaS. The only issue is, and has always been, the migration of data. And I don't see that getting solved until some startup writes a bunch of layers on top of a bunch of providers. It's very tricky, for good reasons.
- IanCal 11y ago
  > Also, Lambda-like options are available with most PaaS providers now. Which other ones are there? I used to use PiCloud until they were bought out by dropbox and it atrophied. Shame, it was exactly what I wanted in a service.
  - robbs 11y ago
    IronWorker from Iron.io is similar to Lambda.
    - ddorian43 11y ago
      ironworker is not per-request, it's like jobs that you schedule from a queue

sandGorgon 11y ago

Is there a particular reason why Amazon chose JavaScript? I'm seeing more and more PAAS services going nodejs first/only and am wondering if there's an underlying reason.

twagner 11y ago
AWS Lambda supports nodejs and jvm-based languages (Java, Scala, Clojure, etc.) directly, and lets you run Python, shell scripts, and arbitrary executables as well. We started with nodejs because it worked nicely for expressing our initial launch scenario, event handlers.
- sandGorgon 11y ago
  yes - I am aware that you support Python, etc. .. but nodejs is your first class language. For example, even your docs only mention nodejs (and java recently) [1] what is even more interesting is that you felt it worked nicely for expressing event handlers. Can you talk a bit more about that - very interesting to see why not something like python or ruby. I know that nodejs is a callback-oriented framework... was it the fact that you can test locally on nodejs consistently versus what would be the expected output on Lambda ? [1] https://aws.amazon.com/lambda/faqs/ https://aws.amazon.com/lambda/faqs/
coldtea 11y ago
Popularity?

zkhalique 11y ago

I came here expecting to read about "distributed computing in the peer to peer network" and instead found a how-to for "servers-as-a-service" from Amazon. Check this out instead: https://crowdprocess.com/ https://crowdprocess.com/

paulspringett 11y ago

Interesting that the article talks about load tests but omits any results. I was trying out a Gateway API + Lambda + DynamoDB setup in the hope that it would be a highly scalable data capture solution. Sadly the marketing doesn't match the reality. The performance both in terms of reqs/sec and response time were pretty poor. At 20 reqs/sec - no errors and majority of response times around 300ms At 45 reqs/sec - 40% of responses took more than 1200ms, min request time was ~350ms At 50 reqs/sec - v slow response times, lots of SSL handshake timeout errors. I think requests were throttled by Lambda but I would expect a 429 response as per the docs rather than SSL errors. My hope was that Lambda would spin up more functions as demand increased, but if you read the FAQs carefully it looks as though there are default limits. You can ask these to be changed but that doesn't make scaling very realtime.

balls187 11y ago
Correct. Lambda isn't designed for high data through put. That's what Amazon Kinesis is for. Each Kinesis shard can handle 1000KB/s data injestion rates. You would write your data to a kinesis stream, then use Lambda to respond to the kinesis event to write data to your DynamoDB table.
- paulspringett 11y ago
  Thanks for the info on this, I hadn't seen Kinesis before. I also tried something similar with S3 upload but Kinesis looks a much better solution for what I'm trying to do.
- wildwood 11y ago
  Kinesis isn't a good idea for low-latency queueing. It can handle high throughput, but it can often take anywhere from one to ten seconds for a message to make it through the queue. Given that DynamoDB can reliably write in the 4-5ms range, a kinesis queue may not be necessary. Unless the point of the Kinesis layer is to keep the cost of DynamoDB provisioning low?
scottdw2 11y ago
Are you using Node.js or Java for your Lambda function? If you are using "Node.js", you may be seeing slow times if you are not calling "context.done" in the correct place, or if you have code paths that don't call it. Not calling context.done could either cause Node.js to exit, either because the node event loop is empty, or because the code times out, and Lambda kills it. When node exits, the container shuts down, which means Lambda can't re-use the container for the next invoke and needs to create a new one. The "cold-start" path is much slower than the "warm-start" path. When Lambda is able to re-use containers, invokes will be much faster than when it can't. Also, how are you initializing your connection to DDB? Is it happening inside your Lambda function? If you either move it to the module initializer (for Node), or to a static constructor (for Java), you may also see speed improvements. If you initiate a connection to DDB inside the Lambda function, that code will run on every invoke. However, if you create it outside the Lambda function (again in the Module initializer or in a static constructor) then that code will only run once, when the container is spun up. Subsequent invokes that use the same container will be able to re-use the HTTP connection to DDB, which will improve invoke times. Also, you may want to consider increasing the amount of RAM allocated to your Lambda function. The "memory size" option is badly named, and it controls more than just the maximum ram you are allowed to use. It also controls the proportion of CPU that your container is allowed to use. Increasing the memory size will result in a corresponding (linear) increase in CPU power. One final thing to keep in mind when scaling a Lambda function is that Lambda mainly throttles on the number of concurrent requests, not on the transactions per second (TPS). By default Lambda will allow up to 100 concurrent requests. If you want a maximum limit greater than that you do have to call us, but we can set the limit fairly high for you. The scaling is still dynamic, even if we have to raise your upper limit. Lambda will spin up and spin down servers for you, as you invoke, depending on actual traffic. The default limit of 100 is mainly meant as safety limit. For example, unbounded recursion is a mistake we see frequently. Having default throttles in place is good protection, both for us and for you. We generally want to make sure that you really want to use a large number of servers before we go ahead and allocate them to you. For example, a lot of folks use Lambda with S3 for generating thumbnail images, sometimes in several different sizes. A common mistake some folks make when implementing this for the first time is to write back to the same s3 bucket they are triggering off of, without filtering the generated files from the trigger. The end result is an exponential explosion of Lambda requests. Having a safety limit in place helps with that. In any case, if you are having trouble getting Lambda to scale, I'm happy to try and help.

balls187 11y ago

I built http://vat.landedcost.avalara.com/ http://vat.landedcost.avalara.com/ using this same architecture pattern. The site is served up via S3, and the back-end logic is a Lambda module that wraps a SOAP API.

daviding 11y ago

I'm playing with these exact things now and it is very enjoyable so far. My main worry is not on the technical side but on how things are charged for. If I build something that starts to get used I am covered in terms of scalability, but not in a way that protects me from 'cost scalability' so to speak. I know I can set up billing alerts and hit a big 'shutdown' button in response to high load, but what I don't think I can do is throttle these services based on the money I want to budget/spend. With my own services I have a hard cost limit, with a hard scalability limit, or rather I just accept that my response times will go down or fail once I've allocated all I can afford. If there something for AWS in terms of 'cost throttling'? It may be a gap in their services, especially for people want to build things that might get traction?

ww520 11y ago
Same worry about the cost. The API gateway seems pretty expensive.
jsprogrammer 11y ago
The other thing that would be interesting to look at would be the cost of running an alternative implementation on a more standard platform. What would be the cost of running the same application on AWS VM's, for example? Is Amazon trying to extract a profit? Unless they are using specialized hardware, can they really execute this service any cheaper than you could? Or do they pad the billing to fund Amazon? Why would I go with a likely much more expensive option (I'd be pretty surprised if Amazon's billings for this service scale linearly with their costs) instead of the option that provides more traditional cost scaling?
bpicolo 11y ago
As a small user, I've bemoaned the lack of 'cost throttling' for a while. I spend minimally and don't want to worry about e.g. private key leaks that cost a fortune, or some malicious traffic hitting my s3 hard.
- daviding 11y ago
  As a thought exercise it is interesting to think through what we would 'trade' though. For the S3 case there could be a hard cap of allocation, but once it is reached then does the service just switch off? Could it just respond to, say, 100 requests per second, as a ratio of how much money you want to spend in some time period? For Lambda style services it's odd because if I was hosting them in my own container (or an AWS one even) then they would still accept requests but their responses would start to slow (but still work). Trading through-put for cost/scalability? The trouble with AWS services for that 'fear of success' type of budgeting (different from losing a key or malicious calls) is they are either on or off, with no in-between cost/latency/resource allocation ratio. I'm surprised this hasn't come up more actually (or I just missed it), considering the overlap between devs that would like less devops and devs with limited budgets..

pea 11y ago

Great to see Lambda stepping up their serverless game. We're big fans of this approach and are hacking on something similar to this at StackHut[1], but: * Mostly OSS to avoid lock-in * Git integration * Full stack specification (OS, dependencies, etc.) * Python/ES6 support (Ruby and PHP coming) * Client libs so you can call your functions 'natively' in other languages. It would be awesome to hear what people would like us to build for them. Here is a blog-post on how to build a PDF -> image converter: http://blog.stackhut.com/it-was-meant-to-be/ http://blog.stackhut.com/it-was-meant-to-be/ [1] https://stackhut.com https://stackhut.com

Jake232 11y ago
I think your pricing scheme[1] could put a lot of people off. I fall into the category where I'd be fine on the free tier (< 10 private services), and yet I don't want a free service. I know if it's free, then it's going to be under some kind of fair usage policy, and you're going to rate limit me or have some kind of restrictions eventually. There's no way it can be sustainably free if I start to push it really hard. I'd prefer to just know the limits upfront, or have some kind of usage based pricing. [1]. http://stackhut.com/#/pricing http://stackhut.com/#/pricing
- pea 11y ago
  Hey Jake -- thanks for your feedback, that is really helpful. We're going to add some better pricing. How would you like this to work? - per month, flat rate, ups w/ usage - per request - per compute / storage We really like the idea of only paying for the compute you actually use a la lambda; one of my gripes with Heroku was having to pay $x when the server was only in use for short bursts. Why should I pay for downtime? That said, we've actually had many people say they would prefer per month, as it is more predictable and they are worried it could spiral out of control. I would be super interested to hear your thoughts.
  - viraptor 11y ago
    Different person, but I'd prefer per-request with N requests packaged for free and (N+1)th request charged if charging is enabled, or returning error if I want to stay free. (so there are no surprise charges for service spamming)

loafoe 11y ago

Beware, link-bait! Title should really be "Microservices without non-Amazon Services", which if you remove the double negate really says "Microservices with Amazon Services", which is well.. not that interesting IMO. I'd rather write against CloudFoundry which abstract away AWS.

Animats 11y ago
Also note the total absence of any reference to cost and billing. This isn't free.
- scottdw2 11y ago
  Lambda has a fairly generous free tier. Here are the details on pricing: https://aws.amazon.com/lambda/pricing/ https://aws.amazon.com/lambda/pricing/ You get up to 1M requests / month and 400,000 GB-seconds of compute time per month. A default lambda function uses 128 MB of ram (0.125 GB), which gives you about 3.2 M seconds of compute time (time actually spent executing requests) every month for free. Thus if you have functions that take 500 ms on average, and use the default amount of RAM, you can process about 6.4 M requests in a month for a total bill of $1.20. Above the free tier limits you pay $0.20 per million requests, and $0.1667 per million GB-seconds. The pricing is fairly attractive.

droithomme 11y ago

This article only makes sense if you don't know what servers are, and believe "the cloud" doesn't use them.

drinchev 11y ago

I was thinking... How can you use server less webapp with SEO-friendly dynamic url structure, e.g. Ecommerce, social network, etc. does anyone have an idea on that?

rev_bird 11y ago
I don't think servers have a lot to do with this -- when you go to a URL, and a page gets returned, why does it matter where the data came from? For example: Say you've got an AngularJS app sitting in S3 or something, and your backend is a Node.js app running in Lambda. Google finds a link to "random-new-social-network.com/profile/drinchev" somewhere and tries to index it -- their request is routed to "random-new-social-network.com," where Angular recognizes "/profile/drinchev" as a route to a profile for some user named drinchev, pulls in the "profile" template, and spits out your profile, where Google can read it and call it a day. If you're talking about search engines getting along with Javascript-reliant sites, that's a different story, but I don't think I see the problem.

raspasov 11y ago

I see a lot of people disagreeing with the overall direction of "less servers, more services". I totally get it, I used to be one of those people, but I think the shift to "less hassle development" is inevitable. 5 years ago people used to debate whether we should use a virtualized server vs. a physical one. You still can see similar discussions but rarely - we all have more or less agreed that using AWS/Rackspace/etc. is good for a business in majority of use cases. I think 5 years from now we'll still be debating servers vs. services, but the prevailing wisdom will be that "services" have won.

alexro 11y ago
It may well be so that companies will run their private clouds on the colocated servers. What wins in that case?
- raspasov 11y ago
  Maybe for some companies/use cases, however my feeling is that the setup time and dealing with hardware directly will always be too much hassle for the majority.
  - alexro 11y ago
    Except they will deal with hardware anyway - there are about several thousand different devices in our offices. How difficult is it to get another 2 admins - and two could be enough in the modern world of everything automated.

cdnsteve 11y ago

Lamda does not work inside a vpc nor can it connect to one. You cannot use RDS period. This severly limits options currently available from a database and security perspective.

midnightjasmine 11y ago
AFAIK the AWS team is working on this. It's one of the most asked for features.