Going whole hog on PaaS? (with presenter notes)

The last few years have seen the rise of Platform as a Service (PaaS) as part of the computing landscape, through the success and growth of numerous public and private offerings, both commercial and open source.

The promise of a unified platform that abstracts away language/application runtimes, data services, and systems management into a single platform that has automation, logging, metrics, auto-scaling, and self-service all baked in, is extremely appealing and implementing some kind of PaaS strategy is often a topic when discuss how to "do DevOps", as the ideas that PaaS encompasses include many core DevOps principles and the idea of a turn-key solution is hard to resist.
Unfortunately, in many ways the landscape is still young and the solutions available take many different approaches, from hosted offerings like Heroku, DotCloud, or Nodejitsu, to large scale, one-size fits all in-house offerings like CloudFoundry, OpenShift, or Stackato, to newer and more targeted (often Docker based) offerings, such as Deis, Dokku, or Flynn. So it's difficult to know where to begin and what's truly turn-key, and how far these solutions will get you in a reasonable amount of time and effort.
Drawing on my years of experience in the web hosting industry and my experience over the last two years in implementing a production in-house PaaS offering at Mozilla, I will attempt to:
* Provide a concise overview of the PaaS landscape

* Lend some insight into what PaaS might be good for you, based on some attributes of your organization, culture, technology stack, and technical debt

* Share some lessons learned in implementing a production PaaS at Mozilla, including cultural challenges, shifts in thinking required to adopting a PaaS ( the http://12factor.net/ mindset), and technical challenges, such as managed shared secrets, removing reliance on shared filesystems (NFS), etc

* Provide guidance on why you may not want to adopt any PaaS solution, but instead determine how to apply your existing infrastructure automation (Configuration Management, IaaS, CI pipeline, etc) with some custom automation, APIs, self-service tools, to achieve the promise of PaaS and apply "PaaS patterns" to your existing tools and workflows.

In the end, you'll leave this talk with more insight into what PaaS means, how you can apply the patterns it embodies to improve your automation, your workflows, and ultimately your culture, and you'll know if you should go whole hog on PaaS or not.

Transcript

1. going whole hog on paas? 1 Monday, April 28, 14
2. who am I? brandon burton @solarce (on all the things) webops, devops, gifs 2 Monday, April 28, 14
3. why should you listen to me? been doing web operations for eight years saas web hosting mozilla 3 Monday, April 28, 14
4. why should you listen to me? early adopter of PaaS heroku (when it was just rubby) dotCloud (best free tier early on) now Docker, Inc AppFog (PHP) 4 Monday, April 28, 14
5. why should you listen to me? been building a PaaS at Mozilla for over two years Feb 2012, experimented CloudFoundry (just clone git master) OpenShift (nightly build rpms) Sept 2012, built on ActiveState’s Stackato product (turnkey) 5 Monday, April 28, 14 * turnkey was critical as webops didn’t have the headcount to dedicate to operating
6. let’s set some vocabulary PaaS: Platform as a Service Cloud: Hosted Compute, Network, Storage, API driven, Elastic, On-Demand 6 Monday, April 28, 14
7. let’s set some vocabulary Runtime: a language runtime, e.g. Python, Java/Clojure/Scala (JVM), Ruby, PHP Framework: for building apps in a language, e.g. Django, Node.JS, Rails Data Service: external data store like databases, message queues, in-memory cache, full text indexing 7 Monday, April 28, 14 * where a runtime begins and a framework ends can be fuzzy, depending on the language and runtime container * jvm stuff, node.js * data services * database: mysql, postgresql * message queues: rabbitmq, activemq * in-memory cache: memcache, redis * full text indexing: elasticsearch
8. kinds of paas General Purpose Language Specific 8 Monday, April 28, 14
9. kinds of paas General Purpose Hosted Heroku OpenShift AppFog HP Cloud aPaaS (Stackato based) 9 Monday, April 28, 14
10. kinds of paas General Purpose In-House CloudFoundry OpenShift Stackato Flynn, Deis, Dokku 10 Monday, April 28, 14 * newer entries like flynn, deis, dokku, are trending towards general purpose, but with varying levels of language and data services support right now
11. kinds of paas Language Specific Nodejitsu (node.js) Acquia (PHP) CloudBees (Java) Gondor (Python) Railscloud (Ruby) 11 Monday, April 28, 14 * these are just a few examples, there are many smaller paas type hosting offerings that focus on one or a couple languages/runtimes/frameworks
12. patterns of paas 12 Monday, April 28, 14 * ok, we’ve set the stage and reviewed the landscape * let’s get into the meat of things, what are the patterns we can learn from the paas world
13. patterns of paas self-service 13 Monday, April 28, 14
14. patterns of paas cli 14 Monday, April 28, 14
15. patterns of paas api 15 Monday, April 28, 14
16. patterns of paas data services 16 Monday, April 28, 14 * mature platforms have a few advanced features
17. patterns of paas logging / metrics 17 Monday, April 28, 14 * heroku has a really nice story around log streams and metrics * stackato provides some services via it’s own logyard project and New Relic integration * this is an area that more PaaS need lots of work, as it can be a game changer
18. patterns of paas montitoring/alerting 18 Monday, April 28, 14 * this is something I haven’t seen much of, but imagine self-service monitoring/alerting * something pagerduty like * hashtag devcarryingpagers
19. whole hog? probably not 19 Monday, April 28, 14 * how much time do you have to learn a new distributed system (a complex one), while maintaining your existing infrastructure (all that stuff this paas would replace/help make better!) ?? * how many runtimes/frameworks do you need to support? * how many data services do you need to support?
20. whole hog? what are you already doing well? 20 Monday, April 28, 14 * you’ve already got a good provisioning story? or you’ve outsourced it to aws! * got your chef/ansible/puppet/salt story dialed in? * got some logstash and graphite up in your stuff? * got jenkins doing builds? * got some nice tools to let devs push via web interface?
21. whole hog? learn from patterns! 21 Monday, April 28, 14 * what isn’t self-service today? * pushes? (to prod?) * adding metrics? * adding new logging? * adding monitoring/alerting? * could you build some additional APIs around your existing cool to improve self-service? * could you build some CLI tools around existing APIs?
22. whole hog? what can you buy/saas? 22 Monday, April 28, 14 * could you buy something turnkey to satisfy an automation need? * could you hire someone to help you build tools? * there are lots of great saas offerings for * CI * metrics / logging / monitoring / alerting
23. conclusions many excellent PaaS offerings for a variety of needs adopting a general purpose PaaS is a large undertaking you may only need to build/buy a few tools to be “PaaS-like” 23 Monday, April 28, 14
24. what next? follow @solarce on Twitter participate in hangops share your own experience at a future LA DevOps round table session 24 Monday, April 28, 14