AWS Elastic Beanstalk vs. AWS Lambda vs. SQL Server Integration Services (SSIS)

AWS Elastic Beanstalk is well suited for [the] rapid development of applications that use standard compute platforms based on popular programming languages. So getting a Go, Python, Ruby, or Node.js app going in AWS Elastic Beanstalk will be easy. For non-standard applications, containers provide another option for using AWS Elastic Beanstalk. In either case, AWS Elastic Beanstalk is well suited for applications that are [self-contained]. AWS Elastic Beanstalk is also good for development or test environments that need a built-in deployment method. AWS Elastic Beanstalk is less appropriate for complex applications that rely on multiple AWS services. While deploying and running the base code might be easy to get going, it may be difficult to apply permissions and integrations with the other services.

Incentivized

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

Ideal for daily standard ETL use cases whether the data is sourced from / transferred to the native connectors (like SQL Server) or FTP. Best if the company uses MS suite of tools. There are better options in the market for chaining tasks where you want a custom flow of executions depending on the outcome of each process or if you want advanced functionality like API connections, etc.

Incentivized

• Extremely easy to get set up and get apps deployed.
• Integrates really well with existing build processes and is manageable through a suite of CLI tools.
• It is very easy to scale up.
• The documentation is exceptionally detailed and covers a very wide range of deployment scenarios.

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

• SSIS works very well pulling well-defined data into SQL Server from a wide variety of data sources.
• It comes free with the SQL Server so it is hard not to consider using it providing you have a team who is trained and experienced using SSIS.
• When SSIS doesn't have exactly what you need you can use C# or VBA to extend its functionality.

Incentivized

• How to more easily integrate with other other AWS services. There are plenty out there, but it's not quite as seamless as I feel like it should be to mix and match products.
• Make backing up easier when scaling the server. It took quite a bit of time to make sure we had everything set up in case something went wrong.
• When you are first starting to use AWS, the dashboard can be very intimidating. There are countless products all with names that aren't very indicative of what they actually do.

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

• SSIS memory usage can be quite high particularly when SSI and SQL server are on the same machine
• SSIS is not available on any environment other than Microsoft Windows
• SSIS does not function with any database engine back-end other than Microsoft SQL Server

Incentivized

As our technology grows, it makes more sense to individually provision each server rather than have it done via beanstalk. There are several reasons to do so, which I cannot explain without further diving into the architecture itself, but I can tell you this. With automation, you also loose the flexibility to morph the system for your specific needs. So if you expect that in future you need more customization to your deployment process, then there is a good chance that you might try to do things individually rather than use an automation like beanstalk.

Incentivized

SSIS is responsible for running core business processed managing core business data. It can be managed, improved and expanded using minimal internal resources. It is also able to support all of our current data infrastructure. Replacing SSIS would be time consuming and costly with no apparent ROI.

Incentivized

The overall usability is good enough, as far as the scaling, interactive UI and logging system is concerned, could do a lot better when it comes to the efficiency, in case of complicated node logics and complicated node architectures. It can have better software compatibility and can try to support collaboration with more softwares

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

It is easy to learn, works great on many features, but needs improvement on ETL troubleshooting and performance monitoring functionality. Great tool on Microsoft stack. it is great with simple, structured datasets. Once logic gets fancy like nested conditionals
complex joins,
reusable transformations, versioned logic …SQL Server Integration Services (SSIS) packages become hard to read and harder to maintain. Source control is painful. Errors can be cryptic
Logging takes effort to set up well
Debugging in production is limited.

Incentivized

Raw performance is great. At times, depending on the machine you are using for development, the IDE can have issues. Deploying projects is very easy and the tool set they give you to monitor jobs out of the box is decent. If you do very much with it you will have to write into your projects performance tracking though.

Incentivized

As I described earlier it has been really cost effective and really easy for fellow developers who don't want to waste weeks and weeks into learning and manually deploying stuff which basically takes month to create and go live with the Minimal viable product (MVP). With AWS Beanstalk within a week a developer can go live with the Minimal viable product easily.

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

The support, when necessary, is excellent. But beyond that, it is very rarely necessary because the user community is so large, vibrant and knowledgable, a simple Google query or forum question can answer almost everything you want to know. You can also get prewritten script tasks with a variety of functionality that saves a lot of time.

Incentivized

- Do as many experiments as you can before you commit on using beanstalk or other AWS features. - Keep future state in mind. Think through what comes next, and if that is technically possible to do so. - Always factor in cost in terms of scaling. - We learned a valuable lesson when we wanted to go multi-region, because then we realized many things needs to change in code. So if you plan on using this a lot, factor multiple regions.

Incentivized

The implementation may be different in each case, it is important to properly analyze all the existing infrastructure to understand the kind of work needed, the type of software used and the compatibility between these, the features that you want to exploit, to understand what is possible and which ones require integration with third-party tools

Incentivized

There are many services like AWS Elastic beanstalk, but there are none with the maturity in the platform or the cost-effectiveness of AWS Elastic Beanstalk. Also, AWS Elastic Beanstalk is the oldest among them, so there are more people with AWS experience than the other platforms. The only thing is their documentation and UX are a bit old, which doesn't stop it from performing greatly, but yes, if you are looking for better UX, then you can check out other options.

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

Both are very similar. Azure is cloud based. It is easier for the organization who uses cloud based application. The SQL Server Integration Services is cost effective. Azure was more on the expensive side for our organization. Azure was a little complex, it needed special training to use it. Azure was not accurate with complex data.

Incentivized

• Elastic Beanstalk removes countless hours from development team responsibility, freeing up those resources to instead focus on building the products that our customers want to use.
• As a business that is already embedded into using EC2 instances, it's essentially free to leverage the work that AWS performs on configuring the Elastic Beanstalk stacks.
• With Elastic Beanstalk, while there is still a responsibility to ensure that applications can work with updated underlying dependencies, it's much easier when AWS handled the heavy lifting of updating the stacks.

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

• Without this, we would have to manually update a spreadsheet of our SQL Server inventory
• We would also have poor alerting; if an instance was down we wouldn't know until it was reported by a user
• We only have one other person who uses SQL Server Integration Services , he's the expert. It would fall to me without him and I would not enjoy being responsible for it.

Incentivized