5 ms·

I've been thinking a lot about this recently. I'm in between jobs and thinking of starting a SAAS on the side in order to support my goal to go backpacking for

by sarreph 10y ago

I've been thinking a lot about this recently. I'm in between jobs and thinking of starting a SAAS on the side in order to support my goal to go backpacking for a few months next year. However, the amount of microservices I'm thinking of putting it all together with means it'll require a decent amount of non-automatable (as far as I can tell) maintenance and attention. This isn't exactly what I want at the back of my mind all the time while travelling... but then again, you can't have all your cake and eat it. Anyone who has a successful hands-off SAAS built on a modern stack care to chip in on ways of mitigating this?

dtien 10y ago
How about don't go with a microservice arch. Nothing wrong with tried and true monolith Django, Rails, or [your favorite stack]. In fact, sounds like this is your first time out, in which case I would absolutely recommend minimizing the headache and complexity and go with a simple monolithic stack. [insert rant about premature optimization] In any case, build your SaaS, go backpacking. Both invaluable experiences.
bensummers 10y ago
Write it as a monolith. If you get to a stage where it needs a bigger server than you can afford, run a profiler on it, and fix up any glaring performance problems. Then if it gets wildly successful and does actually need microservices, then you have the resources to pay for the development & sysadmin overhead. Also by delaying as long as possible, you'd have the maximum information and maximise your chances of getting the split right.
jasonkester 10y ago
Expanding on the "both/and" advice from elsewhere in this thread, I'd recommend saving for the backpacking trip first with a boring-yet-lucrative consulting gig, then building the SaaS product during your downtime on the road. It'll fix your expectations and your finances all in one go. SaaS businesses take at least a year or so to ramp up to the point where they can reliably support you (even on the beach in Cambodia). It'd be a shame to have to cut your trip short because the thing you'd built wasn't immediately successful. With luck, it'll be the thing that finances your second lap around the world three years from now. [edit] And yeah, don't build microservices. Especially for a B2B SaaS. Scaling problems for products with a price tag are things that come with tons of money attached. Use that to scale when and if it becomes a "problem". For now, build a boring Rails app on PostgreSQL or whatever has the least chance of falling over while you're halfway down the Inca Trail.
MikeKusold 10y ago
Organize your microservices as packages, then run it as a monolith. Host it on Heroku. Now you have no ops, and no automation needed. Once your business grows to the point where you need to scale, you can easily split apart your monolith and you can host it on AWS (Heroku makes it easy to migrate your database to AWS).
UK-AL 10y ago
Write it as a monolith, but easily converted to microservices. I find you need a monolith phase anyhow to find out your real microservice boundaries before guessing.
brightball 10y ago
Elixir is a solid solution for this. You essentially write micro services as a monolith that runs on the BEAM VM and naturally spreads across a cluster (https://elixirschool.com/lessons/advanced/umbrella-projects/ https://elixirschool.com/lessons/advanced/umbrella-projects/). It's all message passing without shared memory so whether you're sending something to a different function, process, processor or machine in a different datacenter your code doesn't really care. As a bonus you don't have to define REST/SOAP/Protocol Buffer interfaces for every single microservice you're writing...since it's just function calls. Everything works smoothly and efficiently just like boring Erlang has for decades, with some readability and productivity perks that Elixir gives you. Elixir sounds trendy and new, but it's just modernized Erlang. It's older than Linux.
- amorphid 10y ago
  I <3 actors & immutability. I didn't understand what "easy to reason about" meant until learning Elixir.
  - cutler 10y ago
    Yes, I loved Elixir as soon as I set eyes on it. However, as far as "easy to reason about" goes, Clojure in an Emacs CIDER repl is about as good as it gets.
arikfr 10y ago
There aren't many SaaS services I can think of that can be truly hands-off to the extent that you can backpack with a free mind. Also scaling a SaaS business takes time and significant effort. All of the above is from personal experience. If I were looking for passive income from software I would've looked at desktop software.

by sarreph 10y ago

dtien 10y ago

How about don't go with a microservice arch. Nothing wrong with tried and true monolith Django, Rails, or [your favorite stack]. In fact, sounds like this is your first time out, in which case I would absolutely recommend minimizing the headache and complexity and go with a simple monolithic stack. [insert rant about premature optimization] In any case, build your SaaS, go backpacking. Both invaluable experiences.

bensummers 10y ago

Write it as a monolith. If you get to a stage where it needs a bigger server than you can afford, run a profiler on it, and fix up any glaring performance problems. Then if it gets wildly successful and does actually need microservices, then you have the resources to pay for the development & sysadmin overhead. Also by delaying as long as possible, you'd have the maximum information and maximise your chances of getting the split right.

jasonkester 10y ago

Expanding on the "both/and" advice from elsewhere in this thread, I'd recommend saving for the backpacking trip first with a boring-yet-lucrative consulting gig, then building the SaaS product during your downtime on the road. It'll fix your expectations and your finances all in one go. SaaS businesses take at least a year or so to ramp up to the point where they can reliably support you (even on the beach in Cambodia). It'd be a shame to have to cut your trip short because the thing you'd built wasn't immediately successful. With luck, it'll be the thing that finances your second lap around the world three years from now. [edit] And yeah, don't build microservices. Especially for a B2B SaaS. Scaling problems for products with a price tag are things that come with tons of money attached. Use that to scale when and if it becomes a "problem". For now, build a boring Rails app on PostgreSQL or whatever has the least chance of falling over while you're halfway down the Inca Trail.

MikeKusold 10y ago

Organize your microservices as packages, then run it as a monolith. Host it on Heroku. Now you have no ops, and no automation needed. Once your business grows to the point where you need to scale, you can easily split apart your monolith and you can host it on AWS (Heroku makes it easy to migrate your database to AWS).

UK-AL 10y ago

Write it as a monolith, but easily converted to microservices. I find you need a monolith phase anyhow to find out your real microservice boundaries before guessing.

brightball 10y ago

Elixir is a solid solution for this. You essentially write micro services as a monolith that runs on the BEAM VM and naturally spreads across a cluster (https://elixirschool.com/lessons/advanced/umbrella-projects/ https://elixirschool.com/lessons/advanced/umbrella-projects/). It's all message passing without shared memory so whether you're sending something to a different function, process, processor or machine in a different datacenter your code doesn't really care. As a bonus you don't have to define REST/SOAP/Protocol Buffer interfaces for every single microservice you're writing...since it's just function calls. Everything works smoothly and efficiently just like boring Erlang has for decades, with some readability and productivity perks that Elixir gives you. Elixir sounds trendy and new, but it's just modernized Erlang. It's older than Linux.

amorphid 10y ago
I <3 actors & immutability. I didn't understand what "easy to reason about" meant until learning Elixir.
- cutler 10y ago
  Yes, I loved Elixir as soon as I set eyes on it. However, as far as "easy to reason about" goes, Clojure in an Emacs CIDER repl is about as good as it gets.

arikfr 10y ago

There aren't many SaaS services I can think of that can be truly hands-off to the extent that you can backpack with a free mind. Also scaling a SaaS business takes time and significant effort. All of the above is from personal experience. If I were looking for passive income from software I would've looked at desktop software.