These days companies have a lot of choices when it comes to where to host their web applications. Not only are there many different providers to choose from, there are many different types of hosting to choose from. Do you need the raw performance of running on bare metal? Do you need total customization or control of your environment? Or, do you simply need to deploy your application somewhere, and let somebody else manage all of the finer details?
There is no one right answer for everybody. It all depends on the needs of your application. However, at UrbanBound, we’re going to stay on Heroku as long as humanly possible.
There are many benefits to using a Platform as a Service (PaaS) provider such as Heroku or OpenShift. You give up a lot of control over how your environment is configured. However, in many cases, this is a very, very good thing.
I’m a nerd. I have an old-as-dirt dual Pentium III box in my basement, with a whopping 512MB of RAM, running the latest Ubuntu Server LTS release. I also have a VPS (Virtual Private Server) that I use to host a couple of applications that I have built over the years. There is nothing special on either of these machines. No credit card numbers. No proprietary information. However, that does not stop the flood of vulnerability scans and brute force login attempts that hit these machines daily. I know for a fact that, should I lapse on keeping my machines patched, up-to-date, and locked down, it would only be a matter of time before somebody gained access and did who knows what to my data or my websites/webapps.
The nice thing about using a PaaS is that I don’t have to worry about security as much. I still worry about it, but I worry about the things that are in my control… like making sure our application doesn’t have any security vulnerabilities, or isn’t using versions of any libraries or frameworks with known security holes. But, I don’t have to worry about stuff like the recent Ghost or Shellshock vulnerabilities. The great team at Heroku is all over these issues. We have come to rely on Heroku to quickly address new security vulnerabilities at all levels of the tech stack below our application.
I also don’t need to worry about firewall configuration, intrusion detection systems, malware scanning, network configuration, configuration of other services running on the servers, etc. The list goes on and on.
Scaling out is getting easier and easier as time goes on. The days of provisioning a new server from scratch, making sure all of the right versions of the right packages are installed, and manually adding the server to the load balancer are long gone. Even the hosting services that require you to manage the servers yourself provide an easy way to clone an existing server and have the new machine up and handling requests in minutes. And tools like Chef and Puppet are great for keeping you from ending up with a batch of snowflake servers.
But, simply using a slider in a dashboard to tell Heroku how many instances I’d like running, and then poof? Are you kidding? Short of reading my mind (or implementing a fully automated scaling solution with an unlimited budget), I don’t know how much easier it could be.
Granted, this does not come cheap. Heroku can be a very expensive option when you start scaling out. But for the time being, it is stupid-simple to handle occasional spikes in traffic.
One potential reason for wanting to manage your own servers is to have the ability to deploy the services you need to get the job done. When you have access to the machine itself, you are free to run whatever database, queuing system, or cache you wish.
Heroku supports a wide variety of add-ons. The list includes data stores, caching utilities, error reporting tools, logging and monitoring tools, notification services, network services, queuing systems, and more. It is very diverse, and likely includes at least plugin to handle whatever need it is that you have.
The best part is that these add-ons are simple to use. There is nothing to install, and most simply require the running of a single command, and maybe the setting an environment variable or two, before you can begin using them. That’s it.
At UrbanBound, we have a team of people who specialize in building software. Though we all know are way around the command line, and a few of us administer our own personal servers, none of us do it full time. Using a PaaS, we can leave all of the server administration to somebody else...somebody who knows much more about server administration than we do.
The focus on DevOps tooling the past few years has resulted in tools that make it much easier to administer clusters of servers. However, creating and maintaining Chef recipes and Puppet resource files takes a fair amount of work. It also also not easy to keep up to date with the latest versions of all the software you’re running on the server. Nor is it trivial to ensure that all of the software you are running on your server is configured, tuned, and optimized properly.
Leaving the server administration in the hands of the PaaS provider doesn’t only mean that we will end up with a better configured and more secure server. It also means we can focus on what we do best, building our app.
Not everybody can get away with using a PaaS service like Heroku. Some may need tighter control over how things are configured. Some may need to run in a private data center for legal reasons. And for those who need to scale out wide, it can become very expensive. But, if you don’t need the raw performance of running on bare metal, or the ultimate flexibility to configure every last thing in your environment, then I would encourage you to seriously consider a PaaS provider such as Heroku. Focus on what you do best. For us, that’s continuing to make the UrbanBound application great.