Using a New Hosting Company?

Discussions
#1

I’ve been doing a lot of research into what hosting company I should use for my application, and the one I’m most attracted to is a bit of a newbie.

The app is based on the Meteor framework (which sits on top of Node), so I was looking for a Node-specific host and came across Modulus. Their offering is inline with something like a Heroku, where deploys are super easy and things like load balancing are taken care of for you.

For a guy like me who is 100% new to running an app (and doing it solo for now), an offering like Modulus is really interesting.

My issue (if we can call it that), is that they’re a newer company. I did hop onto their support chat for a few minutes not too long ago and the guy who helped me out was great. They seem serious about building a solid hosting service, and I’m looking at it as a great opportunity to grow my business alongside their own.

Does anyone have experience working with a provider that’s new? Any tips/notes you can offer up?

#2

I’ve always over-engineered my systems but I’m coming to learn that you need to find the right balance of reliability and simplicity to just get something up and find out if a highly reliable/robust platform is required. Premature scaling and sweating the hosting details has probably killed the cash flow of countless bootstrapped software businesses (not the host they chose being down for a few hours a year).

However, if you are choosing a newish host though, I wouldn’t pick one that requires you to do something “magic” and therefore become locked in to hours of refactoring if they turn out to be a dud.

#3

@imsickofmaps great thoughts, thank you. I’d rather not blow money on early paranoia :slight_smile:

There’s a tiny bit of “magic” in that you have to convert your app to a raw Node app (using a tool they built specifically for Meteor apps), but nothing so extreme that would warrant a rewrite/refactor.

#4

I really like Digital Ocean or Linode even though they are VPS providers. I like this because when you go to add other services, you don’t have to scratch your head and jump to another provider later.

Being picky, I like the ability to roll my own stack sort of like what @imsickofmaps is saying. Coming from my first OS apps being run off of Pagoda Box (a PHP PaaS) I had a terrible time fighting what versions were supported vs my dev environment.

As far as the pricing goes, DO is going to be far cheaper than even the lowest tier of PaaS systems or darn close. Linode will run you about $10-15 per instance. Both will give you a lot more power and space. The only cost is installing your stack which I assume you probably know from your dev environment.

#5

@rtablada I’d considered DO, too, as it came up in a book about the framework I’m working with. My only concern is that I won’t have the chops to manage a 100% custom build out of the gate. My goal is to get it stable on my own and as the product grows, invite someone who does just sysadmin to come in and setup the best solution.

Is that a smart strategy? Based on @imsickofmaps comment above, it seems really easy to think you need something that you really don’t early on.

#6

I have used “newbie” hosts before and have had both positive and negative experiences with it. On one hand it’s fun to be the customer of someone that’s hungry and still excited about what they do. On the other, it can be frustrating to be part of what amounts to an experiment - which is essentially what any new business is.

Two questions to ask yourself when considering a host that is new.

  1. Will I be able to handle their growing pains? Assuming they impress
    others as much as they’ve impressed you they are bound to grow and with that
    comes growing pains. Now growing pains for a hosting company can
    mean anything from horrible support (where it was once great) to
    extended service outages or lost data. Not a big deal really - if you are
    prepared to weather it with them or if you have a backup plan for when you decide to bail.

  2. Will they be able to handle my growing pains? You mentioned you are
    new to running an app so it’s fair to assume you will have your own
    issues sooner or later - most of which won’t be related to hosting -
    but for those that are you need to know if they will be able to
    support you through them. (Supported technologies, plan upgrade paths, policies on traffic spikes, etc.)

Tips:

  • Do not rely on their backups. (if that’s a service they provide)
    Always, always, always have your own stored elsewhere.

  • Be overly complimentary of their support staff any time they deserve
    it. As a new company they will be hypersensitive to customer feedback
    and will certainly go the extra mile for people who don’t treat them
    like crap.

  • Decide what support hours are acceptable to you. I used to choose
    Australian hosts because they were open when I was working whereas the
    ones here in The United States were closed. A non-issue now but
    something I remember being a big deal to me before I learned to
    handle most of my own server issues.

3 Likes
#7

@NicheDiver thank you for the response, gave me a lot to think about. Some follow up questions for you…

  1. Re: backups, how often? I’ve seen everything from hourly to daily recommended. What’s the “standard,” safest, and most economical?

  2. Is there anything outside of experience that will really tip me off to their long-term performance? I did some research for reviews, but there isn’t anything comprehensive.

  3. The big hook for me is that they offer everything I’ll need in one spot (and it actually works on the first try). As a first timer, this obviously cools my nerves because it means not having to manage and monitor a handful of services. On the flip side, though, it could also mean an outage on their end is 1 to 1 on my own. Is it safe to do everything in one spot? Any reasons to avoid this?

Thanks for your advice :slight_smile:

#8

  1. Your backup schedule should depend on how painful it would be if you lost everything since the last backup. If you can recover from losing a week’s worth of data without breaking a sweat then weekly backups are fine. If, on the other hand, losing more than an hours worth of data would be a nightmare then you should go hourly. As far as what is “standard”/safest/most economical - I cannot say. I’ve fallen into a routine of backing up to a local “grab-n-go” device and haven’t looked into the latest services for such things.

  2. Even without reviews from past users you can usually still sniff out problems by digging around. Fortunately for you this company seems to be very social online so I would recommend stalking them a bit. For example, go to twitter and search not just their feed but all of twitter for tweets both to and about them. Do separate searches using their twitter name as, their URL, founder names or anything else you think would lead you to tweets involving this company. Repeat on other platforms where they engage with users. Also try obscure search terms in Google that you think unhappy customers might use when complaining. (e.g., Modulus refund, Modulus “not happy”, etc.) Finally, when all else fails to give you 100% assurance (no such thing), make the leap knowing you did what you could to be informed and if it goes poorly you’ll know you did the best you could with what you knew at the time.

  3. I only gave a cursory glance at their homepage so I’m not sure what services they are combining but look at it this way. Hosting is at the core of what they do. If there is an outage on their end, all other services tied to that core are rendered useless no mater who is providing them. If it makes you feel warm and fuzzy, less confused and well taken care of to have them all in one place then there is value in that.

Good luck!

#9

I understand the idea of something you wont need until later. But PaaS and IaaS make their business through locking you into their datastores. Many of them have no way to export out your SQL or Mongo, or whatever is hip to use with node these days. Then you are stuck using their slower datastores which are only accessible if you also run your web instances with them too. So it’s not so much “will I need to run Varnish or Memcache or Redis or ___ later,” it is a question of “will I ever outgrow this pricing model?”

#11