Why all companies should have a Heroku-like platform for their developers

Why should you care?

One of the biggest problems that exists today in technology companies is the velocity to ship experiments is slow. Technology companies often don’t invest in making prototyping easy. The reasons being the need to manage extra infrastructure and costs. If experimental products and applications could be created and deployed rapidly then this will encourage innovation.

Platform

Now I know these are a lot of platforms that allow you to host your applications in secs and this is a solved problem.

Why not just use Heroku?

Certain companies create and manage their own cloud environments on AWS, Google Cloud Platform or their own private cloud. They sometimes don’t like the idea of using services like Heroku directly and buy into the 12 factor application model but instead want to use the idea of something like Heroku to drive development velocity of engineering teams. Also some companies want to do more with their PaaS than what Heroku has to offer.

  • Deis Workflow: PaaS on top of Kubernetes that adds a developer friendly layer to it and uses things like Heroku Buildpacks to build applications and deploy them on Kubernetes.
  • Empire: PaaS on top of AWS ECS that uses the Heroku approach as well.
  • Convox Rack: PaaS built on top of AWS uses things like VPC, S3 and KMS etc to give you a developer friendly api.

Requirements

The requirements for this platform were very simple. They were to enable developers taking part in the hackathon to create apps with just a git push and to be able to create databases for the applications with ease.

Implementation

The implementation includes the following:

Kubernetes in AWS

First, we will start with getting a Kubernetes cluster in AWS. If you are running on GCP, good for you. Then just “push button” deploy a cluster in GKE.

kubectl get nodes
NAME STATUS AGE VERSION
ip-10-0-0-1.ec2.internal Ready 17h v1.6.2
ip-10-0-0-2.ec2.internal Ready,master 17h v1.6.2
ip-10-0-0-3.ec2.internal Ready,master 17h v1.6.2
ip-10-0-0-4.ec2.internal Ready,master 17h v1.6.2
ip-10-0-0-5.ec2.internal Ready 17h v1.6.2

Install Deis Workflow on top of Kubernetes

This is where you will realize that the Kubernetes community/ecosystem is really strong.

  • Install Helm
brew install kubernetes-helm
  • Initialize Helm and Install Tiller
helm init
  • Install Deis Workflow
helm repo add deis https://charts.deis.com/workflow
helm install deis/workflow --namespace deis
  • Make sure you don’t use the default minio storage option for storage. It is a great option for testing workflow but wouldn’t recommend it for making your cluster resilient under outages. We used s3 storage option that can be configured by overriding the values.yml file for the helm chart. Follow the guide to configure object store.
  • We recommend using SSL for both the Workflow API and all managed apps. Follow the guide to enable SSL on Workflow.
kubectl get pods --namespace=deis
NAME READY STATUS RESTARTS AGE
deis-builder-3768201740-clk0p 1/1 Running 0 38d
deis-controller-4279484688-zhxsk 1/1 Running 1 9d
deis-database-4238932065-v0rg0 1/1 Running 1 38d
deis-logger-2533678197-jd05z 1/1 Running 1 38d
...
curl -sSL http://deis.io/deis-cli/install-v2.sh | bash
sudo mv $PWD/deis /usr/local/bin/deis
deis version 
v2.15.0

What changes for the developer?

So far it has been a great ride, we installed Deis Workflow that is running on top of a production grade cluster manager(Kubernetes) on top of a decent cloud provider(AWS). Why did we go through this process? What we want is for our developers to love us. This is what a developer will go through if they start using this platform:

  • The traditional way:
  • The Deis Workflow way:
deis login http://deis.awesome-platform.com
Logged in as developer
Configuration file written to /Users/awesome-user/.deis/client.json
deis create hackathon-ruby-app
Creating Application... done, created hackathon-ruby-app
Git remote deis successfully created for app hackathon-ruby-app.
git push deis master
Counting objects: 239, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (172/172), done.
Writing objects: 100% (239/239), 375.14 KiB | 0 bytes/s, done.
Total 239 (delta 57), reused 239 (delta 57)
remote: Resolving deltas: 100% (57/57), done.
Starting build... but first, coffee!
-----> Restoring cache...
No cache file found. If this is the first deploy, it will be created now.
-----> Ruby app detected
-----> Bootstrapping...
-----> Installing platform packages...
....
Build complete.
Launching App...
deis open

OnDemand Database Creation

We now know that application deployment with Heroku like workflows is fairly simple and fast. But what if the application needed a database? This is where developer hacking on a project usually get stuck. If you can make database deployment as fast as the application deployment then you have won in their eyes. Again, we are talking about prototyping here, we don’t recommend this when it comes to production.

  • Use stateful sets to bring up HA database installations for MySQL and Redis
  • Write a simple API on top of databases that can generate endpoints to access them easily.

Conclusion

With the rise of cluster managers and schedulers like Kubernetes, it has become easy and fast to experiment with ideas. This in turn drives innovation in companies specially the ones that encourage developers or engineers to experiment and fail. So, lets not sit back but enjoy this time that we are living in :)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Anubhav Mishra

Advisor to the CTO & Head of HashiCorp Labs at @HashiCorp. Previous: Engineer @ Hootsuite. Love OSS 💻, and Manchester United ⚽️ !