21

I'm pretty new to the whole Netflix OSS stack and deployments in general. As a background for my current level of knowledge ops-wise, my main role is as a front-end application engineer. However, I enjoy the operations side of things, so I'm attempting to setup a new deployment strategy and the tooling for a new project.

Our Goals

  • Super easy deploys (we want to push a button to update production)
  • Automated deploys to test environments (using Jenkins)
  • Ease of maintenance (we have an app to write, don't want to spend our time fiddling with production issues)
  • Ability to handle a service oriented architecture (many small apps, various languages and data stores)
  • Enough flexibility to ensure we won't have to change strategies any time soon (we're already trying to get away from RightScale)

We're OK with a little more initial setup time if doing so will save us some headaches in the future.

So, along these lines, I've been listening to podcasts, watching Ops talks, and reading tons of blog posts and based on our goals and what I've taken to be some forming best practices, we've started forming a plan using Asgard, rolling our package into a jar and rolling that into an AMI.

We had this all planned out and like the advantages the process versus using a Chef server and converging instances on the fly (we felt this was error prone given our limited timeline and lack of understanding around a Chef server workflow). However, a coworker did a little looking around on his own and felt like Elastic Beanstalk met our needs.

I've looked into it and spun up a test environment with a WAR file and an attached RDS database. Things seem to work and I believe that we can automate deploys to a testing environment using Jenkins via the AWS API. Seems simple enough... perhaps too simple.

What I'm wondering is, what's the catch? If Elastic Beanstalk is so simple and effective, why isn't it talked about more? I'm having a hard time finding enough objective opinions and facts about the two different deployment strategies, so I thought I'd ask around.

Do you use Elastic Beanstalk? If so, why and what factors lead to that decision? What do you like and dislike?

If you don't use Elastic Beanstalk but considered it, what do you use and why didn't you use Elastic Beanstalk?

What are the advantages and disadvantages to a Elastic Beanstalk based deployment strategy for an SOA? That is, will Elastic Beanstalk work well with many small applications that rely on each other to work?

James van Dyke
  • 143
  • 1
  • 1
  • 5

2 Answers2

13

I've evaluated Elastic Beanstalk in addition to other AWS offerings while trying to improve our hand-rolled AWS instances. The reasons I chose not to use it were due to complications that would arrise migrating my existing application and not with the offering itself. The catch is that you don't have as much control about application deployment / configuration of the servers. If you are starting a new application then it may be helpful to not deal with those things right now, if you have an existing application then it is more of a challenge to fit in the Beanstalk model.

Beanstalk provides a similar offering to Heroku and other PaaS vendors but not much of a benefit to those who just want to focus on making their application. You do at least get to determine the virtualized resources to a greater degree than other PaaS vendors.

Problems that I was running into with my application(s):

  • Git based deployments - I love them but our repo is 1+ GB. Rather large to push on a regular basis. This repo also contains about 40 applications (which really should be split) but that would take some time. Uploading any sort of package could work but most of our applications would take a large amount of work to make it into a package.

  • Integration with other services - From what I've seen Beanstalk sort of assumes that anything you are connecting to is a single service. This works well if your services are behind and ELB but our were separate nodes that we hit through HAProxy running on each application server. If you are running your datastores and other services as a single endpoint, you should be fine.

In my evaluation I also included OpsWorks and CloudFormation. OpsWorks has similar integration issues with how existing automation was working for these applications. CloudFormation didn't do much more than what some Python scripts and Chef were already taking care of for us.

I wound up choosing to use AWS Autoscaling Groups instead with some automation provided by Asgard. This was the smallest change to existing configuration/application code and provided us with the benefits we were looking for, simple management of multiple servers available through the AWS API.

The restrictions put in place by Elastic Beanstalk on your application are very helpful. You will have to make sure that your application is mostly stateless, provides an endpoint for a service, and relies on other services for state. If you are trying to make reusable stand-alone services that multiple applications in Beanstalk is a great start.

If/when you get to the point of wanting more configuration OpsWorks is a great next step. The predefined roles should make the transition easy to start with and it provides an automation framework around Chef to help coordinate provisioning of multiple servers.

Philip Cristiano
  • 381
  • 3
  • 6
  • 2
    Great answer, Philip. It seems that the greatest limitation for Elastic Beanstalk is whatever the base AMI has setup on it. So, yes, for a basic, stateless service it appears to be great. However, once you need to run multiple services (e.g., nginx, specialized monitoring) inside a single instance, you have to roll your own AMI and then lose out on the base AMI's automatic updates for the AWS services. By that point, you're well into a custom deploy process. My feeling is that that's about the time you'd want to consider moving away from EB. – James van Dyke Jun 26 '13 at 16:38
0

I do see the point of loss of control, but i don't necessarily see the mandated statelessness. All eb really does is deploy automation, which by the way is awesome. I do see the point of a large repository. I think in general that separating logical app functions into separate beans apps, and then have "staging", and "prod" environments underneath, is really nice. We have modules environments like uploader, it does not do very much and in theory it adds a lot of costs, but then u are using smaller instances just more of it. We run a centralized nginx, and had to write alot of custom sns message handles to notify ngnix of changes in auto scale policy. Another big eb issue is inability to turd load balances off, since we use ngnix, why? elb does not support websocket.

Zeev's Glozman
  • 1