Rolling Your Own Platform as a Service (PaaS) with Docker
We’ve all been there. We’ve had this lovely, monolithic application purring happily away on some platform-as-a-service. However, the application and team are growing and we need to separate out functionality into independent services to keep moving forward without stepping on one anothers’ toes.
This talk deconstructs the “perceived simplicity” of platform-as-a-services and answers some critical questions:
- What are the essential components of a Platform as a Service?
- When is building our own PaaS worthwhile?
- How and where should we leverage docker in the provision/build/release/deploy/un-provision application life-cycle?
This talk stems from a 6 month engagement building a platform as a service for a micro-service based architecture.
Outline/Structure of the Talk
This is a draft, but here ya go:
- Our Starting Point
- Application deployed to Heroku/App Engine/Elastic Beanstalk
- Easy to move to containers
- Already horizontally scalable
- Most of the “platform” is hidden away, so you don’t know what you don’t have
- Application deployed to custom infrastructure
- May not be horizontally scalable due to architectural decisions
- Probably has all the components of a platform
- What Are a Platform’s Components?
- Builders/Packagers that create a deployable artifact
- Artifact repositories to hold the deployable artifact
- Provisioners that spin-up new services
- Hosts that run a deployable artifact
- Routers/Load balancers to
- Direct traffic from the public to their nearest/most available application servers
- Load-balancers/reverse-proxies/service discovery to
- Route traffic from an application server to composing services
- Slowly ramp-up load as a new version of a service is deployed
- But… But… What about `git push heroku`?! It’s so easy! Here’s what’s really happening (Note, I don’t work for Heroku so this is an approximation)
- You push your git repository to Heroku
- Heroku builds an LXC Image (Similar to a docker image) from your code using a buildpack (Somewhat equivalent to a Dockerfile)
- Heroku pushes the LXC Image to an artifact repository of some kind
- Heroku pulls the LXC image to a server and uses it to start a new container.
- Assuming start-up doesn’t explode, Heroku updates a reverse-proxy to direct external traffic to the newly stood-up container
- Congrats! Your app is running!
- This is so cool! I UNDERSTAND THIS! I WANT TO DO IT!
- OK, well, that’s awesome but:
- Building your own PaaS is *time consuming* and *expensive*. Heroku, Elastic BeanStalk, Google App Engine, etc. all have dozens if not hundreds of employees
- Plus the infrastructure costs of hosting your own artifact repositories, continuous integration server, etc…
- Plus the amount of tooling necessary to abstract away the deployment experience is really high
- So, when should you build your own PaaS?
- When we’re spending enough per month on a PaaS provider that hiring a specialized devops/infrastructure developer is reasonable. (Say, $10~20K/mo)
- When you have external audit requirements that can’t be fulfilled with a PaaS. Even then I’d consider a hosted-hybrid PaaS solution such as https://www.aptible.com or Vektra http://vektra.com
- When you need to run applications across many cloud infrastructure providers (such as AWS, Rackspace, VSphere, and Digital Ocean). Keep in mind for every additional cloud infrastructure provider you’re increasing build/maintenance costs of the PaaS by 125%+
- What about off-the-shelf PaaS?
- CloudFoundry: http://cloudfoundry.org
- Built by Pivotal, Sponsored by EMC. Seems to be gaining huge traction in the enterprise space.
- Fully open-source, so that’s cool.
- Atlas: http://atlas.hashicorp.com
- Built by Hashicorp, creator of tools such as Vagrant, Packer, and Terraform
- Pretty new. Seems squarely targeted at the small/medium sized software business.
- Closed source-ish.
- Dokku/Deis (http://deis.io)
- Dokku is single-host. Useful for someone doing prototyping internally but not something we’d use in production
- Deis is built on top of CoreOS and provides multi-host tenancy and other production-quality options.
- Fully open-source, so that’s cool.
- Where do I use Docker in this situation?
- Docker to Develop
- I have “dev” images that mount the application onto their filesystem.
- I tend to `docker run` it at the beginning of the day and install all the dependencies, start the processes, etc.
- CMD bash -l so we can control when to restart the server processes.
- Docker to Build
- I’m a fan of using Effing Package Manager (FPM) to package an application/its dependencies into a rpm/deb package that can be installed by the servers built-in package manager.
- Docker to Run
- Generally this pulls down the deb/rpm from the builder and installs it onto the image. Docker’s “mostly-single process” model means we will likely need a CMD entry and will want to force the process to run in the foreground.
- Pull the image onto the server we want to run the app in and start it up!
- A clear understanding of the components that make up a PaaS
- How to decide between a commercially-hosted PaaS, a self-hosted PaaS, or a custom PaaS
- How to leverage Docker effectively when developing, releasing, and deploying applications.
developers, infrastructure engineers, technical leads, architects, project managers