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.
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
7. Why AWS OpsWorks?
• Skillset and operational expertise:
• Chef
• AWS services
• Similar operational model
• More controls, compliance, and security than
Elastic Beanstalk could offer
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
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