AWS Lambda is a serverless computing platform that lets users run code without provisioning or managing servers. With Lambda, users can run code for virtually any type of app or backend service—all with zero administration. It takes of requirements to run and scale code with high availability.
$NaN
Per 1 ms
Heroku Platform
Score 9.2 out of 10
N/A
The Heroku Platform, now from Salesforce, is a platform-as-a-service based on
a managed container system, with integrated data services and ecosystem for deploying modern apps. It takes an app-centric
approach for software delivery, integrated with developer tools and
workflows. It’s three main tool are: Heroku Developer Experience (DX), Heroku
Operational Experience (OpEx), and Heroku Runtime.
Heroku Developer Experience (DX)
Developers deploy directly from tools like…
$25
per month
Pricing
AWS Lambda
Heroku Platform
Editions & Modules
128 MB
$0.0000000021
Per 1 ms
1024 MB
$0.0000000167
Per 1 ms
10240 MB
$0.0000001667
Per 1 ms
Production
$25.00
per month
Advanced
$250.00
per month
Offerings
Pricing Offerings
AWS Lambda
Heroku Platform
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
AWS Lambda
Heroku Platform
Features
AWS Lambda
Heroku Platform
Access Control and Security
Comparison of Access Control and Security features of Product A and Product B
Scenarios where AWS Lambda is well suited: 1. When we need to run a periodic task few times in a day or every hour, we may deploy it on AWS Lambda so it would not increase load on our server which is handling client requests and at the same time we don't have to pay for AWS Lambda when it is not running. So, overall we only pay for few function invocations. 2. When some compute intensive processing is to be done but the number of requests per unit of time fluctuates. For example, we had deployed an AWS Lambda for processing images into different sizes and storing them on AWS S3 once user uploads them. Now, this is something that may happen few times every hour on a particular day or may not happen even once on other days. To handle this kind of tasks AWS Lambda is a better choice as we don't have to pay for the idle time of the server and also we don't have to worry about scaling when the load is high. Scenarios where AWS Lambda is not appropriate to use: 1. When we expect a large request volume continuously on the server. 2. When we don't want latency even in case of concurrent requests.
Heroku is very well-suited to early stage and/or rapidly changing projects. It is great for getting moving quickly or changing direction quickly. In scenarios where there is already scale or well-defined requirements, it may be preferable to set things up directly on AWS or another cloud provider to avoid the additional costs of Heroku as the middleman.
AWS Lambda is a welcoming platform, supporting several languages, including Java, Go, PowerShell, Node.js, C#, Python, and Ruby. And if you need to deploy a Lambda function in another language, AWS offers a Runtime API for integration.
We really appreciate how AWS Lambda is always-on for our functions, with only a brief "cold-start" waiting period the first time a function is called after being dormant.
In addition to only generating costs when it's actually being used, AWS Lambda really puts the "serverless" in serverless architecture, offering turnkey scaleability and high availability for our code with zero effort on our part.
The UI and Developer experience is not so great. IF you use an abstraction like Serverless Application Model (SAM), things get pretty easy, but it's still AWS UI/DX you're working with after that (which is to say, not their strength).
Documentation is always a mixed bag. Sometimes it's just easier to google your specific problem and see how others have solved it. This can be much faster than trying to find an example that may or may not be there in the documentation (which oftentimes has multiple versions and revisions).
Could be less expensive, although you get what you pay for
Sleeping apps can be an annoyance: Heroku automatically puts your apps in sleep mode and they have to spin back up after periods of inactivity. Much of this can be solved but it requires working around the built-in functionality. I understand why they do it but it's an area that could be improved.
Restrictions to server access means you can't customize as much as you could if you owned the server. But again, this is also a benefit because it's about convention over configuration. So you can't configure as much, but then, you typically don't have to.
Heroku is a critical and core part of our infrastructure that is serving our customers well. We are very satisfied with the cost of our solution. While it would be difficult to move away from Heroku, we have no plans to do so. We have had no major issues with it and it is a pleasure to use. Other products on the market might offer comparable functionality, but until we expose a need that Heroku cannot satisfy, we'll stay the course.
It is very easy to get started with AWS Lambda and create your first function. The user interface makes it easy to add AWS services to be inputs or outputs to the function, meaning it can be configured in many different ways for different needs. This makes it ideal for various scenarios in AWS.
If you have basic backend and Git knowledge, deploying to Heroku is a breeze. It now supports many types of backends, including hybrid backends (ex: nginx + application server) through its build pack system. The dashboard is easy to use, and the CLI tools are well designed. Accessing the add-ons is also easy. It uses an SSO-type system so you don't have to re-sign in to view the add-on dashboards.
Heroku availability correlates pretty strongly to AWS US EAST availability. We had a couple of times where there was a Heroku-specific issue but not for the last 7-8 months.
As this is a product where a great part of errors can be at the source code level, AWS support team doesn't dive that further. I mean they don't evaluate problems more complex related to your code, [which] is totally understandable, but this make[s] debug process more tough and painful.
I've used it for many years without facing any major problem. It's not hard at all to get used to it, it's documentation is outstanding and simple. We are close to 2020 and I don't think most of the existing companies or startups should still face old problems such as wasting time deploying code and calculate computing resources.
Be ready to pay a bit more than expected in the beginning if you're migrating from a big server. The application is probably not ready for the change and you have to keep improving it with time.
It's also important to consider that you can't save anything to the disc as it will be lost when your application restarts, so you have to think about using something like S3.
It's fine, it works as the others would have, except EC2. We are migrating back to EC2 for dedicated compute because we have scaled to a point where we have consistent traffic. The tradeoff of maintaining infrastructure in-house outweighs the benefits of moving quickly through our roadmap.
Heroku has advantages over Docker, Google App Engine and AWS products, but it depends largely on your use case. If you are already in AWS, it's probably in your best interest to stay with AWS products. However, other "Cloud Formation/Orchestration" products like Docker are typically lacking the ease-of-use factor that allows you to get up and running with Heroku quickly.
We have simplified log fiie ingestion using Lambda functions. The return has been less time worrying about getting logs from source to ingestion; one the process is in place the team is nearly 100% hands off.
We have begun taking a more API focused approach by using API Gateway as the interface to business processes and Lambda as the back end compute. Moving away from server based back ends places us on a path to reducing overall spend in compute costs.
Lambda functions allow us to easily interface with third party services through APIs. This simplifies access management since the function can be granted permissions and access to the function can be gated with API keys and other authentication methods.