Production-grade SaaS infrastructure for $200/month

Interesting Links
#1

Here’s an article I stumbled upon that describes an infrastructure stack for a new SaaS product:

https://medium.freecodecamp.com/how-your-startup-can-leverage-production-grade-infrastructure-for-less-than-200-month-15c3724038b4#.jlhxhbb65

Before you can launch a new service, you need infrastructure. You want reliability, scalability, and many other -ilities. But you don’t want to break the bank.

I’ve gone through the process of launching several new services over the past few years. Each time, I’ve explored the field of options.

The goal of this article is to help you focus on the value that your solution provides to your users, while minimizing the time and money spent geeking out on infrastructure.

The choices are pretty good, I think.

2 Likes
#2

Good stuff. It looks pretty close to my setup:

  • Back-end: Heroku (Rails)
  • Front-end: Netlify/GitHub Pages
  • Database: Heroku Postgres
  • Background jobs: Heroku Redis + Sidekiq
  • Transactional email: SendGrid (heard mixed opinions, but been great for every project I’ve used them for)
  • Logging: Papertrail
  • Monitoring: Raygun (over Sentry, since they actually don’t have a free tier on Heroku’s add-on marketplace)
  • Uptime: Apex Ping (over Uptimerobot, as Ping also gives you a status page)
  • SSL: Lets Encrypt

Edit: Librato looks awesome, but not sure I see the benefit if you’re on Heroku.

#3

Lets see…

  • Back-end and Front-end: Chicago VPS ($20/month) or AWS (a lot)
  • Database: Postgres (free) or Postgres on RDS ($150+/month)
  • K/V storage: Redis (free) or AWS Elasticache ($100+/month)
  • Background jobs: java apps deployed as background services (free)
  • Transnational email: Office365 ($5/user ~ $30/month total)
  • Log collection: Home grown based on elk stack (free)
  • Monitoring: Home grown based on elk stack + home grown service registry (free)
  • Uptime: Uptimerobot (free)
  • SSL: Lets Encrypt (free)
    …
    from $50/month to sky’s the limit
#4

Good list.

Having said that, for a bootstrapped system this is not cheap, and most of advanced properties (load-balancing, hot-standby, etc) are probably not required during the first year.

It is enough just to have the ability to upgrade in the architecture - when (and if) the time comes.

1 Like
#5

Pud’s 2011 distrokid setup: http://pud.com/post/9582597828/why-must-you-laugh-at-my-back-end

#6

Way to complicated… my head hurts… lol

#7

There are costs associated with operating those home grown solutions, as well as operating your own postgres database, that make them non-free. It’s too easy to think that operations is free and that the only cost is the server (virtual or otherwise) and the software cost, especially when you’re operating something that is not critical to keeping your business operating. This is a dangerous mindset and I for one would prefer we start considering the real costs of operating our systems.

And I say this as someone who has operated my own infrastructure many times: it always turns out to be more expensive than I estimated coming in because of people costs and other operating expenses.

3 Likes
#8

CFML…wow, I didn’t know that was still around.

I like the approach espoused in that post, though. It follows the principle of “use the dev stack you know well, even if not trendy.” Which is why my new SaaS product is using boring old Java on the web server.

#9

Hmmm… I use Digital Ocean for $20 a month.
So far no capacity issues. I think I can just spin that droplet up with more capacity if needed.

I guess our programmer may have spent more time on setup using plain vanilla LAMP. Not sure.

I think its seductively easy to scale prematurely, thinking " if I build capacity for success, that’s one less obstacle to success". But capacity was never going to be your biggest problem. You can BUY capacity if you are successful. But success (customers, $) needs to be earned.

-Clay

3 Likes
#10

As far as I understood, linked article was not about scaling, i.e. handling hundreds of customers at once. That would be premature optimization. Instead, it’s about reliability, to get as much uptime and uninterrupted service as possible by using redundant services. It might apply even if you only have handful of customers.

My products are not Saas, and can live if marketing site is down for few hours per year. I even ok with (good) shared hosting. Also, it depends on nature of Saas application, how mission critical it is for customers.

1 Like
#11

Good point.
I’d argue that spending $2K/year is also premature if you don’t have any paying customers.

Do you know that very high uptime is your biggest constraint?
(i.e., is $200/m a better expenditure than, say, Adwords)?
Then, yes, this makes good sense.
I know i’ve spent way too much time solving problems I THINK my customers have and missing ones they I should be working on.

Now, if you do know that high uptime is critical so success (or at least important to paying (or revenue generating) customers, then, yes, this seems to make sense.

1 Like
#12

Automation helps a lot: provisioning, deployment, backup, disaster recovery, monitoring.

#13

I totally agree, as long as the configuration, ongoing verification, and maintenance of the automation is factored in. Simple things like responding to CVEs and upgrading systems in a timely fashion can quickly suck up hundreds of hours in a year.

1 Like
#14

In the early days of a SaaS the time of the founder is essentially free.

Even if this time is released to be spend on, say, marketing - it is not clear that it will ever be more profitable this way, because the founder may not be efficient in the marketing yet. (And because the SaaS may never be profitable at all, of course).

And $2400/yr are very real money.

1 Like
#15

I agree, $2,400 is real money. But almost everything in the article has lower tiers than what’s used in the article, so I’m using essentially the same thing and I’m paying about $40/mo for all of it. With Heroku, scaling the tools is painless if it’s ever needed. Really the only things I’m paying for are a standard dyno and Postgres database, everything else is on free tiers until the need arises.

#16

For me the key was to learn how to automative your hosting infra, and to make deployment to both staging and production as easy as possible. Once that is in place, you can confidently start building out your product. If you go with DO or AWS or Azure is besides the point for many types of SaaS apps.

Now depending on your budget, type of app, and how serious you are, you can pay $20 to $250/month :slight_smile:

#17

I checked Heroku free tier, it is a toy of a server (512M). I’m from Java world, and that thing could barely launch HelloWorld.java. :smiley:

However, a some $20 VPS (2G-4G) should be able to host a single app server + single DB good - which is enough until The Growth happens, and only at that point it is time to add another VPS to have a cluster of apps servers and migrate DB to a replicated setup. Hopefully there are already paying customers who will cover the costs.

That is, of course, if we’re bootstrapping. If on the other hand, we’re “serious” about it, then why not, let’s throw some money at it, because we must be in a real business if we spend the money like that, right? :wink:

#18

It’s a little bit of putting the cart before the horse. If you make some smart decisions when first building your service you should be able to reasonably scale it as you grow. I have read more than a few examples of startups that planned for huge growth, spent a lot of time and money solving scale problems they expected to have only to never experience those problems and running out of money.

The first version of the service I developed was absolute bare bones. Everything was stored in a single database included sessions and job queues. As demand grew it was easy to move sessions out to their own storage and eventually job queue and email processing also. To start it was running on a dirt cheap vps, then over to digital ocean with dedicated resources. As need grew I have increased spend to keep up. Thankfully I leverage a framework that made it easy to grow on demand with plugging in better options as needed.

Always plan ahead but don’t waste valuable resources executing those plans until you need to.

3 Likes
#19

From what I’ve seen Heroku is very popular with the Rails crowd. Does anyone outside that community use it (in a serious way, not one guy hosting a Django app on it)?

From what I’ve heard, they charge for every extra, and the costs really add up.

#20

I was using it for a short time during development in a hybrid rails + playframework (scala) app. I ended up going with ec2 because I wanted more control and also didn’t want to depend on 3rd parties for core infra like memcached.