QCON NEW YORK 2017

Conference: Jun 26-28, 2017
Workshops: Jun 29-30, 2017

Presentation: Is Mesos DC/OS a better way to run Docker on AWS?

Track: 
Practical DevOps for Cloud Architectures

Location:

  • Salon A/B

Duration

Duration: 
4:10pm - 5:00pm

Day of week:

  • Monday

Level:

  • Intermediate

Persona:

  • Architect
  • CTO/CIO/Leadership
  • DevOps Engineer

More talks on:

Key Takeaways

  • Hear practical success stories of leveraging cloud-deployed containers at smaller scale web properties.
  • Understand cost implications of leveraging containers and understand some strategies to reduce cost.
  • Learn considerations and gotchas migrating from containers with elastic beanstalk to Mesos DC/OS.

Abstract

AWS says you can run Docker using EC2, ECS, or Elastic Beanstalk. The common denominator for these three platforms is that they utilize EC2 instances requiring uniformly-sized instances. Wouldn’t it be nice to be able to mix and match instance sizes in your fleet? Mixed instance sizes are useful when employing cost-management strategies such as reservations and spot instances. Mesosphere’s DC/OS along with Marathon offers the potential of consolidating your instance fleet into a block of computing that you can run long-running Dockerized web applications with.

By decoupling the containers from instances, instances can be provisioned based on cost without having to worry about sizing. In this presentation, we’ll evaluate Marathon running on DC/OS as a replacement for Elastic Beanstalk and/or ECS in terms of functionality, ease of use as well as cost.

Interview

Question: 
What kind of volume and throughput do you see on your sites that for the infrastructure that you are managing? Is it a microservices architecture? How is it designed?
Answer: 
We are talking about something like 50K-60K unique visitors an hour off the main site theknot.com.
Regarding the architecture, I wouldn’t say it’s microservice. I would say it is probably more like more miniservice than micro. There are pieces of it which are like a conglomeration of microservices and, I think over time, what we are doing is we are decomposing it more and more. Where in the .NET days, I believe it used to be one monolithic block. Now we are able to split it up things and we are kind of deconstructing the app into smaller pieces.
Question: 
And all of that is containers based Mesos deployments on beanstalk?
Answer: 
Our containers are Dockerized on Beanstalk. We are looking at Mesos as a potential replacement for the Beanstalk mechanism of deployment.
Question: 
What’s the motivation for your talk?
Answer: 
Cost. One of the things we are concerned about is that our AWS spend has significantly. One problem that we have is in some cases utilization of our fleet is really low, and we are worried about it. Add to that the fact that when you buy reserved instances, you have to pick a size, and (if you pick wrong) there is a huge penalty. AWS lets you switch instance sizes. It becomes this cat and mouse game of "what size do I pick" and "did I pick it too much" and then if pick the wrong one, I’m stuck with all these RIs that are the wrong size. We can switch instance sizes but that pushes out the term of the RI contract which may not be to our advantage. We’d like to get to the point where we can pack many containers on each instance instead of running them one to one as we do now. We’re looking for a way to have more than one container on each instance without having the pain of having to manage the many to one relationship.
One of the appeals of Beanstalk for us is that it’s simple enough that a developer with minimal infrastructure understanding can deploy their container. They can deploy all the time and they don’t require any DevOps assistance. That is our main success factor. We looked briefly at Kubernetes, and it's great for orchestrating containers. But it requires a five-person DevOps team to build a developer-friendly interface to use it. Until that interface is built, whenever the developer needs to deploy software, he/she would have to go to that group.
At XO, our desire is to have teams deploy themselves without having a centralized bottleneck. We don’t want a process is so complicated that you know it requires someone who has knowledge of AWS CLI or orchestration. I’ve been at other companies where that is the case and we don’t want that. That why Beanstalk appeals to us so much.
Question: 
Beanstalk as kind of a PaaS, where you deploy something to it and it handles scale, it handles load based on whatever you need. But I hadn’t heard of it being used with containers. How does that work? You deploy this container to Beanstalk and it just scales horizontally for you as it needs more? Is that the way it works?
Answer: 
Yes. We use ECR, but you could use DockerHub if you wanted to. And you deploy this container and give Beanstalk the image URL. The great thing is because it is all one platform, Beanstalk takes care of that authentication without the pain that you have in Mesos or Marathon. And then you specify your instance size. So that is where the cat and mouse game is: how big do I take it? We try to get an idea like through load testing but sometimes user behavior and usage differs from what we predicted.
You pick an instance size when your Beanstalk is created. Let’s say you pick like M1 large or M3 large. Everything is going to be M3 large until you destroy that Beanstalk, which is fine if that is the right size. But if it’s not the right size, then it’s a little bit of a pain because you have to reconfigure your beanstalk which is somewhat involved. Then what if we deploy a feature then it becomes a popular feature on theKnot and everyone uses it. At that point, we’d want to get bigger instances instead of many small instances. And because it is more cost efficient to have larger instances that is why this is appealing to us. One thing we’ve noticed is that if you look up spot instance prices, the prices for larger instances are generally cheaper per unit of compute than smaller instances.
If we are able to leverage a large instance, it benefits us from a cost perspective. That’s another motivation why we wanted to look at DC/OS because we would buy the cheapest instance on a per-vCPU basis. We’ll load up our fleet that way and reduce our spend. One of our organization’s goals is to run twice the infrastructure at half the cost. This is why we are of looking at DC/OS and technologies like it. Beanstalk is nice and it helped us deploy really fast once we got the containers figured out. But that convenience comes at a pretty big price.
Question: 
QCon targets advanced architects and sr development leads, what do you feel will be the actionable benefits?
Answer: 
I think you are going to get beyond the marketing hype that the Mesosphere is putting out there. You are going to understand what’s involved in deploying DC/OS and the workloads that it’s well-suited for. If you want to run a Hadoop cluster or a Cassandra cluster, you just need to know whether it’s on-premise or in the cloud and deploy your cluster. I was telling my manager about the talk’s abstract and he said that this is great because it cuts through all the marketing. It's awesome if you run those things that they have packaged up like Spark, Hadoop, Cassandra, etc. But if you have private containers or private images that you want to deploy, it is not. With private registries, you have to do some engineering to get that authentication working. So I am going to show how to do that private set up of process to authenticate so you can connect to your private registry because they don’t really show you how to do that.

