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 7.6 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…
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 …
We use AWS as our primary cloud provider due to the overall availability of services, AWS Lambda is just one of the services we use with AWS which allows a more seamless integration for our microservices. AWS Lambda gives us much more flexibility and can be invoked by more …
AWS Lambda is much easier to use than the near alternatives. It is so straightforward and lightweight it is my primary service for handling small transactions or triggers. The other services require more setup time and are more complex to use. AWS Lambda takes your code snippet …
AWS is great product and a close match our expectations. It is close to Azure in function but more feature rich with API and support documents. From my experience, it is cheaper compared with our competitors and provides better interface. Overall our dev engineers prefer AWS …
I've worked previously with Azure Functions which seems to be the direct competitor to AWS Lambda and while Azure Functions worked just fine there seemed to be more configuration and "magic" behind the scenes to it compared to AWS Lambda which is very straight forward. I …
When we use Lambda, we do not need to worry about the infrastructure and costs. AWS can handle it all on its own. For an optimum use case, one can always use AWS Lambda along with API Gateway and Route 53 for the best use case. Cloudwatch can help you identify any issues and …
We also use Google Cloud Functions because we use GCP in addition to AWS. AWS Lambda is comparable to Google Cloud Functions in its functionality. The main advantage of going with one or the other has to do with what resources it will interact with--we use AWS Lambda to …
I have used Azure Functions and Google Cloud Functions. In comparison, AWS Lambda is a bit more difficult to configure out of the gate. But in most cases once the function is in place and running the operation becomes completely hands-off. While I've used Azure Functions and …
Each service has its purpose. With EC2 you can provision servers for customers and internal projects. With EBs you can optimize what you need in performance with what you can afford. With AWS Lambda you can integrate several of these tools to work together or acomplish …
I've used Google Cloud Functions to create apps for Google Home devices. My students find this more difficult to use than AWS Lambda, especially when it comes to setting permissions.
We really did not evaluate them against other products except a little Google research, we are a centralized AWS customer so it was a smooth and simple (even if blind) decision for us.
Jenkins is a solution for CD/CI pipelines. We can leverage this tool to run code automatically. Long-lived applications and jobs can also be run through it.
AWS is a much more mature platform than Microsoft Azure but is a lot more rigid in the portability perspective. If you are in it for the long run then Lambda is great and the best choice.
Since our company heavily relies on AWS already, my team did not consider any other serverless platforms when building our applications. Lambda was chosen by "default", but it's also such a popular platform that we felt we couldn't go wrong.
These are all AWS sister products, so I wouldn't say they are competitors but tools in the same box. They all work quite well together and I would say combined they are greater than the sum of their parts. Cloudformation (and SAM) templates make tying them together pretty …
AWS Lambda is good for short running functions, and ideally in response to events within AWS. Google App Engine is a more robust environment which can have complex code running for long periods of time, and across more than one instance of hardware. Google App Engine allows for …
But other similar things I've used are Azure Functions and GCP Google Cloud Functions. Like all services like this, the support is pretty much the same. AWS Lambda supports enough popular languages, and behaves pretty much the same as all of these similar services. It does it's …
We considered using application deploy in EC2 with Auto Scale but ended up with AWS Lambda as it helps us to simplify our development and deployment process. It allows us to quickly create instances in a short time for processing data when the source application uploads data …
While AWS Lambda doesn't have the UI or the predefined functions that these other services provide, what was apparent to us is the cost saving and flexibility we have with AWS Lambda once we have it set up.
Heroku was more extensive in terms of its operating and scaling from what we witnessed by looking into other options and trying to find the best operating system for a new platform.
Heroku Platform is cheaper to begin with compared to DigitalOcean or Amazon Fargate. The configuration user interface is also arguably easier to understand. With its user friendliness and cheaper tiers, Heroku Platform was our pick to host some of our applications that were …
I believe Azure App Service is pretty similar to Heroku as you can in both deploy your backend applications. However, the dyno concept and it's drastically simple web dashboard makes Heroku a much better and sane alternative to Azure app service. In Heroku, you get abstracted of …
Kuberbetes is an easily scalable docker based option which should need minimal DevOps, however, it has a pretty high learning curve with many decisions that need to be addressed as well as monitoring, logging and security concerns.
Heroku has the advantage of simplifying the development and integration with some services (which in Heroku they call addon) wherein other platforms, certainly for those who don't have much experience, it will take much more development time.
Heroku, in my opinion, is the easiest platform to deploy and host web applications on. From collaboration to deployment, everything is well thought out and bulletproof. If you need advanced server functionality, like a VPC, machine-to-machine communication, etc., you will …
We also use Cloud 66 which provides some of Heroku's features, at a lower price. It still cannot compare to Heroku's ease of use and ability to easily deploy new staging environments though, so we will always use Heroku for at least some of our projects.
Heroku is an all in 1 package for deploying and running your services. It provides an easy to use setup and run for 90% of cases. If you have a more complicated infrastructure, you'd definitely need to move to another hosting provider. But if as long as you can operate within …
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 …
We kicked the tires on OpenShift before deciding on Heroku, and found the platform to be much less intuitive and well-documented than Heroku. It felt like we were constantly trying to implement workarounds for esoteric platform problems, and eventually the work became too …
For a different project, Aptible surpassed Heroku when it came to meeting HIPAA-related requirements, though it offers much less flexibility with add-on services (for obvious reasons). Google App Engine had a much more complicated deployment model and seemed unnecessarily …
To this day no other PaaS matches Heroku in ease of use and maturity. If you want to stay 100% focused on your unique product/service rather than wasting time on boilerplate hosting issues, I can highly recommend Heroku. I personally use it for all of my own websites …
Heroku is the more expensive option for hosting compared to some of the cloud platforms we investigated, but it's worth it for us because of the plug-and-play nature of Heroku deployment. We can be up and running in a few minutes and know with precision how much it will cost us …
Heroku has the easy facility to deploy and host applications while others have to configure a lot. The price of the services is high for others. But within Heroku pricing and easy to maintain under the same roof.
Some APIs are specifically developed to be deployed to certain platforms and usually decision which platform to use is not developer's. Another question is deployment cost and pricing model; in specific cases after price comparison Heroku is often selected among other cloud …
Heroku is a really great platform to get up and running QUICKLY and efficiently. What Heroku is really great at that other services are lacking is ease of use, documentation. It is really great for beginning developers and awesome to get up and running to take care of lots of …
I feel Heroku is lightyears ahead of all other PaaS offerings. To me the competition is between PaaS and self-hosted cloud, not between Heroku and other PaaS providers.
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.
Deploying apps, scaling , managing environment is very simple. Clean interface for logs, metrics and app settings. Deployment is fast. Don't need deep knowledege of devops or cloud. Buildpacks, pipelines, and review apps makes work easier. Detailed guides help solve common problems fast.
Pricing is higher at scale. Autoscaling options are limited.
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.