AWS Lambda vs. CloudFoundry

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.

Incentivized

It's well suited if:

• The organization has large number of applications that needs to be deployed frequently.
• The organization is tied to the DevOps mindset.
• The organization has programs in different languages.
• The applications does not need EJB's support that servers like web logic provide.

It's less suited if:

• The applications needs security configuration within the same CloudFoundry instance.
• The organization, for whatever reason does not want developers to manage the instances.

Incentivized

• 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.

Incentivized

• Support for Orgs and Spaces that allow for managing users and deployables within a large organization.
• Easy deployment, deploying code is as simple as executing single line from CLI, thanks to build-packs.
• Solid and rich CLI, that allows for various operations on the instance.
• Isolated Virtual Machines called Droplets, that provide clean run time environment for the code. This used to be a problem with Weblogic and other application servers, where multiple applications are run on the same cluster and they share resources.
• SSH capability for the droplet (isolated VM's are called droplets), that allows for real time viewing of the App code while the application is running.
• Support for multiple languages, thanks to build-packs.
• Support for horizontal scaling, scaling an instance horizontally is a breeze.
• Support for configuring environment variable using the service bindings.
• Supports memory and disk space limit allocation for individual applications.
• Supports API's as well as workers (processes without endpoints)
• Supports blue-green deployment with minimal down time

Incentivized

• 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).

Incentivized

• Does not support stateful containers and that would be a nice to have.
• Supports showing logs, but does not persist the logs anywhere. This makes relying on Cloud Foundry's logs very unreliable. The logs have to be persisted using other third party tools like Elk and Kibana.

Incentivized

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.

Incentivized

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.

Incentivized

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.

Incentivized

While Docker shines in providing support for volumes and stateful instances, Cloud foundry shines in providing support for deploying stateless services. Heroku shines in integrating with Git and using commits to git as hooks to trigger deployments right from the command line. But it does not provide on-premise solution that Cloud foundry provides.

Incentivized

• 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.

Incentivized

• Positive impact, since it simplifies the deployment time by a huge margin. Without cloud foundry, deploying a code needs coordination with infrastructure teams, while with cloud foundry, its a simple one line command. This reduces the deployment time from at least few hours to few minutes. Faster deployments promote faster dev cycle iterations.
• Code maintenance such as upgrading a Node or Java version is as simple as updating the build-pack. Without cloud foundry, using web logic, the specific version only supports a specific version of Java. So updating the version involves upgrading the version of web logic that needs to involve few teams. So without cloud foundry, it takes at least few days, with cloud foundry, its a matter of few mins.
• Overall, happier Developers and thats harder to quantify.

Incentivized