This article was originally published on How To Web here.
Infrastructure is often treated as a “feature” of our SaaS startups. We weight how much time it will cost us to improve or strengthen it and we keep forgetting that without it, we wouldn’t have a business. And when disaster strikes (and it will), we don’t have anyone else to rely on, except ourselves … and the cloud services provider that we have chosen at the beginning of our journey.
Disclaimer: This article is written from my perspective as a developer and I do not claim to be an expert in cloud computing services. However, I felt the need to share some of the things that I wish I had known when I started managing our infrastructure, together with my experience working with various cloud services providers.
At the beginning of 2014, I spent an entire month migrating our servers to another cloud. Truth be told, I did a lot of refactoring during that time as well, but I also spent days installing the right software on each machine. We were using 5 servers at the time, each one with a clearly define purpose: API, database, dashboard, etc. I had help from one opts guy that prepared the (blank) virtual machines, but he was not a programmer, and I personally installed most of the packages needed by the different components of our platform.
Now, here comes the best part: after one year, we switched clouds. Again. More time was wasted, but it was inevitable. Over the course of that year, we had 3 major outages on our production servers; the cloud storage was not working properly, sometimes accounting for more than a minute to retrieve a single file; message queues would randomly break, without any apparent reason, and so on.
But the thing that really riled me up was the way we were treated by the “support” team. It was a joke. Every time we wrote to them, we received an answer along the lines of “it’s working on our end”. I actually made a test page that they could access, just to prove to them that their storage engine had major latency issues. It solved nothing.
You might ask yourself how we ended up in that particular situation. It was quite simple: we were lured by the sheer number of credits and the promise of a young, friendly company who would be there for us when we needed to scale. I was in contact with several people from their team, and I liked them all. But, a few months after we signed the contract, when I reached out and sent them a very sincere message telling them about the problems we were facing and how they sucked, nothing changed. My impression was (and still is) that they were actually aware of all those issues, but powerless to resolve them.
Since then, I have made a list of all the things that I wish I had considered before making such an important decision regarding the infrastructure of our startup. I sincerely hope you will find them useful.
Things to look out for …
Pricing – How much will your monthly bill be?
When I say “pricing”, I don’t mean “credits”. Most accelerator programs today have deals with a lot of cloud services providers, so it will be quite easy to get your hands on some credits to get you started. But, the credits will run out eventually. Before you should even consider choosing someone, you should ask yourself questions like:
- How much will my monthly invoice be and can I afford it? If you don’t have any infrastructure set up yet, you can compare the prices of virtual machines, since servers will account for most of your bill.
- Can I use services like cloud storage, CDN or DNS management to optimize costs?
- Is their pricing model flexible (do I pay only for what I use)? Seems obvious, but if you don’t opt in for hourly pricing from the beginning, some cloud providers will charge you a month in advance for virtual machines. And it might not be possible to switch to hourly pricing without starting a new machine and reinstalling the whole thing. It’s stupid, I know. I don’t have a problem with reserved instances, but I really don’t enjoy it when switching from one pricing plan to another translates into hours of work.
Support – Are they actually helping or is it just smoke and mirrors?
I can’t stress enough how important is to have good support: a detailed knowledge base, documented SDKs, and ultimately, the people who can help you when something goes wrong.
Overall, good support will translate in less time spent tweaking things or apologizing to your customers. Excellent support will help you with things that are not particularly their problem – like advising on how to set up an auto-scaling infrastructure or optimizing costs.
Of course, you can’t know from the beginning how support is, but you can find it about it. Talk to people who are using the same cloud provider. If you don’t know anyone, just Google it. If people are unhappy with customer support, they will complain. Loudly and publicly.
Quite often, good support will not come free. But, I’m willing to pay for it if it saves me time, energy and money.
Developer-friendly – Does it make your life easier?
This one is not a deal breaker, but you should consider it as well because it can be a real time saver. I consider a console or dashboard to be “developer-friendly” if it helps me with tasks that would otherwise take me longer. You know, mundane things, like starting up a new machine or increasing memory on an existing one, limiting access to a server by IP address, uploading an SSL certificate, etc.
Like I said, I’m a developer, so tools that allow me to spend most of time developing are worth-while to me. My most valuable resource is my time, so managing the infrastructure in a way that doesn’t keep me blocked for days on a single task is very important.
APIs – Is it well documented and ready to support increased usage?
Good APIs are indispensable. Any infrastructure that needs to scale horizontally will have to use these services because only identical copies of your machines can be replicated. For example, if your database is located on the same machine as your main website, launching a new machine will actually create a duplicate database and you no longer have a single point of truth for your data.
So, all that data that your customers will create, plus static files, will be pushed to external storage and external databases. This is not only efficient in terms of pricing and availability, but it will also allow you to properly set up an auto-scaling infrastructure.
Of course, for all of that to work, services like cloud storage, CDNs (Content Delivery Networks), DNS management, message queues, email services, monitoring, etc. must be available constantly even if your usage increases. I can’t really tell if an API is good or not until I try to actually use it, but again, if there are any problems with it, I’m sure there will be some public complaints.
Also, detailed documentation and SDKs for multiple programming languages can be an indication that people over there are taking their jobs seriously.
Turning a corner
We were fortunate enough to get out of the clutches of a bad cloud services provider before more damage could be done, a little bit bruised, but still kicking. Our platform has grown since then, and I don’t want to think about what could have happened if we didn’t make the switch. I’m positively sure now those outages would have cost us dearly.
In case you are wondering, we are now using Amazon Web Services and we’re quite happy with them. Word gets around that Digital Ocean is also good (and cheaper), although I haven’t personally given it a try. In any case, before you hop on and sign any contracts, it will not hurt to do some research, and I bet you will be much happier in the end.