Apex lets you build, deploy, and manage AWS Lambda functions with ease(apex.run)
apex.run
Apex lets you build, deploy, and manage AWS Lambda functions with ease
http://apex.run/
58 comments
The "tedium" that Apex & Serverless manage for you are a subset of the "tedium" that you need to manage when you are using servers. You can't get rid of that, but you can avoid all the other stuff involved with managing servers.
For the case of Apex, I think "deployment tool" is better than framework. There isn't really any magic here. At least nothing you couldn't do yourself in the AWS console or UI. It would just suck for more than a few functions. This is automating all the clicking you would have to do otherwise and giving you a sane way to manage functions that can be grouped together.
you need to consider the alternative. I've been running unix boxes for 30 years, and even though it's node.js-based, even though it's amazon's usual byzantine nonsense, even I think Lambda is a total game changer in the making.
Not just from a deployment standpoint, but from a development standpoint! Lambda enforces boundaries and clarity, and strongly encourages simplicity. So, so much better than monolithic app servers.
A bit of background: it's the first company from TJ [1], one of the creators of Express JS [2] and a collaborator to Node.js [3]. I've been following TJ's work for a while :)
[1] https://medium.com/apex-software/announcing-apex-software-in...
[2] https://strongloop.com/strongblog/tj-holowaychuk-sponsorship...
[3] https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e...
[1] https://medium.com/apex-software/announcing-apex-software-in...
[2] https://strongloop.com/strongblog/tj-holowaychuk-sponsorship...
[3] https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e...
A bit more than just Express: Mocha, Jade, ejs, superagent, Koa, etc.
I didn't try it yet but it seems very useful.
I don't see a way to bind a function to a URL on the Amazon API gateway. Is it a missing feature or did I miss it in the documentation? I ask because setting up the URLs that map to functions is the most annoying task with Lambda and must be automated.
I don't see a way to bind a function to a URL on the Amazon API gateway. Is it a missing feature or did I miss it in the documentation? I ask because setting up the URLs that map to functions is the most annoying task with Lambda and must be automated.
It doesn't surprise me that people want to do that, but the design intention of Lambda is to invoke it asynchronously via writes to dynamodb, s3, sqs, IoT etc. I wouldn't make any assumption that someone building tools for Lambda is going to prioritise integration with the API Gateway and its somewhat alien synchronous behaviour.
The best fitted Lambda apps are going to have an event-sourced CQRS style, I think. AWS IoT is kinda the last piece of that puzzle to fall into place.
The best fitted Lambda apps are going to have an event-sourced CQRS style, I think. AWS IoT is kinda the last piece of that puzzle to fall into place.
There is nothing wrong with using lambda to synchronously respond to user facing API requests. It actually works really well and I would highly recommend it. Were doing it in production at ~15 million calls/day.
Isn't it expensive though?
That is the best part! It is cheaper! We had a node service that went from $2500/mo to $400/mo just by switching form Ec2 to Lambda. That is the most apples to apples comparison I can give you. Other services were split up or rewritten, but honestly my gut feeling tells me they are costing 10x-50x less.
IMO Autoscaling ec2 instances to daily traffic is not a trivial problem and you'll never get the granularity you can with Lambda
IMO Autoscaling ec2 instances to daily traffic is not a trivial problem and you'll never get the granularity you can with Lambda
You are also saving in not having someone maintaining and making sure the server is always online. Even if it was the same price, not having to worry about the server is a big plus
Cheaper than standing up enough EC2 instances to do the same volume. That's the idea at least.
Strictly looking at server uptime, yes, it's nearly 5x the cost of comparable t2 on-demand EC2 instances. That can be mitigated if you have spiky traffic where you'd need to turn on several EC2 instances for less than an hour but are stuck paying for the full hour, or if you can scale to zero for extended periods of time. You don't have the ability to serve concurrent requests from a single lambda worker, so if you're waiting for async IO then you're wasting money you wouldn't be wasting with EC2. -- For us lambda was prohibitively expensive at scale. I suspect a fair number of people reporting significant savings vs EC2 had over-provisioned instances.
But there are already tools like
https://github.com/Miserlou/django-zappa
https://aws.amazon.com/blogs/compute/building-enterprise-lev...
plus something else that was featured on HN recently and I can't find or remember.
Amazon itself has a tutorial about the integration of the API gateway with Lambda at http://docs.aws.amazon.com/apigateway/latest/developerguide/...
I saw an evangelist demoing it at an Amazon Summit a month ago. It's so time consuming and error prone that you don't want to do it manually more than once (not that he made any mistake).
So I won't say it's a corner case. Maybe it's too early to know what Lambda will grow into.
https://github.com/Miserlou/django-zappa
https://aws.amazon.com/blogs/compute/building-enterprise-lev...
plus something else that was featured on HN recently and I can't find or remember.
Amazon itself has a tutorial about the integration of the API gateway with Lambda at http://docs.aws.amazon.com/apigateway/latest/developerguide/...
I saw an evangelist demoing it at an Amazon Summit a month ago. It's so time consuming and error prone that you don't want to do it manually more than once (not that he made any mistake).
So I won't say it's a corner case. Maybe it's too early to know what Lambda will grow into.
What's the point of API Gateway? Looks like a proxy where you recreate your api and does nothing more.
API Gateway does a number of things. It distributes endpoints via cloudfront, which is pretty awesome. It serves as a unified front end for a collection of back end microservices. It handles client cert authentication (important to us, but not to most people) and api keys for you, and a bunch of other neat stuff as well. And it offers a test harness where you can mock up data easily.
In theory, you could do the same thing with nginx and load balancers and multiple ec2 instances, but it'd be a lot more work. And I think the real magic is with integration with Lambda. That's a game-changer.
In theory, you could do the same thing with nginx and load balancers and multiple ec2 instances, but it'd be a lot more work. And I think the real magic is with integration with Lambda. That's a game-changer.
Offloading some calls into lambda does look cool
I think I leant about it when I learnt about Lambda. In this context it's a convenient way to give a URL to a function, pass parameters to it and get back the result. You could build HN with the API gw, one Lambda function per each request and a db.
That's exactly what I'm suggesting is an anti-pattern. Yes you can do that. Yes it's hardly surprising that AWS make it possible, since synchronous RESTful CRUD is such a popular integration approach and often the first one we learn.
But I'd advise you to design your LambdaNews service using an asynchronous event-driven model instead. You'll find it reduces complexity and makes for a snappier, more reliable client experience (e.g. no 429 throttling responses to handle). You'll also find that the supporting AWS services like Kinesis, Cognito, IoT, SNS, SQS, DynamoDB, S3 etc are much more in tune with that pattern.
The fact is that async platforms scale much better than anything that has to block and poll. It should hardly be surprising that at AWS's massive scale, it becomes a preferred service design pattern.
Pub/sub integration people have known this for decades, it is not news.
obdisclosure: I am ex-AWS but all the above is derived from public statements and documentation.
But I'd advise you to design your LambdaNews service using an asynchronous event-driven model instead. You'll find it reduces complexity and makes for a snappier, more reliable client experience (e.g. no 429 throttling responses to handle). You'll also find that the supporting AWS services like Kinesis, Cognito, IoT, SNS, SQS, DynamoDB, S3 etc are much more in tune with that pattern.
The fact is that async platforms scale much better than anything that has to block and poll. It should hardly be surprising that at AWS's massive scale, it becomes a preferred service design pattern.
Pub/sub integration people have known this for decades, it is not news.
obdisclosure: I am ex-AWS but all the above is derived from public statements and documentation.
I'm sincerely interested. The POST I use to submit this comment can be asynchronous, no problem (just do ajax). Same for votes and flags. The GET I use to get the page could be a real HTTP GET or diffs coming over a websocket (but I need a page to start with). I'm not sure how to implement that in the AWS ecosystem because I don't have much experience on it, but is it this what you mean with "asynchronous event-driven model"?
> but the design intention of Lambda is to invoke it asynchronously via writes to dynamodb, s3, sqs, IoT etc.
I wish they (they being AWS or Apex or someone in this space) said this explicitly. Every time I've read about Lambda I've thought it's interesting but am not sure how/where to invoke it in production.
I wish they (they being AWS or Apex or someone in this space) said this explicitly. Every time I've read about Lambda I've thought it's interesting but am not sure how/where to invoke it in production.
Here's their documentation on the various ways to invoke a lambda function (including the API Gateway, contrary to what was stated above):
http://docs.aws.amazon.com/lambda/latest/dg/intro-core-compo...
http://docs.aws.amazon.com/lambda/latest/dg/intro-core-compo...
I built a tool to do just that: https://github.com/bustlelabs/shep
It currently only supports node. If you are looking for just lambda, Apex is an awesome tool. But for us we needed end to end integration with API gateway and I wasn't happy with any of the other tools out there.
It currently only supports node. If you are looking for just lambda, Apex is an awesome tool. But for us we needed end to end integration with API gateway and I wasn't happy with any of the other tools out there.
Looks like they're not trying to do that yet. Serverless (serverless.com) has done that; Apex differentiates itself from Serverless in the OP.
Serverless (the framework) does this, FYI
I just started using AWS Lambda, can someone explain why this would be better than using AWS console/sdk?
I don't use apex. I use serverless. but it's probably the same idea. All the work of transpiling, minifing, creating lambdas, api gateway, aws resources, stages etc... are done automatically from the command line. You don't need to compile/transpile your code, create a zip, upload to s3, create a lambda import the zip from s3, create the endpoint, connect to the lambda, create the api gateway template, etc... And do this every time you change something in your code. It gets frustrating really fast when doing it manually.
awesome thanks.
Once you get beyond "just started" you'll see the value of these tools :-) The charm of Lambda is that it's easy to get rolling, but then the AWS complexity seeps in. This helps deal with a _lot_ of that in a pretty sane way.
The AWS UI and console are great for <10 functions. 100 functions... not so much. It becomes necessary to automate things and Apex provides that. If you are just getting started, I'm not sure it is "better". But if your entire stack is lambda funcs its almost necessary to keep your sanity.
I'm using Serverless framework now, but given that Apex can run codes other than JS and Python, might as well give it a try!
https://github.com/serverless/serverless
https://github.com/serverless/serverless
> curl https://raw.githubusercontent.com/apex/apex/master/install.s... | sh
When did package manager go out of style?
When did package manager go out of style?
As soon as people realised there was an easier way than building and testing packages on 8 different distros, then having people whine because they don't act "right" for each distro. Packaging takes a lot of time out of development work.
so does that mean there's no equivalent of `pypi` or `npm` for go? Or is the point to not impose any requirements on the user?
It's a single binary, there isn't much "acting right" to be done. Build, install to /usr/bin with appropriate permissions and be done with it. It's not like Go is dynamically linked and requires you deal with varying soname's between distributions.
Every time I look into packaging it seems like it has become even more of an arcane art (or I just don't know what to search for). Most guides and tools seem to aim at package maintainers for individual distros, which have different needs then someone wanting to package their individual software for as many distros as possible.
What are the tools to use to solve this?
What are the tools to use to solve this?
> Every time I look into packaging it seems like it has become even more of an arcane art
Plenty of people willing to help out!
The Fedora wiki actually contains a lot of general information on just creating RPM's, if you aren't planning on submitting and maintaining your software for inclusion in the Fedora Software Collection you don't need to be overly-zealous about following the Fedora Packaging Guidelines (though we hope you do, because it makes your software easier to use and less likely to break). "How to create an RPM package" is a good start [0]. The rpmdev-newspec tool part of the rpmdevtools package will generate you a decent skeleton you can use to get started with, though they still have some warts as they haven't been updated (they still call rm -rf $RPM_BUILD_ROOT which hasn't been necessary since EL6).
For the most part, an SRPM built for Fedora or EL* should also be able to be compiled for OpenSUSE - with some exceptions where package naming differs or incompatible software versions are present (you'll have to solve these issues with conditionals). The same will typically be the case with .deb's built for Debian and derivatives.
The Open Build Service from the OpenSUSE project [1] is an excellent tool for building and publishing packages for many different distributions, it won't save you from writing your spec files and debian/ files, but it will save you some time in building new releases afterwards (and it encourages the one rpmspec-with-conditionals workflow, so you don't maintain separate spec files for different distributions).
Of course, I'd always like to see developers trying to get their software in the distribution repositories, but you probably don't want to go through the hassle of joining Fedora/Debian/Ubuntu/etc just for that. However, if you already have a working rpmspec file and an sane build system that doesn't require crazy tweaks you can probably find a packager willing to work with you.
I haven't messed with debian packaging in a while, but if you have any questions about creating RPM's feel free to email me ([email protected]).
[0]: https://fedoraproject.org/wiki/How_to_create_an_RPM_package
[1]: https://build.opensuse.org/
Plenty of people willing to help out!
The Fedora wiki actually contains a lot of general information on just creating RPM's, if you aren't planning on submitting and maintaining your software for inclusion in the Fedora Software Collection you don't need to be overly-zealous about following the Fedora Packaging Guidelines (though we hope you do, because it makes your software easier to use and less likely to break). "How to create an RPM package" is a good start [0]. The rpmdev-newspec tool part of the rpmdevtools package will generate you a decent skeleton you can use to get started with, though they still have some warts as they haven't been updated (they still call rm -rf $RPM_BUILD_ROOT which hasn't been necessary since EL6).
For the most part, an SRPM built for Fedora or EL* should also be able to be compiled for OpenSUSE - with some exceptions where package naming differs or incompatible software versions are present (you'll have to solve these issues with conditionals). The same will typically be the case with .deb's built for Debian and derivatives.
The Open Build Service from the OpenSUSE project [1] is an excellent tool for building and publishing packages for many different distributions, it won't save you from writing your spec files and debian/ files, but it will save you some time in building new releases afterwards (and it encourages the one rpmspec-with-conditionals workflow, so you don't maintain separate spec files for different distributions).
Of course, I'd always like to see developers trying to get their software in the distribution repositories, but you probably don't want to go through the hassle of joining Fedora/Debian/Ubuntu/etc just for that. However, if you already have a working rpmspec file and an sane build system that doesn't require crazy tweaks you can probably find a packager willing to work with you.
I haven't messed with debian packaging in a while, but if you have any questions about creating RPM's feel free to email me ([email protected]).
[0]: https://fedoraproject.org/wiki/How_to_create_an_RPM_package
[1]: https://build.opensuse.org/
FPM[1] will get you most of the way there, but your packages are still going to seem a bit out of place unless you make distro specific changes.
[1] https://github.com/jordansissel/fpm
[1] https://github.com/jordansissel/fpm
Seems interesting, although I find it amusing that a tool to make system-level packaging easier wants to be installed with "gem install"... no dogfooding?
If you're really interested in a serverless stack, check out https://github.com/anaibol/awesome-serverless
Apex is totally awesome. Especially if you are just concerned with Lambda. But if your looking for something that integrates with both Lambda and API gateway check out the tool I wrote: https://github.com/bustlelabs/shep
good stuff! added you to https://github.com/anaibol/awesome-serverless
Thanks!
Salesforce is not gonna like this. They already have a "cloud" programming environment called Apex.
https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...
https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...
And it's a special kind of hell.
Reserved for people who talk at the movies.
Reserved for people who talk at the movies.
Eh, Apex certainly isn't amazing (and the debugging experience is absolutely awful) but the limited code I have to maintain in our org (where workflows and other drag-and-drop tooling weren't sufficient to get the job done) has been quite easy to develop and maintain.
Problems usually come from trying to make applications that aren't well suited to the Salesforce platform work on it natively - it's great for CRUD apps with workflows, a custom visualforce page here or there and some more complicated logic implemented in Apex sprinkled in - but if you are resorting to Apex to do the majority of your work you are likely using the wrong tool for the job.
Problems usually come from trying to make applications that aren't well suited to the Salesforce platform work on it natively - it's great for CRUD apps with workflows, a custom visualforce page here or there and some more complicated logic implemented in Apex sprinkled in - but if you are resorting to Apex to do the majority of your work you are likely using the wrong tool for the job.
I've used Apex and I had a completely different experience. The very tight platform integration with force.com, SOSQL, resource management, builtin testing and api framework made it a very productive experience to me. And I say this with a long background in C, C++ and Python.
Having to ship your code back to the mothership to run unit tests made it impossible to run TDD (~30 second overhead on each test run). That along with the test coverage requirements made it a pain on the first level. Unless you're using their utterly abysmal in-browser editor.
On the second level is if you're building an app that needs to talk bidirectionally to salesforce on a per customer (app install) basis. Each salesforce site has their own WSDL URLs. That makes sense if all you're doing is building something out for your own Salesforce site.
But if you're building something installable over their marketplace .... it's almost impossible to have a seamless user experience, from the customer's point of view.
On the second level is if you're building an app that needs to talk bidirectionally to salesforce on a per customer (app install) basis. Each salesforce site has their own WSDL URLs. That makes sense if all you're doing is building something out for your own Salesforce site.
But if you're building something installable over their marketplace .... it's almost impossible to have a seamless user experience, from the customer's point of view.
[deleted]
And Oracle neither. They have a webapp framework called Apex as well.
https://apex.oracle.com
Slight difference. Salesforce's Apex is name of their programming language. They don't compete directly I don't think?
In terms of general use-case they do, they are both database-driven RAD tools at the end of the day (Salesforce is just a database at the end of the day with a lot of tooling and basic schema-design done for you). But I can't say I've ever seen someone compare them, they aren't usually used by the same customer segments.
Note: I stumbled across this while Github stalking TJ Holowaychuk to see what he was up to these days. :)
Still waiting for php
In my view, they got it wrong. If the service is too cumbersome to use and requires these extra frameworks to actually use them effectively, then there's a fundamental problem with the service it relies on.