Speaker: Chien Huey

DevOps Engineer @XO Group Inc

Chien started out his career as a developer with a knack for configuring infrastructure way before the term DevOps was coined. Along the way, he explored the operational side of technology and embraced it after years of the “Get Data, Set Data” developer grind. Always a coder at heart, Chien loves the world where infrastructure is code. Chien is currently a DevOps Engineer at XO Group, Inc.

Find Chien Huey at

Speaker page

@chspinning
DevOps Engineer at XO Group Inc.

Similar Talks

Learnings from a Culture First Startup
CTO @Buffer
Sunil Sadasivan
Docker Container Lifecycles – Problem or Opportunity?
Developer Advocate @JFrog
Baruch Sadogursky
Multi-Host, Multi-Network Persistent Containers
VP of Product @Aerospike
Alvin Richards
Securing Your Containers
Global Solutions Architect @Venafi
Carl Bourne
A Practitioner's Tale: Uniting Dev, Sec, and Ops Tribes
Sr. Principal Solution Architect @Sonatype
Curtis Yanko
CI/CD Pipeline-as-code with Jenkins and Docker
Principal Solution Architect @CloudBees
Kishore Bhatia
Becoming an Outlier
Software Architect @VinSolutions, Author @pluralsight
Cory House
ESPN Next Generation APIs Powering Web, Mobile, TV
Senior Director of Distribution Platforms @ESPN
Manny Pelarinos
The Human Side of Microservices
Tech Lead @Yelp
John Billings

Tracks

Monday, 13 June

Tuesday, 14 June

Wednesday, 15 June

See the Full Schedule

Conference for Professional Software Developers

Follow QCon

Contact

Menu

QCons around the World

Qcon