Hacker News new | past | comments | ask | show | jobs | submit login
Introducing Apex – Serverless Architecture with AWS Lambda (medium.com)
234 points by johanbrook on Jan 17, 2016 | hide | past | web | favorite | 40 comments



I'm curious if anyone has deployed a real app at any scale on Lambda/API Gateway. So far in my experience, the default limits and throughput are far lower than would be remotely useful for a moderately busy webapp. And to hit those rates would be outrageously expensive.

That may improve over time. But even more than that "serverless" is misleading. True, you don't have to personally manage the servers that are running your code, but that means that your operations team is actually inside Amazon. They have economies of scale, but that means they also don't always notice when one of their servers isn't performing up to par. More than once we've had to ask our support reps to get Lambda instances behind the scene restarted. At that point I start to wonder what the point is at all.


This is a problem even with EC2 unfortunately, maybe less so, and you can actually do something about it which is nice haha. At very least boot up a new node etc. There's definitely a certain amount of trust required for them to do a good job, but frankly having their team of developers on my side is great for a single person team, so far at least. I'll definitely write about any issues I have in prod.


I recently built a small service running on Lambda as part of a data pipeline. It doesn't get called very often, so it's well within the free tier. It's far from core functionality, and we wanted to just stick it somewhere where we wouldn't have to worry about it.

I would second what meddlepal said in a sibling comment about tooling and documentation. Everything is a little undercooked. I can see something like Apex being hugely useful here.

Given the current pricing it does seem hard to imagine large-scale systems running entirely on Lambda. But I imagine that will change.

I completely agree with TJ that we are headed for a new paradigm in server-side computing that looks a lot more like Lambda than Docker or Chef. We're racing towards a much higher level of abstraction. It's too early to tell if it will be an AWS product that emerges as the dominant platform for this new paradigm, or if a new player becomes dominant.


I just had a miserable experience trying to get a microservice written in Python running on Lambda. The tooling and documentation isn't there yet. It was so bad that I finally just did it over to deploy on two t2.micro instances with an ELB and auto scaling. Much easier deployment model that everyone understands.


The guys at http://acloud.guru are running their platform on Lambda/Firebase, and have given a few talks about how they've managed to achieve it. Disclaimer: I know a founder of theirs.


They have written a blog post that goes into more detail on how they piece together various components with Lambda: https://read.acloud.guru/serverless-the-future-of-software-a...

I'm pretty sure they have another post coming in the near future too.

