I am happy with my beans!
Updated August 10, 2019

I am happy with my beans!

Rahul Chaudhary | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Overall Satisfaction with AWS Elastic Beanstalk

Elastic Beanstalk has been around for some time, but it never caught our eye until we started using AWS CodePipeline.
Currently, we use Elastic Beanstalk (EBS) to run applications on our pipeline. Each stage (dev, perf, prod) has its own set of servers defined under EBS. Our current solution is working very well with CodePipeline.
  • Fits perfectly in our infrastructure. CodeCommit, CodePipeline, and AWS BeanStalk, work in perfect harmony.
  • Easy to change deployment configurations. If I need more servers in my EBS, I just change configurations, and with a click of a button I get more servers. For example, moving from nano instances to micro, or simply adding/deleting more servers.
  • Better security, and upgrade. I usually get small notifications of software/OS updates, and if I choose to, I can simply redeploy my application on an upgraded system.
  • Different upgrade strategies. I haven't tested all [of them], but the current one has the transactional type capability, where if my deployment fails, it falls back to the previous stable one.
  • Difficult to understand. No matter how cute and easy the AWS videos sound, I find it difficult to understand. There are just too many configurations.
  • EBS is free, but you pay for the resources. Problem is, I end up using more resources, thus paying more.
  • They could work on their logging system a bit more. I would love more dashboard metrics in logging, and an easier way to look at logs.
  • An option to make the default URL more friendly. I am forced now to use Route 53 to get a more friendly DNS name, but would have loved if they would have provided a better name to begin with. There are long random strings which could go away.
  • I spend less time managing infrastructure. So I plainly saved the cost of one employee.
  • I am completely invested to the AWS environment. Hence EBS is a natural choice. The ROI was significant because I am already invested in AWS.
  • Sticking to one vendor, means my team has to swim in familiar waters.
  • No extra access issues, because our IAM is already set up. Thus onboarding this technology wasn't difficult.
The biggest issue with using Beanstalk, and I guess with every other "infrastructure generators" are the same - what happens after it? You still have to manage it and understand what beanstalk did. So it was not as easy as it showed in the tutorial videos and diagrams. There is a learning curve, and eventually things do go wrong, so it is essential to understand what's happening under the hood.
AWS has good documentation, hands down. Initially I did feel that it was overwhelming, but the more time you spend with it, the easier it becomes. Beanstalk documentation is scattered, so definitely you need to look around a little bit. Other than that stackoverflow and medium like articles were my best friends.
Honestly, I haven't tried any other alternative products. As already mentioned, I am already heavily invested in AWS, so EBS was a natural choice for me. In other reviews, I have found, AWS is better than its competitors. There are more flavors, and options in AWS, better security, better models. Why go someplace else, when what you have serves you better.
- It works perfectly with other AWS resources like CodeCommit, CodePipeline. If you are working in an AWS environment, this is a MUST.
- Once you understand how it works, you can use it to easily scale and manage your application.
- It certainly is better than its competitors.

- More AWS resources to manage. Great! Though AWS is easy, with so many options, it is getting tiring to learn more new AWS stuff. So be careful, EBS isn't hard, but isn't easy either.
- If you have a single server, you don't need it.

AWS Elastic Beanstalk Feature Ratings

Ease of building user interfaces
Platform management overhead
Workflow engine capability
Platform access control
Services-enabled integration
Development environment creation
Development environment replication
Issue monitoring and notification
Issue recovery
Upgrades and platform fixes

Using AWS Elastic Beanstalk

1 - In my small company, Beanstalk is used by the developers. However, in a larger organization, I can see it being used by DevOps team. Developers in my company use it for deployment and management of our applications and containers. It is used in conjunction with the pipeline tools that AWS provides.
1 - Developers in my company use elastic beanstalk to deploy, manage, and monitor the applications in the servers. A developer must know and understand the basics of deploying an application and must understand the overall flow of the application development lifecycle. Having good understanding of AWS services is a given requirement. On top of that, having AWS certification is a big plus, and recommended.
  • Automatically provision the required servers to host the application.
  • Compatibility with AWS CodePipeline and CodeBuild.
  • Automatic scaling.
  • I wouldn't call it innovative, but having an end-to-end pipeline was a big achievement for us.
  • We were able to create our own EC2 images, compatible with beanstalk, with very small footprint which helped us reduce the cost by 20%.
  • We upgraded our beanstalk servers to work with containers.
  • We would like to trigger lambda functions from beanstalk servers.
  • We would like to associate ECS tasks with Beanstalk so that beanstalk can create servers on the fly to host more containers.
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.

Evaluating AWS Elastic Beanstalk and Competitors

  • Price
  • Product Features
  • Prior Experience with the Product
  • Existing Relationship with the Vendor
Beanstalk is part of AWS family, and if you are married to AWS like us, really you are left with little to no option to try other products. Obviously with technology it is possible to have other solutions, but it comes with more headache and price than just settling to use Beanstalk. And frankly it ain't that bad.
For us, we are pro-AWS. Other products in the market like Azure just doesn't cut it for us. Maybe in future we may want to use other vendors just for some simple applications, but not now. Documentation and community support is a big factor in choosing an infrastructure, and AWS excels in that. So if I had to choose again, I will choose the same stack.

AWS Elastic Beanstalk Implementation

- 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.
Change management was a big part of the implementation and was well-handled - First and foremost, planning is the key to use any AWS service. When we initially started, we didn't know all the ins and outs of beanstalk. But we were smart in our implementation. Instead of just deciding that we want to use it, we did a couple of rough POCs to prove that our technology was supported. Then as we progressed, of course we hit issues and that led us to change the architecture multiple times, but each time we learned something new. So it is not a do and forget type of thing. It requires constant learning and be prepared for re-architecture.
  • Sometimes we didn't think our architecture all the way through, leading us to re-architecture and frustration.
  • Changing business requirement, led us to change the beanstalk usage. E.g. going from servers to containers.
  • We soon realized that AWS Is not cheap, and so we had to be clever to reduce our cost as much as possible.

AWS Elastic Beanstalk Support

Good followup
Knowledgeable team
Problems get solved
Kept well informed
No escalation required
Immediate help available
Support understands my problem
Support cares about my success
No - We are a small company, and we cannot afford for a premium support. Other than that, we actually are pretty good with AWS and technology. So far we haven't hit any issue that we cannot solve ourselves or with the help of the community. Additionally there are AWS blogs where we can get help for free.
So we never have directly interacted with AWS support, but we have definitely benefited from some of their staff member's answers and blog posts. In a recent example we were trying to reduce the volume size for our EC2 image. The solution was so specific that we could not find any question on stackoverflow that could help us. Upon searching AWS support site, fortunately we found the exact question that someone else had asked, and they got their answer pretty quickly. The answer was very detailed with step by step guide, so yeah it was an exceptional support for them, and it benefited us too!

Using AWS Elastic Beanstalk

Like to use
Relatively simple
Easy to use
Technical support not required
Well integrated
Feel confident using
Slow to learn
Lots to learn
  • Provision servers.
  • Integrate with out AWS services like AWS CodePipeline.
  • Scaling of servers.
  • Customization of EC2 scripts, e.g. you want to do something at the start when a new EC2 machine is booting up.
  • Managing IAM roles on top of the ones generated by Beanstalk.