Infrastructure is one of those things that is extremely vital, yet working on it feels extremely unproductive. For every minute I spend working on an infrastructure issue I lose a minute that I could have spent improving the Hubstaff application. Configuring and maintaining application servers are probably the biggest factor in the infrastructure game and what makes matters even worse is that server problems always happen at the most inopportune times. This fear, is like a buoy bobbing in the back of your mind, that the server will go down and lose power and everything will be ruined (even if only temporarily)!

For large companies the headache isn’t as large. They have big teams to manage and protect their servers, of which there are many in multiple locations. In a start-up you don’t always have the resources to hire a cloud architect to manage things. Which means you are doing it yourself. When something goes down, which it inevitably will, it’s your responsibility to figure it out and get everything working again. When you’re running a start-up, that worry is something you just don’t have time for. (Read about how Hubstaff determines priorities)

Flashback to seven years ago

I was working at ChaCha Search, we would buy HP and Dell servers and install Linux on them, tuning Linux to meet the needs of our specific applications. To store all our equipment we would rent a cabinet in a data center. Luckily (or unluckily depending on how you interpret the rest of the story) this data center was near our offices. A few times a server issue would happen in the middle of the night and my phone would go off. In some rare cases it required that I go to the datacenter because I couldn’t reach the server via SSH for some reason. I’d roll myself out of bed, bundle up in my winter coat (useful both outside and inside of the data center) and brave the weather all the way to the brick and mortar data center, to see what was happening. Usually I had to clear a giant log file or reboot the system and head home in the hopes of catching 30 mins of sleep before my day started again.

I’m not an IT expert, it’s not what I do. So, while I was perfectly capable of buying a Cisco router, configuring it, dotting my I’s and crossing my T’s, I didn’t always know how to optimize it. In fact, ChaCha Search had two servers and we ended up figuring out that the firewall unit we were using didn’t have duplex communication turned on. Meaning we were doing half as much through-put as our firewall was capable of. These are the types of problems you are bound to run into when you are forced to troubleshoot issues that aren’t your day to day focus.

At our server center for ChaCha Search, you could pay a monthly fee to have someone on-site monitor your server. If something happened in the middle of the night, you’d stay sound asleep and someone on staff would restart it and make sure the logs were rotated correctly. As part of the contract to get this piece of mind, you had to sign over root access to your machines. If we needed to get something installed, we had to ask it to be done for us. The thinking was, they didn’t want us messing things up. We weren’t experts and they worried that we would cause unforeseen costs by trying to take care of things ourselves. This chain of command slowed things down a lot. On the one hand it solved the problem of frigid 3:00 am walks to the data center, on the other hand we lost a lot of control.

Fast forward a few years later

Amazon Web Services comes onto the scene and introduces a great new way of doing things. Suddenly the whole server paradigm is virtualized. An organization has complete control, you can download and tweak things exactly how you want them. The control is there, there is no need for the winter coat, but it doesn’t solve the 3:00 am wake up call if your server goes down in the middle of the night.

The issue of platform management posed a huge problem for a lot of companies. To avoid it you either had to have a lot of money, a big team or a lot of time. In reality there aren’t a lot of organizations that fit into those categories.

Server management today

Nowadays I sleep peacefully through the night and my winter coat is reserved for snow days. Heroku has abstracted the whole data server process to a higher level. It’s the ultimate platform as a service (PaaS) company. We are able to run our web application, without worrying about maintaining servers, configuring IP addresses or installing software. It has made the entire process programmatic. Want a Ruby on Rails server spun up? There’s a command for that. Need to restart your application? There’s a command for that.

So what does PaaS mean?

Basically, Heroku has a mesh of virtual servers (using AWS). It handles spinning them up, restarting them and routing HTTP requests to them. If they detect an issue they handle it.

You purchase dynos. Dynos are portions of a server, so instead of having one or two dedicated servers that you manage and operate yourself, Heroku has huge pool of virtual servers and all their customers get a piece. You can adjust how many dynos you want on the fly. All the back-end stuff is taken care of. Heroku works with a bunch of different programming languages. Java, Node.s, Scala, Python and PHP are just a few, so it’s compatible with a wide range of applications.

As a programmer I don’t have to worry about how my software is going to be deployed on it. I don’t have to worry about load balancing or session preservation, how much RAM my system has or if I’m running on the newest version of Linux. Time does not have to be spent stripping down a Linux install and tuning it to be a web app serving ninja. If a problem occurs Heroku has automated systems that kicks into gear so nobody ever notices there was a problem. I don’t have to worry about being a server expert, because everyone at Heroku is. Their network operations team is going to find a problem before I ever could and take care of it. All I have to worry about is pushing my Ruby on Rails code to them and making sure Hubstaff is the best application it can be.

Control with Heroku

Heroku doesn’t support everything. If you have really special needs, like running a voice-over IP system, you are probably going to need to figure something else out.

There are a lot of options for people who need a more in-depth solution. For $35 you can get a virtual private server (VPS) and you can do whatever you want with it. At Heroku, $35 only gets you a portion of that. The difference is that I don’t have to pay anyone to manage my server, which would be a lot more than $35 a month. So, while I may have a server product four times less powerful, I’m still benefiting from economies of scale. In addition, I can spin up free instances on Heroku for things like a staging environment. When you take this into account Heroku starts looking quite inexpensive.

Heroku gives me flexibility and piece of mind. Worries about scaling and managing servers can fall to the wayside with the Heroku team on board. But if I know I’m going to be on the front page of Hacker News I can scale up my dynos in a second to manage the traffic and scale down once the surge passes.

Another feature of Heroku I enjoy is the add-ons. Add-ons, like the billing functionality, allow you to manage everything in one place.

Don’t think Heroku is right for you?

Another player in the cloud computing space is Google App Engine. Google App Engine is similar to Heroku in that it also solves the problem of server instances, it scales underneath you. The number one reason we don’t use it is because it doesn’t support Ruby on Rails. You have to be on board with Google’s version of app development. They have applied their hard-won lessons in scaling and web app design to Google App Engine. This can be great if you’re willing to adopt their methodology, but terrible if you are used to a certain way of doing things already. In terms of programming languages you are pretty much limited to Java, Python and Go. I’m a Ruby on Rails person, which goes perfectly with Heroku.

Microsoft’s answer to cloud computing is Azure. It’s more of a competitor to Amazon Web Services. They have offerings that are managed, but at their core it’s really infrastructure. I don’t feel like enough is abstracted away for me to focus fully on the development side. On the other hand, if you are going to host something that is Windows based it is probably the way to go.

Everyone has a different set of priorities. Everyone has a different threshold for control, which will greatly dictate the cloud platform that is right for you. If you’re like me and you want to spend your time writing awesome code and building stellar applications then Heroku is a great way to go. (See what other tools are helping us grow)