I am impressed by how fast they built their platform given the size of their dev team. We (I'm a course author there, not developer) also use Lambda for custom slack bots too.


I would be thrilled if they provided an update, but Benchling's CRISPR search is what originally got me excited about Lambda. It's an incredibly compelling use case, as it enabled one second searches at any level of demand. And, their hosting costs dropped from thousands of dollars on EC2 to $60 on Lambda.

http://benchling.engineering/crispr-aws-lambda/


Yes, several production services including one serving an API and another a server side rendered JS app. API gateway + Lambda has some rough edges but the scalability has been great.


I'm deploying a new segmentation engine that runs on top of Lambda (input from Kinesis, output to SQS and Cassandra). There are definitely a few gotchas and rough edges but after the first invocation things are super fast. It's nice not having another set of boxes to manage. And our Lambda costs themselves come to a couple bucks a day, tops.


i'm working on MindMup, and we're moving almost all our APIs gradually to lambda and api gateway. we have two APIs running there in production at the moment. the benefit is being able to interact with the rest of the AWS stack easily (we use S3 to upload documents for exporting and heroku to process them at the moment, and dynamodb for storing user accounts and license information). ideally, at the end of the migration, we'll just kill all the heroku exporting and licensing services. should be cheaper as well, because we will be able to kick off lambda functions on s3 events instead of polling for s3 changes from heroku.

everything is versioned (so different api endpoints for staging, prod and development can talk to different versions of the lambda function), which is a big plus.

the api gateway stack is highly opinionated, as in it's good for JSON data parsed using Java on the back end (API gateway uses velocity). our strategy is to use it as a nodejs backend, so there was a lot of magic involved in the setup. it's not well documented and it discovering things like "$input.json('$') means entire body" is not easy. also we wanted to return errors as HTTP codes, not just in the JSON message body.

the setup initially was horrible and magic, but it's luckily automatable. I got it working well so that a single lambda function can receive calls from multiple api paths (so we can deploy an entire API at once, and manage dependencies simply), and that all the environment configuration is in the api gateway, not lambda (so a single function can be invoked with production/staging/development environment parameters).

it took me a while to figure out exactly how to pass things up and down the stack, and we ended up building something similar to apex (but significantly simpler due to a limited use case). a single command-line request packs up everything, uploads lambda, creates and configures the API gateway functions, manages versions and permissions, so it's relatively easy to create a new JS function tied to a URL in the API gateway now. It kind of looks like sinatra. we might end up opensourcing that if I get a chance to clean it up.


I tried to use and love lambda, spending a lot of time making my use-case work for their poor development and deployment environment (a zip file, really??). In the end, I had to abandon the effort.

They only allow a certain fixed execution time and 500 mb of temp space, max. And they won't raise these limits.

During testing I noticed that frequently I would have the same contents of empirical storage (/tmp) -- i.e. i'd be running on the same host.

I have a sneaking suspicion that the entire purpose of lambda is to resell capacity on hosts that aren't busy -- but could be -- thus the low CPU time limits and storage spaces. I'm sure someone would not notice 500 MB or 5 minutes of CPU time vampired on their less busy, not monitored hosts from time to time. And if the real user does need the capacity, they can just kill the process, which had happened many times in my testing (process would be killed or die for no reason).

Sounds great and amazing in theory, but execution is horrible and unusable except as a toy.


I had a similar feeling when I first tried it. The UX is really bad, I'll give you that! For my current use-cases though I think it'll be just fine.

That's interesting about the random kills, I'll keep an eye out for that, good to know. Interesting theory though haha, wouldn't surprise me too much.


At Cronitor we've just finished building out lambda infrastructure for a fan-out where I would otherwise use a worker application and Supervisord.

Lambda has a lot of strengths, and it gives you solid primitives like immutable versions, version aliases/pointers and stateless functions.

The problem I had was that it didn't give me any more than that. Here are just a few of the things we had figure out and then build ourselves:

1. The development workflow. How can I get a REPL workflow going that doesn't make me go crazy.

2. Deploys and Rollbacks. How can we safely deploy and rollback, especially in cases where you have the same lambda function in multiple regions and each region is at a different published version (because the version number is monotonically incrementing)

3. Permissions and Policies. The broad strokes are clear. But you want your S3 bucket or SNS topic to trigger lambda? Get ready to spend an hour trying to figure out what you've done wrong and what's missing from the vague directions. Hope you get that REPL flow solid first.

In the end, we built several scripts (create_build, publish_version, promote_to_prod, etc) and we use these directly during development and from a Fabric-based deploy script. When I have time I plan to release this tooling open-source.

If I had to do it all over again, I wouldn't. And I wouldn't use Apex (at least not yet). I would just use a t2.small instances with a simple worker.


I love the idea of developers working on code, and not infrastructure, and so I love open source projects that solve this problem (by automating infrastructure).

But I will never support anything that locks me into a particular vendor.

There are many reasons, from geopolitical to economic, that any open source infrastructure effort should be vendor neutral.


Would be nice to see something like Apex that can work on Lambda or within some kind of deployable service, so that the environment it actually ran on was abstracted, avoiding vendor lock-in. I haven't seen any projects yet that try to make the Lambda interface portable though.


I'm ok with using AWS for now. The trade off is this limitation you are pointing out, vs. saving dev ops effort.

Anyway what is novel this year at AWS becomes industry standard and commoditized later.


Depending on what you use it's not much lock-in. In most cases you'd delegate the handler to some package/library anyway so you're just interpreting the Lambda "event" and "context", much like writing the bulk of your HTTP handlers inline is usually a bad practice.


You can very quickly build wrappers around Lambda code to be able to use its functions in a traditional webapp (at least in node). If you need to use a different vendor you can change it relatively quick.


tl;dr: You would need a relatively simple Node.js/Express based backend for Apex, compared to its current AWS API Gateway + AWS Lambda backend.

Maybe TJ could correct any inaccuracies here:

It sounds very much like the Node.js shim used for local testing or other languages could be enhanced to listen to a TCP port rather than use stdin/stdout.

At which point, instead of just using the shim for local testing, you could deploy Apex + Shim to any VM and port. No more lock in.


Fair. But there is no open source implementation of Lambda right now, as far as I'm aware. Hopefully if there were such a thing Apex would support it.


There is a stream and batch processing framework called Apache Apex. Might be a good idea to change the name. See https://www.datatorrent.com/apex/


Salesforce also has a language called Apex https://developer.salesforce.com/page/Apex


And Oracle, god make their sandals rot, have "Application Express", often abbreviated to ApEx.


Oracle ApEx, which is a competitor of the Force.com platform. Man how strange corporate tech is...


The product itself (http://apex.oracle.com and http://apex.oracle.com/ut/) isn't bad: it's tailored toward citizen developers versed in the Oracle DB.

Off topic: if you're reading this, Vlad my boy, I will think about sending you an email at some point. Because we all know how you love emails.


It's ... a thing. I don't miss it.


ape-x could do... ;)


There's some limitations with both lambda and the API gateway that you need the be aware of -

API gateway has a fixed timeout of 10 seconds that you can't currently extend. Should be fine for most use cases, but something to be aware of if you have any functions that will take longer.

Lambda functions cannot return binary data.


Another big limitation is that you currently can't run lambdas in a VPC, so using Lambda with RDS is pretty much off the table if you don't want your database to be open to the world.


Looks great, and the discussion on HN is always helpful to find other related projects.

I've just finished prototyping a A/B testing backend running over Lambda / API Gateway. I think I bumped into some of the rough edges others are mentioning.

What troubled me the most however is how difficult it is to share / open-source the code for such a project. There are no environment variable support, so to configure things you have to embed them in code. No way to easily package something that users can just run a few simple commands and get up and running (I think having an AWS CLI + keys already set up is a pretty hefty upfront requirement). So you end up with a huge readme or a blog post just to explain how to set up all the moving parts. A small mistake anywhere along the process and this thing isn't working any more...

I hope tools like Apex can also solve this use-case. Something akin to the heroku / digitalocean button would be truly awesome.


Looks like "serverless" is the new buzz word for App Engine or Heroku?


Which is too bad because there is a lot more interesting things you could do if you really didn't need the cloud, and connected apps could run client only.


Especially after VoLTE, all 4G data are IP based and even voice data are actuall controllable in Application Processor, it's basically SIP+RTP on a port like 5060. Someone need to develop a VoLTE p2p.


Exactly! PaaS was exactly the thing which supposed to allow developer focus on application code, instead of infrastructure. And actually App Engine is exactly working for me this way.


I think of Lambda like I think of database triggers. It's a great solution for the specific thing that it's built for but people have a tendency to go very overboard with it.

Built for: Triggering events when something happens within AWS Not built for: Replacing all of your servers

I once knew a guy who was very into Oracle and wanted to server up HTML from stored procedures. This strikes me as that line of thinking.


Serving up HTML from Stored Procedures was a thing back in the late 90's/early 2000's as enterprise vendors made the shift to web apps.

In fact quite a popular thing for client-server app's where the server was built in PL/SQL, and some clients just needed reports.

I agree, AWS Lambda is a hammer. Just like everyone in enterprise software jumped at J2EE and Enterprise Java Beans back in early 2000's, and "did it wrong", I expect the same to happen here.

I just wish I know of a decent Open Source project doing similar things in a super-light-weight fashion - ideally in Python.


Well, if you look at Lambda as a simple event notification system that integrates with AWS your closest equivalent is PHP.

PHP isn't integrated with the AWS stack, but you could drop a terabyte of code on a 256mb VM and it would all run when called. Scales down really well, which is great for housing little one off scripts to receive web hooks at minimum cost, utility servers, etc. It's not sexy, but very effective.

I'd imagine you could do the same type of thing with Python in a CGI mode or something along those lines, but most other languages purposed for web stuff tend to need to load a lot of libraries at runtime to operate that way.


https://github.com/garnaat/kappa targets the same feature set, and has more functionality afaics, albeit perhaps slightly different. It has more sources to bind lambda to, and takes care of more of the drudgery (iam, permissions, etc). It doesn't do the nodejs shim for go.


[deleted]


I don't think TJ is making any claims that it is cheaper.


Am I the only that can't fucking scroll down on this site. I didn't know this was so annoying.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: