In this talk, the engineering team behind the Intuit PaaS takes you through the design of our shared PaaS and its integration with AWS OpsWorks. We give an overview of why we decided to build our own PaaS, why we chose OpsWorks as the engine, technical details of the implementation as well as all the challenges in building a shared runtime environment for different applications. Anyone interested in OpsWorks or building a PaaS should attend for key lessons from our journey.

1. DMG305 - How Intuit Leveraged AWS
OpsWorks as the Engine of Our PaaS
Capen Brinkley and Rick Mendes, Intuit
November 14, 2013
© 2013 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

2. Agenda
• How we got into AWS, and why we’ve decided
to do a PaaS
• Why we chose AWS OpsWorks as our engine
• How we use AWS OpsWorks to build our PaaS
• Q&A

3. Intuit’s Journey to AWS

4. Why PaaS?

5. EC2
CloudFormation
S3
Auto Scaling
Chef
Simple Deploy
Heirloom

6. Application A
Application B

7. Why AWS OpsWorks?
• Skillset and operational expertise:
• Chef
• AWS services
• Similar operational model
• More controls, compliance, and security than
Elastic Beanstalk could offer

8. Architecture

9. Layered

10. Layers
Intuit Abstraction Layer
AWS OpsWorks
EC2
IAM
S3
ELB
SQS

11. Abstraction Layer Benefits

12. Nomenclature
Intuit
AWS OpsWorks
App
Stack
Stack
Layer
Instance
Instance
Build
App
Deployment
Deployment

13. Simplicity
Abstraction Layer
• Create app API
• 3 parameters
• All parameters simple
strings
• Users only need to
provide name, app type
and region
AWS OpsWorks
• Create stack API
• 16 parameters
• Parameters mix of simple
strings and elements
• Users need AWS
knowledge to set
parameters

14. Simplicity – Create Inputs
Abstraction Layer
{
"name": "My App",
"app_type": "rails",
"region": "us-west-2"
}
AWS OpsWorks
{
"Attributes": {
"string" : "string"
},
"ConfigurationManager": {
"Name": "string",
"Version": "string"
},
"CustomCookbooksSource": {
"Password": "string",
"Revision": "string",
"SshKey": "string",
"Type": "string",
"Url": "string",
"Username": "string"
},
"CustomJson": "string",
"DefaultAvailabilityZone": "string",
"DefaultInstanceProfileArn": "string",
"DefaultOs": "string",
"DefaultRootDeviceType": "string",
"DefaultSshKeyName": "string",
"DefaultSubnetId": "string",
"HostnameTheme": "string",
"Name": "string",
"Region": "string",
"ServiceRoleArn": "string",
"UseCustomCookbooks": "boolean",
"VpcId": "string"
}

15. Flexibility – Multiple Clients

16. Behind the Curtain

17. Continuous Integration
Intuit Abstraction Layer
Intuit Package Manager

18. App Configuration Variables
User, System Vars
User Vars
Intuit Abstraction Layer
Custom JSON
App Instances

19. Managing Instance Statuses
Start/Stop
Status Request
Intuit Abstraction Layer
Info Manager
Transition

20. Collaborators
App
1
Dev Group A
(4 users)
Dev Group B
(6 users)
QA Group A
(2 users)
App
2

21. Technologies
•
•
•
•
•
RESTful APIs
Ruby on Rails
AWS SDK Gem
RDS MySQL
Opscode Chef

22. Challenges
• Think differently about Chef code
– Things like roles and data bags are not supported yet
• Polling for instance statuses
– There are no asynchronous APIs or notifications at this time
• Multi-step deletion of apps
– Instances cannot be deleted automatically

23. Looking Ahead
• Java Support
– Should we replace our custom support with AWS OpsWorks
support
• Application Visibility
– Access to application logs and application runtimes
• Additional Languages/Frameworks
– Expand beyond Ruby and Java

25. Q&A

26. Please give us your feedback on this
presentation
DMG305
As a thank you, we will select prize
winners daily for completed surveys!