With the introduction of AWS OpsWorks, you can now build and manage your application stacks with the finesse and control of Chef recipes. OpsWorks compliments the AWS management frameworks and in this session we'll dive deep on how to use OpsWorks and how to get the best from the framework.
Thomas Metschke, Technical Program Manager, AWS
Rik Heywood, Technical Director, Workfu
2. Once upon a time…
Making Donuts
1. Make dough
2. Roll and cut the dough
3. Separate donuts from holes
4. Let the dough rise
5. Prepare the glaze
6. Frying time!
7. Let them dry
8. Apply glaze
9. Add sprinkles (optional)
5. Introducing AWS OpsWorks
• Integrated application management solution for ops-
minded developers and IT admins
• Model, control and automate applications of nearly any
scale and complexity
• AWS Management Console, SDKs, or CLI
• No additional cost
6. Why Use AWS OpsWorks?
SIMPLE
Easy to use,
quick to get
started and
productive
PRODUCTIVE
Reduces
errors with
conventions
and scripted
configuration
FLEXIBLE
Simplifies
deployments
of any
scale and
complexity
POWERFUL
Reduces cost
and time with
automation
SECURE
Enables
control with
fine grained
permissions
7. Improve productivity
• Scalable infrastructure
• Flexible architecture
• Deploy often
• Staging environments
AWS OpsWorks gives us the tools we need
to automate operations.
We can scale Monster World, one of the
largest Facebook games, to millions of users
without ever needing more than two
backend developers.
Jesper Richter-Reichhelm
head of engineering
9. Basic Layers
• HAProxy
– Minor config changes as our site uses https for everything
• PHP App Server
– Customized Apache config and PHP.ini using template overrides
• MySQL
– We also install scripts to backup the database via custom recipes.
10. Additional layers that share App instances
• Memcached Layer
– Allows us to deploy memcached onto any instance
– We auto install it on all PHP instances to use spare memory
• Queue Worker Layer
– Processes messages in our background task queue.
– Again, we install one worker worker on all PHP instances.
– Helps to scale queue throughput as traffic increases
– We can still deploy dedicated queue worker instances if we need to
11. Layers sharing database instance
• RabbitMQ Layer
– We queue up a lot of background tasks, such as querying the Twitter API, rebuilding
the search database, sending out notifications to users etc.
• Sphinx Layer
– A full text search engine.
• Both services place very little load on the instance.
– If load on either of these, or MySQL, gets too high, we can easily migrate them to
dedicated instances.
12. Other features we depend on…
• Simple one click deployment
– Could be automated on push via API, but we prefer manual control of this.
• A realistic staging / testing environment
– Cloned our stack to create an identical duplicate of it
– Same cluster and config on Production and Staging
– We can leave Staging switched off most of the time, saving cash.
• No long complicated out of date documents explaining how to set up server
instances - it's all automated and in our git repository.
13. AWS Application Management Services
Elastic Beanstalk OpsWorks CloudFormation EC2
Convenience Control
Higher-level Services Do it yourself
14. The heart of AWS OpsWorks
Agent on each
EC2 instance
OpsWorkstalks with
15. The heart of AWS OpsWorks
understands a set of commands that are
triggered by OpsWorks.
The agent then runs a Chef solo run.
Agent on each
EC2 instance
19. What’s next for AWS OpsWorks?
• Deeper integration with AWS resources (e.g., ELB)
• More built-in layers
• Advanced VPC integration (beyond today’s support for the
default VPC)
• And more!
• Please give us your feedback in the OpsWorks forums.
20. Thank You!
For more information, please visit us at
https://aws.amazon.com/opsworks
Thomas Metschke
@tmetschke