[HN Gopher] The Tech Stack of a One-Man SaaS
___________________________________________________________________
The Tech Stack of a One-Man SaaS
Author : amzans
Score : 329 points
Date : 2020-11-23 13:06 UTC (9 hours ago)
(HTM) web link (panelbear.com)
(TXT) w3m dump (panelbear.com)
| rebataur wrote:
| For early stage startups we just released fsKube: Your full-stack
| kubernetes enabler
|
| fsKube provides as Desktop Web UI to setup entire AWS EKS
| Kubernetes cluster, with all the components and Django framework
| template with a full DevSecOps enabled, along with monitoring and
| operations.
|
| The whole thing within 45 minutes. Support for Spot Instances,
| Graviton Processor and AMD AMI coming soon, will reduce already
| cheap EKS prices further.
|
| Watch the full demo here https://youtu.be/Nt5yowdwm5Q
|
| Product https://rebataur.com/tools/fskube
| errantmind wrote:
| My One-Man SaaS tech stack:
|
| * AWS EC2
|
| * .NET Core Backend (Business logic + Kestrel Web server + Let's
| Encrypt + JSON Web API)
|
| * NOSQL Database: The filesystem
|
| * SPA InfernoJS front-end (similar to React)
|
| --
|
| The application is performance intensive and must deliver
| responses sub 100ms at at all times. Each 'request' from the user
| does a lot of work. I optimized to get all this to run
| efficiently on a $20 / mo EC2 instance, with no other costs
| ttymck wrote:
| Would love to hear more about how you deploy, manage and utilize
| Celery. I think there is a lack of quality case studies on
| celery-in-production. Thanks for sharing!
| avan1 wrote:
| Glad to see that stack works for author, but honestly one man
| show's shouldn't be multi lingual stacks at all IMO. for me php
| (laravel for back and front with blade templates) or js (express
| and vuejs for frontend) and docker-compose for deploying and
| developing stuff is fast and enough stack.
| vladletter wrote:
| Thank you for the sharing!
|
| About pricing:
|
| - Do you have any tool for cloud pricing tuning/estimations ?
|
| - Are you using specific tool to track all your expenses in
| general ?
| amzans wrote:
| I have used https://calculator.aws/ in the past, but to be
| honest it's difficult to account for the egress
| costs/networking fees using their calculator. Simple things
| like networking between Availability Zones/Regions can really
| creep up in your monthly bills if you don't watch out.
|
| I do track my expenses on a sheet manually, using a ballpark
| figure. At the end of the month I compare it with my AWS bill.
| If something seems off, I investigate it further. But I don't
| try to predict exact figures, more like expected ranges.
|
| I do miss the fixed-cost nature of DigitalOcean/Linode. I
| didn't have to worry about sudden charges, you pay $20/mo per
| node and that's it. Lots of bandwidth included.
|
| But for the most part it's fine, as long no bot starts
| bombarding your services with useless requests, egress costs
| tend to scale with revenue in my case, as my product's pricing
| is based on usage.
|
| I also have Cloudflare in front of my AWS stack, it has blocked
| a few small attacks already, but nothing serious yet.
| ezekg wrote:
| Fellow solo founder here. I feel like this is pretty overkill,
| most notably k8s (and terraform.) The last company I worked at
| used k8s and it felt overkill even for them. But if it works for
| you, great, but I definitely think that'd require spending too
| much of my time on devops. Maybe I should do a "counter" blog
| post on using Rails, Heroku, Redis and Postgres. :)
| paxys wrote:
| Seeing a lot of criticism on this thread, but honestly as a
| founder the best stack for your company is the one you know.
| Whether you use Kubernetes/Terraform or manually rsync a bunch of
| files to a server under your desk - do whatever works for you.
| er4hn wrote:
| Adding onto that - your priority is to be able to ship features
| and have an ease of maintaining them. This setup works for you,
| so it's great to see it be shared.
| mvanga wrote:
| Honestly, having gone down this path a year back, just use Heroku
| for your backend. Maybe Netlify if you want to separate your
| frontend and backend.
|
| The amount of complexity and interdependencies these "here's my
| stack" posts describe are always a huge cognitive overhead for
| running a one-person SaaS.
|
| Heroku costs more, but there's a reason for it. If you're even
| remotely making money from your product, and are alone in running
| the show, it's a no brainer to drop a couple hundred dollars a
| month to eliminate 99% of your ops headaches: the documentation,
| the add-on's, the fantastic UI, decent reliability, and ease of
| operations are totally worth it. Literally the worst thing one
| can say about Heroku is the cost, and possibly, the inability to
| build certain complex architectures (which most single-person
| SaaS services aren't).
| golergka wrote:
| I tried using AWS, Digital Ocean and other hosting platforms
| for my hobby projects, but every time I keep running into
| different problems and eventually give up and go back to Heroku
| - and things just work.
|
| I would never recommend Heroku for my employer or for any
| company that has real production loads and a budget for
| administrators that know how to set it all up: Heroku does seem
| to get prohibitively expensive at larger scale. But for hobby
| projects that get couple of hundred requests per day this is
| more than enough, and if one of them gets too successfull, I'll
| just pay someone for a day or two of work for migrating my code
| to other hosted platform - and since I never use vendor-
| specific tech, this shouldn't be too hard to do.
| amzans wrote:
| Heroku is a great product if you want development speed right
| from the start. I have used them in the past, and it was a very
| nice experience overall.
|
| For many projects this is more than enough. However, in my case
| I would be paying 2-3x more if I was using Heroku.
|
| With Kubernetes, in case I wanted to deploy new projects or
| even spin up a "testing" env, I can use the same stack/cluster,
| and not have my costs increase.
|
| I do realize that this is not for everyone. But for me it just
| made sense, and enabled me to work on new features faster than
| before.
| jaggederest wrote:
| I just wonder how much you're spending per month. Going from
| $200 to $600 in exchange for not having so many moving parts
| would be 1000% worth it to me. Usually the margin on SaaS
| businesses is in the 60% range, most of which isn't
| infrastructure, so it's a rounding error until you get to the
| size where you have full time people working on infra.
| [deleted]
| jrochkind1 wrote:
| I've been spending some time looking at moving to heroku, but
| having trouble figuring out how to use it for a real production
| for deploy for "only" a couple hundred dollars a month.
|
| Is that what you're doing? "Standard" dynos and just a few of
| them are working for you, I assume, for that budget? In my
| tests, with a Rails app, "standard" dynos are looking
| surprisingly slow, possibly unacceptably so. Very curious to
| hear about other people's heroku formations if anyone wants to
| share. What platform you're on (Rails or something else), and
| what your response times look like, would also be interesting.
| cldellow wrote:
| With a standard dyno, you get something like 1/15th of a core
| on the underlying EC2 instance. IMO, they're best for workers
| where latency isn't an issue.
|
| For user-facing work, I use performance dynos.
|
| Heroku _is_ expensive, but in exchange, you don't have to
| worry much at all about the ops side of things.
|
| YMMV, it may not be suitable if you need to be profitable
| each month and can't afford to spend the baseline cost of,
| say, $1,000/month.
| jrochkind1 wrote:
| Thanks. I agree that heroku is an amazing service, a really
| impressive product.
|
| But once you are using a single performance dyno, you are
| unlikely looking at a bill that's only "couple hundred
| dollars a month".
|
| Thanks for confirming you use performance dynos for user-
| facing stuff -- I thought I was going insane discovering
| that it didn't look like standard dynos were suitable for
| that for me -- is "everyone else" using them though? The
| heroku docs imply they are indeed... standard (that's the
| name), and the performance dynos are for unusual
| performance needs.
|
| Which is not what it was looking like to me.
|
| Based on my current investigations, I agree being prepared
| to spend $1000/month is a better back of the napkin to-
| start-with estimate.
|
| Which, sure, is quite possibly still a value compared to
| the number of hours you'd be spending setting up and
| maintaning something else. Quite possibly! But it's not "a
| couple hundred dollars a month".
| dyeje wrote:
| Checkout Hatchbox.io, just started using it myself. You
| basically pay a flat monthly rate for their Heroku-esque
| management service and then pay for the servers on your
| provider of choice separately (e.g. DO, AWS, etc).
| lambda_obrien wrote:
| I've been looking for something between Heroku (too
| expensive, too many features) and Dokkku (too much hassle,
| I have to maintain my own security and patches) and this
| looks like exactly the thing I wanted, except it looks like
| it's only for Ruby? I use a combination of Python, Elixir,
| and Haskell, so I'd love it if they did support other
| langs.
| cpursley wrote:
| Take a look at digitaloceans new app platform or
| render.com. Render allows you to run distributed Elixir,
| which is nice. And with digitalocean, if you outgrow app
| platform you could just move to their hosted k8s.
|
| These both are k8s under the hood but with everything
| extracted away to a heroku level, but much cheaper.
| Additionally, they both provide static site hosting like
| netlify.
| jrochkind1 wrote:
| Are you finding it mature enough to "just work"? The reason
| someone pays for something like heroku is they put a high
| value on "just work", I am really not looking to be
| troubleshooting weird bugs or figuring out weird edge cases
| in my ops, that's the whole point here!
|
| I'll take a look, it definitely looks interesting, thanks!
| paxys wrote:
| Heroku is terrible value for money. You can very easily use one
| of the dozens of free & open source deployment managers or CLIs
| for EC2 and get the same ease of use at 1/10-1/20 of the cost.
| It's good for hosting a hobby project for free or $5/mo and
| forgetting about it, but it doesn't make any sense for a
| startup.
| bredren wrote:
| Or side project. There is a learning curve to heroku of its
| own, and you could be spending that time just learning how to
| deploy docker containers.
| bryanrasmussen wrote:
| For the one man projects I'm thinking of starting there's a
| good chance I will make at best 100 a month for the first
| couple months, having probably only one customer for that time.
| ab-dm wrote:
| Heroku is a god send for getting off the ground, however the
| biggest issue for us hasn't been cost (it's high, but worth
| every cent) it's been server location.
|
| We're an Aussie company, and a large percentage of our
| customers are in Australia. Having servers only in the US and
| Europe mean that Australian customers speeds are slower than
| they should be, and private spaces are far too expensive to
| warrant it.
| aclatuts wrote:
| I have started using google cloud run as a drop in
| replacement for Heroku.
|
| It has almost all the same features and runs at almost any
| GCP location.
| padseeker wrote:
| I support this sentiment so much. I've been building something
| in my spare time. You are one person, the value provided with
| Heroku and the time saved is worth the cost versus AWS, at
| least for a project of this size and scope. It would take a lot
| more customers and capacity on the server to justify the ROI.
| aadithpm wrote:
| As a fairly new dev, this is really great information for me.
| Thanks for posting this.
|
| If you don't mind me asking, roughly how much do you spend (time)
| on this every week? How much of that is split between
| development, operations and product or business development?
| amzans wrote:
| Glad you found it useful!
|
| Since I have a full-time job too, my time on this project is
| pretty limited, usually no more than 2 hours per day.
|
| That's why I tried to automate and save time as much as I could
| using Kubernetes operators, well supported open source
| projects, and most importantly, tools I already feel
| comfortable with.
|
| I don't have hard rules in terms of how I distribute my time,
| but recently it may have looked like this:
|
| - 60% of the time I'm trying to understand the problem I'm
| solving (talking to customers, researching, evaluating
| features).
|
| - 20% working on features, and issues.
|
| - 20% promoting: writing blog posts, documentation, reaching
| out on Twitter, HN, Indie Hackers. Helping out customers
| integrate their website / understand how something works.
|
| Of course, there's tons of other smaller things here and there,
| but those are the big "buckets" of my time.
|
| Once I know what to work on next, I tend to prioritize as
| follows:
|
| 1) At the start of each week I pick 1-3 topics to work on next
| (for example writing a new blog post, working on a new feature,
| or even just writing documentation which I am going to next).
|
| 2) Each day when I'm working on my project I pick the most
| impactful thing I could work on, and start with that. I allow
| myself to explore a topic in depth, sometimes without a clear
| goal or deadline. After all it's supposed to be fun if I want
| to stick to it for the long term.
|
| 3) I try to respond to customer emails as soon as I can, and
| understand why they're giving my product a try. That's my gauge
| for what to work on the following week.
| XCSme wrote:
| This is a lot more complex than I expected.
|
| I personally just use one ore more VPSs on DigitalOcean, which
| scale pretty well at first and if you get enough traction to need
| "infinite" horizontal scaling, it might be better to only focus
| on that once you have the money to hire some sys
| architect/admins.
| k__ wrote:
| This seems like an awful small share of managed services for a
| one-man show.
|
| I mean, K8s? Come on!
| idlewords wrote:
| A good rule of thumb for success is to have more paying customers
| than there are layers in your tech stack.
|
| Another rule of thumb is to have a setup so basic that articles
| like this are no fun to read or write. The limiting factor in a
| one-bro setup is complexity, and this guy maxed out about one
| paragraph in to his description.
| [deleted]
| blitblitblit wrote:
| Presuming you are using Github and were using Angular, I think
| "Google Chrome" is missing from the "Other" stack - since I have
| had problems even in Firefox try to get latest Google
| WebComponent shinies to work.
| thrower123 wrote:
| I expected a much more boring stack, to be honest.
| Ozzie_osman wrote:
| At my startup we use a pretty similar tech stack, except we are
| on Heroku for infrastructure which makes our life a lot easier,
| and gives us things like review apps quite easily.
|
| One piece we've struggled with is just mypy doesn't seem to play
| too nicely with Django. It definitely feels like a world of
| difference between the type support we get in our React app with
| Typescript and mypy with Django. Would be curious what OP's
| experience has been with that.
| pirsquare wrote:
| FWIW, Pieter Levels just started using Git last week.
| https://twitter.com/levelsio/status/1327451757975375874
|
| This is one-man who made > $1million a year.
| real_ben_michel wrote:
| Super similar to what I use (http://www.casaspanish.co.uk).
|
| Django has just so much stability, it was an obvious decision for
| me to go with it. And that's speaking as someone who has mostly
| worked with NodeJS/React for the past 5 years.
|
| I love the pythonic principle of "There should be one obvious way
| to do it". This helps me cut down on decision making which is
| something quite annoying to deal with as sole-tech-founder. Now I
| get to focus on the business, and technology is just a matter of
| execution.
| ericmcer wrote:
| How did you land on another analytics SaaS product? I think like
| every dev I have always dreamed of starting my own thing, but
| never had the time/energy to compete with existing spaces, and
| couldn't think of any new markets create. It just seems crazy to
| me when someone is like: 'oh I am gonna make a tool for people to
| manage their finances' when 1000 exist, but then they build it
| and achieve some level of success.
| davnicwil wrote:
| If I were to attempt a one liner for the key takeaway from this,
| it'd be "use frameworks as much as possible, use managed services
| as much as possible".
|
| It's a position I couldn't agree with more. It might be one of
| those mistakes you can only _truly_ learn from by making it
| yourself, but honestly, while DIY is awesome for learning its
| only place in a business is at the core of what your business
| value is.
|
| One way I think about it is anything DIY is surface area for
| either innovation, or mistakes. To mitigate the risk of making
| mistakes doing things DIY you'd better do it only in areas where
| innovation could actually benefit your core business value and
| give you magnified upside. If you innovate outside these areas, I
| guess it's nice, but you've taken the risk of mistakes for no
| significant upside. Not to mention a whole load of work invested.
| qrohlf wrote:
| A lot of people here are recommending stacks that have worked for
| them, or cautioning against over-engineered stacks that didn't.
| All of that is useful, but I'd boil a lot of this down to one
| simple axiom:
|
| If you're a professional engineer and you're starting a tech side
| project with the goal of shipping - use what you know.
|
| I do a lot of work with node, cloudfront, s3, and React for my
| day job. All of my side projects are built on node, cloudfront,
| s3, and React. This works well for me because my goal with side
| projects right now is to be productive, not to learn new tech.
|
| An important clarification is that I use the tech that _I use_ in
| my day-to-day, not what _my company_ uses. Just because I have
| coworkers who know kubernetes back-to-front doesn 't mean I do!
|
| Also, there's nothing wrong with doing side projects with totally
| crazy/new tech stacks as a way to explore and learn new tech. I
| just think it's good to be really intentional with whether the
| goals of a project are educational/process-oriented or results-
| oriented.
| johnestar wrote:
| wow, pretty amazing post
| deforciant wrote:
| I use similar stack too :)
|
| - GKE kubernetes - Managed Postgres (CloudSQL) - GCS buckets for
| file storage - Cloudflare for DNS - Countour for ingress - Keel
| for automating deployment updates - Mailgun - Sentry (errors) -
| Node-RED various little automations such as healthchecks
|
| Planning to introduce Elasticsearch too, so far I have been
| testing the operator and it seems to be pretty good quality.
|
| From maintenance perspective GKE is great, as long as the bills
| are paid, no need to login there pretty much ever. As a one man
| company this means a lot, I try to never spend any time on ops.
| fxtentacle wrote:
| Here's my self-serving advice for every one-man SaaS:
|
| Use Heroku.
|
| It's super easy to get started. And when you reach $2000+ in
| monthly bills, hire me to move things over onto dedicated or EC2
| so that you'll get 10x that performance for the same price.
|
| As for the actual language, I think PostgreSQL + Ruby Backend +
| JS Frontend is still the easiest way to get started.
|
| All those great architectural ideas don't matter much until you
| have your first $5k monthly in reliable revenue. And by then,
| you'll have a completely different perspective than what you
| think you need now.
| aerovistae wrote:
| Okay, this thread is making me nervous about Heroku. I'm
| building a web app that runs on it and I clearly have not given
| the pricing scaling as much thought as I apparently need to.
|
| My site is a firebase powered SPA, so the only thing Heroku has
| to handle is the initial pageload....I would think that the
| standard 1x dyno would be sufficient for that....which is not
| very expensive...
| tensor wrote:
| I'd actually suggest PostgreSQL + Hasura + React with Ant
| Design or Material UI
| fxtentacle wrote:
| For many newcomers starting out, the Rails CRUD generators
| are good enough to generate their entire admin area. And
| Rails comes with sane security defaults.
|
| I agree that GraphQL + React will be pretty and work well.
| But for one-man start-ups, the focus is usually on "looks
| good enough and kinda works".
|
| So I believe I'd go with Bootstrap & Glyphicons, just to get
| results faster.
| cpursley wrote:
| Hasura outperforms Rails by an order of magnitude in
| addition to being faster to develop with. Supabase also
| looks really nice.
| armatav wrote:
| This man knows the way.
|
| I use this stack and I'm pretty sure I could pump out any
| SaaS business in about two weeks with it. Host on Heroku, use
| whatever analytics system you want.
| taffer wrote:
| > PostgreSQL + Ruby Backend + JS Frontend is still the easiest
| way to get started.
|
| With JS, do you mean React or jquery or literally JavaScripting
| the DOM?
| fxtentacle wrote:
| I meant some sort of JavaScript framework. I'd say that part
| mostly depends on personal preference. I'm quite happy with
| Angular, but I've also had lots of smaller one-off pages
| where I used jQuery.
| xu3u32 wrote:
| How hard is CORS set up with dedicated frontend/backend? I'm
| running into this with Django REST and VueJS. Or do you just
| host both using Heroku?
| xyst wrote:
| if you truly want to save some $$$, host it on your residential
| line and proxy the requests through an external load balancer.
|
| could also rope your friends/family into it if you want your
| app to be "distributed", might require a lot of work though
| especially if they are not very technology oriented.
| FreekNortier wrote:
| But does Python scale for back end applications?
| underdeserver wrote:
| Yes, it does, as long as performance-bottlenecked code is not
| in Python (and it usually isn't). In the real world, you may
| have to extract some hot regions to C++ or Rust or Java, but
| 99% of your code will scale infinitely.
| amzans wrote:
| My team migrated a service handling >1.6k req/s at peak time,
| from Scala (Finatra), to Python (Django). Same number of
| servers (3x c5.large), just higher CPU utilization (from ~15%
| to 70%).
|
| Scala was great, but unfortunately it made it difficult to
| onboard new team members into the project, so development
| suffered. Also the rest of our stack is mostly Python, so we
| couldn't use a lot of the common tooling, and libraries we
| had built for other projects.
|
| We migrated it within a month, and it's been running for
| almost a year without issues.
|
| At some point the service even recorded 3k+ req/s at ~200ms
| 99p latency. Yeah, maybe not Google scale, but more than
| enough for 99% of the businesses out there.
|
| This service handles about 2.5 billion requests per month
| from one AWS region. We're a small team, and that's only one
| of the services we support. Which is great because we don't
| need to spend all of our time optimizing it.
| Ozzie_osman wrote:
| Or, alternatively, if most of your heavy-lifting is already
| done in the database layer there's less work for Python to
| do.
| derwiki wrote:
| Ask any number of the very successful companies who use Python
| hansvm wrote:
| A single core running Python will easily handle more load than
| most successful SaaS companies ever reach, especially in web
| dev where most of the real work happens in a database of some
| flavor.
|
| There absolutely are performance pitfalls, and Python is less
| power efficient than other alternatives running some kinds of
| workloads at scale, but in a ton of environments the perf
| difference doesn't matter.
| jrochkind1 wrote:
| I do ruby/Rails and not Python, so it may differ.
|
| But while I too had in my head "for web dev most of the real
| work happens in a database of some flavor", I recently
| realized that was _not_ true for my app, probably hadn 't
| been true for some time, and probably isn't true of most
| Rails apps (possibly not the same for non-Rails web apps?).
| If you've properly eliminated n+1 queries and other
| inefficient querying, I find that my apps are spending only
| 20 or 30ms waiting on DB results, and a couple hundred on CPU
| tasks to render HTML.
|
| I know people are going to reply with "That's because Rails
| is slow," but I'm not sure that's true for what we're talking
| about compared to similar Python platforms, I'd be interested
| in seeing numbers for other real apps. In the Rails community
| too, people still repeat the assumption "most of your
| response time is spent waiting on the DB" -- but I dont'
| think it's actually true anymore (it may have been once).
| hansvm wrote:
| The "most of your response time is spent waiting on the DB"
| assumption might not hold for your app. Even if you
| actively push work to the DB to reduce network bandwidth or
| something, your workload might fundamentally be comprised
| of small, easy-to-optimize units of work that the DB
| handles without any issues.
|
| That said, hundreds of milliseconds sounds slow by an order
| of magnitude or more for html rendering, even if all the
| work is done in a batteries-included framework for a
| dynamic language, and it doesn't jive with my Python
| experience at all. Do you mind me asking what kinds of
| tasks are taking that much time?
| jrochkind1 wrote:
| In this app, mostly lots and lots of thumbnails. It may
| be some unoptimized code.
|
| But rather than get into the details of my app, and parts
| that need optimization (whether in my local code or in
| Rails or in ruby), I'm more curious about the overall
| concept.
|
| Are you _sure_ that most of your web app 's time is spent
| waiting on the DB? My suspicion has become that this is
| conventional wisdom that is not actually true of most
| apps anymore. But I could be wrong. Or I could be right
| only for Rails and not python because Rails is slower
| than typical python, or something. I am curious to find
| out.
| hansvm wrote:
| > Are you sure that most of your web app's time is spent
| waiting on the DB?
|
| Positive. It's my first tech job though, and we use C# at
| work to the extent that matters.
|
| The kind of Python I write off the clock probably isn't a
| good example of waiting on the DB though. It's usually a
| thin wrapper around C or assembly (or calling into such a
| library via numpy, networkx, etc) to do something
| horrendously expensive that I absolutely would not want
| to run in vanilla cpython. That said, when I do
| ordinaryish web-related stuff in Python I'm looking at
| well under 20ms total elapsed time per call, which is why
| your ~200ms html rendering time stuck out to me.
| eggsnbacon1 wrote:
| time "spent" in the database depends on the speed of DB
| drivers too, which depends on the language. Our stuff is
| Java and average query is ~2ms round trip.
|
| Python, Ruby and friends are bad for page speed metrics.
| REST response time of ~200ms vs ~10ms for our java backends
| Axsuul wrote:
| Thanks for sharing! How are you liking Loki so far? I'm looking
| to migrate off Google Cloud's logging offering to Loki but was
| worried about its maturity.
| attollos wrote:
| There is a typo on your landing page: "The short answer is: we
| doesn't use tracking cookies"
| ishjoh wrote:
| My one man tech stack.
|
| Scala (akka http, slick, Twirl) Postgres AWS EC2
| Jquery/Javascript
|
| https://www.formgadget.com/ for those curious.
| eric_b wrote:
| It's cool that this stack works for the author, but if anyone is
| just starting out on their own one-person journey to build a
| product, I don't think they should follow the stack in this
| article.
|
| There are too many dependencies and too much complexity here.
| Kubernetes is overkill for 95% of applications, especially single
| founder SaaS businesses. Clickhouse may make sense for an
| analytics product but caring and feeding it is non-trivial (see:
| ZooKeeper dependency and all the problems you get once you move
| to a distributed database).
|
| Most people would be better off with a single beefy machine
| running Linux, Postgres and whatever web app framework they know.
| The whole "cattle not pets" thing is fine once you obtain product
| market fit and your product needs to scale up. At that point
| you'll have time and money to do it - before then you're just
| wasting cycles.
| treis wrote:
| >Most people would be better off with a single beefy machine
| running Linux, Postgres and whatever web app framework they
| know
|
| The problem is back ups. You've got to figure them out
| yourself. And there's a decent chance that you do it wrong
| leading to potentially catastrophic data loss.
|
| IMHO, managed DB + S3 equivalent and then doing your own server
| is the sweet spot. You don't have to worry about data loss and
| it's still pretty cheap and flexible.
| benbristow wrote:
| If you're using something like DigitalOcean, you can enable
| full system backups for 20% of the cost of the 'droplet'
| (VPS) a month in one-click. Probably quite a safe bet.
| triangleman wrote:
| Indeed OP uses this sort of stack in his full time job and has
| learned about all the kinks over the years, while getting paid
| to do it!
|
| I'm working on a side project and it's literally a bunch of .py
| files in a folder. Libraries include fastapi and sqlite3. I
| cannot think of a reason to use container orchestration over a
| "single beefy machine" in almost any use case.
| sgarland wrote:
| Not having to recreate your Python env, not having to worry
| about dependencies (once they're pinned), the ability to run
| the app on a hosted service like Fargate instead of managing
| the server...
| mixmastamyk wrote:
| Side project vs. business with paying customers and bus
| factor is a different equation.
| 0df8dkdf wrote:
| > There are too many dependencies
|
| Agree. Blindly recommend this to anyone is not a good idea! It
| comes down to author's skill sets, and if the author is truly
| interested in tech, or just some guy want to implement an idea.
| Personally I am full stack and know how to make server scale
| without using Kubernetes. Since I've being using commonJS since
| it's inception, it is pretty easy to write web apps that scales
| using a light weight server layer like v8.
| kodah wrote:
| Personally, I run a Kubernetes cluster that _all_ my projects
| go on by default. DigitalOcean hosts mine and my bill is pretty
| low. I set it up for this exact reason, so I could continue to
| use my knowledge of containers and container scheduling systems
| to get easy wins early on.
| mixmastamyk wrote:
| > once you obtain product market fit
|
| This phrase assumes a unique product, while many have probably
| been done before.
| BobbyJo wrote:
| Kubernetes honestly isn't that complicated. It's complexity
| really only scales with the complexity of the system you're
| running on it. If you're just bringing up a database and a
| backend on top of it, it's honestly very simple to get running
| on a single linux box using something like microk8s. And, as a
| benefit, you can move everything over to EKS or GKE in like a
| few hours max, if you ever need to scale.
| ownagefool wrote:
| I think (one of) the big win(s) with k8s is testing in
| namespaces at a pace that doesn't really slow you down. If
| you think you'd want to do end2end against an environment
| entirely built by code, k8s is a really good building block.
|
| If you think a one man band and his ruby app can probably go
| pretty far with self-discipline, but if I'm choosing to do
| any sort of IaC I'd probably recommend looking at k8s as a) a
| faster solution, b) a more versatile solution and c) largely
| vendor agnostic solution.
|
| Point being, I'd probably recommend folks learn to use k8s
| before they invest time learning lambda, EC2, or ECS, but if
| you're a small team and you already have lambda, EC2, or ECS,
| and it's working for you, then it's hard to argue for change.
| hasithsen wrote:
| I second this. If what you are familiar with is <stack-that-is-
| not-cool-by-popular-opinion> but know it would work, go with
| it. You don't have to struggle with a new tool if something
| similar is already in your toolbox, and you already have a lot
| of experience using it. Of course, do this unless you are
| building to learn (and maybe ship), rather than to just ship.
| And if the new tool proves to be a better one, you can upgrade
| then.
| amzans wrote:
| I agree with you. I wouldn't blindly recommend my stack to
| everyone, one could argue it's probably even overkill for my
| SaaS project right now. At this scale I could get away with a
| couple of $20/mo instances, and call it a day.
|
| However, it just made sense for me due to the simplified
| operations, and re-using most of the learnings from my full-
| time job. It has enabled me to move faster in shipping
| customer-facing features.
|
| If I wanted to start a new project, I can leverage the same
| stack and be up and running in minutes. Which means I can take
| advantage of my cumulative efforts for any future project.
|
| It's definitely not for everyone as you said, but it might be a
| good solution for many :)
| nullsense wrote:
| I think the key thing is that you already know the stack and
| didn't have to learn it. I wouldn't recommend it to someone
| for whom the learning curve will be brutally steep, but if
| you already know it I'm sure it's pretty game changing in
| terms of scale you could handle just being a solo dev.
| segmondy wrote:
| Your stack is great. If anything, I think many one-man SaaS
| will benefit from using k8s. That's the superpower of k8s,
| one person can go from 1node to 1000nodes if they need that
| scaling with minimal effort. Cobbling together shell scripts
| and tools for one or two servers is just as much work as
| using k8s, so long as you don't run your own and use a
| managed service. Best of luck, I think your list is pretty
| reasonable.
| ignoramous wrote:
| > _However, it just made sense for me due to the simplified
| operations, and re-using most of the learnings from my full-
| time job. It has enabled me to move faster in shipping
| customer-facing features._
|
| As someone who is mostly in the same boat as you, you have
| got a strong point in terms of favouring tricks you know
| best.
|
| The amount of code I have had to throwaway made me not want
| to invest in things that require lots of resources to run and
| maintain (in other words, things I'd not be comfortable with
| managing all by myself).
|
| I almost always default to managed and serverless products:
| This won't necessarily be a winning strategy for everyone to
| say the least as it brings its own complexity to the table.
| It is pragmatic; however (like you call out), to trade one
| set of complexities (one that I am comfortable with) for
| another.
| amzans wrote:
| Hey that's great! I think everyone should do what works for
| them.
|
| Using a tool "just because" it worked for others, seems to
| be what often drives many decisions in this industry. For
| example, would you go for the 2,200+ microservice
| architecture from Uber[1] just because they say it solved
| all their problems? They probably have their reasons, and
| they are unlikely to be the same as everyone else.
|
| I know my stack as a solo founder is unconventional, but
| it's what has worked best for me. And I'm happy with my
| choice.
|
| If serverless does the trick for you, then focus on that,
| and keep building the features that your customers actually
| care about.
|
| [1] https://eng.uber.com/microservice-architecture
| bonestamp2 wrote:
| It is more complex than what I'm looking at right now, but I
| still appreciate the read as it helps me think about some
| things I can do now to be better prepared for a more scalable
| environment later. Thanks. Oh, and I had one (serious, but
| off topic) question... what are you using to brew your fresh
| cup of coffee?
| redisman wrote:
| I believe 100% that a one-man SaaS needs to leverage their
| existing knowledge even more than a team. So for me it would be
| a no-brainer nodejs, dynamo, etc. - the tech I use every day
| and know in and out. You should have a very good reason to
| stray from your core if you actually want a business and not
| just a fun coding challenge.
| CraftThatBlock wrote:
| SaaS business single founder here, moved from a mix of GCP's
| Cloud Run, Cloud SQL, and Compute Engine to DO's managed
| Postgres and Kubernetes, and it has had the follow effects:
|
| - Much cheaper, reducing bill from >100$/month to ~40$.
| Important for early stage startups - More performance, easier
| scaling. Found that my application was much better suited to
| run in K8S, but this is definitely specific to my use-case -
| Consolidation of resources. Except Postgres/Redis, everything
| is in my cluster, simplifying management and maintenance
|
| For my business, this was a great move, but as others have
| said, I wouldn't recommend it to everyone. K8S is a great and
| powerful tool, but also is very complex.
| tebbers wrote:
| Did you experience the downtime issues with DigitalOcean
| managed Kubernetes that the author also experienced? I'm also
| considering DOKS so would be great to know!
| nrmitchi wrote:
| Note: source for this information is from discussions with
| DO via support and the kubernetes slack. I am not
| affiliated with DO in any way.
|
| The downtime issues with DOKS are directly related to the
| resources allocated to the control plane, which is _not_
| set up in a HA capacity. The resources assigned are
| directly related to the size /number of nodes you use. API-
| heavy applications can very easy knock out the control
| plane, and in that situation is takes it a (relatively)
| long time to recover on it's own (I would typically see
| ~4hr before it became responsive again).
|
| Their support team is able to modify the master resources
| for a given cluster (to assist with recovery), but the
| turn-around time on that shouldn't be considered
| "production ready".
|
| At this point my advice for DOKS would be:
|
| - Are you using very basic, out-of-the-box Kubernetes to
| host "apps"? You will probably be fine, but be sure to have
| a back-up.
|
| - Are you planning to use Operators, or anything that
| heavily interacts with the kube-api? I would recommend not
| using it, or over-provisioning your cluster (which would
| very quickly offset the advantage of the "free" managed
| masters).
|
| I know that they are working on fixing some of these
| reliability issues and I have hopes that it will be more
| stable shortly.
|
| At this time I have a "stable" cluster which (unless their
| support lied to me) had master resources manually increased
| by their support team after the 3rd incident of it dying. I
| haven't had an issue since then.
| tebbers wrote:
| Thanks for the info. That doesn't sound good - one major
| reason for considering moving to Kubernetes was for the
| high availability.
| nrmitchi wrote:
| Availability of your applications, and availability of
| the kubernetes control plane, are not typically
| correlated. One of the nice things about how Kubernetes
| orchestrates is that the master is _not_ in the path of
| requests. Ie, in many situations the Kubernetes master
| may be unavailable, but your applications will be
| unaffected and can still serve traffic.
| nickthemagicman wrote:
| What do you mean API heavy? Do you mean hitting the
| kubernetes API?
|
| Does k8s auto scaling count?
| amzans wrote:
| I guess he means the Kubernetes API which is what most of
| the controllers, and other components talk to.
|
| That was my case too. It was mostly when I installed the
| prometheus-operator that things would go south, even if
| the nodes themselves were perfectly healthy and
| underutilized.
| CraftThatBlock wrote:
| I had no issues so far, everything has been fairly smooth.
| Setup was very easy too (was my first cluster setup), and
| pricing is very good.
| Pandabob wrote:
| I'm running something similar and have to admit that the
| ~70$/month for CloudSQL grinds my gears a little. The pricing
| for Cloud Run on the other hand is pretty sweet.
| CraftThatBlock wrote:
| Agree. The databases we're my biggest costs on GCP, and DO
| offers more for less.
|
| Cloud Run, as you said, is pretty great. In my other start-
| up, we're using Cloud Run and Cloud SQL, and again, Cloud
| SQL is the biggest cost (~95-99% of the bill)
| dobg24 wrote:
| Is it okay to touch base with you directly? I would love to
| hear your feedback and how we can help. Nothing to sell.
|
| - PM for DO Kubernetes.
| CraftThatBlock wrote:
| Yes! You can find my email on my profile
| wdb wrote:
| I wish companies would have better visibility to allow them
| to approve DO for cloud stuff. Struggled to get the
| necessary compliance docs under NDA from DO
| bdcravens wrote:
| If Docker is advantageous, then ECS is great alternative to
| Kubernetes. It gives you most of the benefits in a fully
| managed offering.
| nickthemagicman wrote:
| Didn't they recently integrate with docker compose? It looked
| really cool but I haven't tinkered with it yet.
| bdcravens wrote:
| Yes.
|
| https://docs.docker.com/engine/context/ecs-integration/
| nickthemagicman wrote:
| Have you messed with the docker compose integration?
|
| Did you like it?
| bitwize wrote:
| When people bring up "cattle, not pets" I tell the story of my
| uncle, who runs a small dairy farm in Wisconsin. He has about
| fifty head of cattle, gave each of them names, and takes care
| of them when they're sick.
|
| Point being that it takes very large scale for the principles
| people refer to when they say "cattle, not pets" to kick in --
| even when you're actually raising cattle. But by the same
| token, automated reproducible configuration is a huge win
| whether you have 1 server or 10,000.
| jturpin wrote:
| Setting up Kubernetes is a fixed cost in the beginning with
| clear payoffs. Things like microk8s, Rancher or GKE/EKS make it
| a lot easier to set up than it used to be. Deploying your app
| is then just a simple Helm chart, or another way of getting
| deployments out. If I was running any kind of business that was
| making more than zero dollars I would absolutely go with
| Kubernetes. I don't think it's as complicated as people think
| at any rate, and it lets you use premade Helm charts which can
| simplify the deployment of things like Clickhouse.
| ramraj07 wrote:
| No it's not, assuming your database sits outside k8s there's
| absolutely nothing that needs to be fit inside k8s, a simple
| machine running docker if needed is more than sufficient.
|
| K8s is such a huge mental overhead that if it's not already
| naturally in your head because you've had extensive
| experience (or apparently born geniuses) no one with limited
| tech budget should ever do this.
| jturpin wrote:
| All of these tools (Terraform, Kubernetes, Github
| Actions/Other CI) seem like overkill until a node dies and
| you need to recreate it, or configuration gets messed up
| and you don't remember how you deployed it in the first
| place. It sounds like the OP has had experience with these
| problems. If these aren't problems you have interest in
| solving, then Heroku or a similar platform would be the way
| to go.
|
| Running a business on a single node is not advisable. If
| your scale is that small, or uptime doesn't matter, then
| sure go with that. If you're running on multiple nodes,
| you're going to need a way to schedule containers to your
| cluster one way or another. Scheduling and orchestrating is
| where complexity get introduced - Kubernetes wrangles this
| complexity.
|
| You can run a lot on a $5 server. I would probably run 3
| $10 servers for a small business at least, which feels like
| still within the realm of a cheap budget for business
| infrastructure costs.
|
| As far as Kubernetes complexity goes, I think this is a
| self-perpetuating idea on internet tech communities. I
| don't think it compares to the complexity of actually
| programming the web apps themselves. There's like 6
| resource types you have to be familiar with to work with
| Kubernetes, and most of that will just be Deployments
| (where containers actually get scheduled and run, health
| checks, etc). The others are for configuration and routing.
| deckard1 wrote:
| > configuration gets messed up and you don't remember how
| you deployed it in the first place
|
| Configuration getting messed up sounds more like a k8s
| problem than anything else. In any case, if you aren't
| using git and don't know how to at least back things up
| you really should be asking yourself if a tech company is
| right for you, as a one man/woman operation. There are
| countless other ways to make money online. Etsy,
| Craigslist, Shopify, etc.
|
| > until a node dies and you need to recreate it
|
| The way to solve both of these problems on a single node
| operation is to create a snapshot/clone of your machine.
| At that point you would really just need to worry about
| the IP address changing and/or updating DNS when
| restoring the image. The best part is you can take this
| "master" copy and deploy it as a staging server. Or even
| horizontally scale by throwing a load balancer on top.
| You can even get your VM exactly how you want it locally
| and then deploy it to DO, Linode, Vultr or whatever.
| jturpin wrote:
| > Configuration getting messed up sounds more like a k8s
| problem than anything else. In any case, if you aren't
| using git and don't know how to at least back things up
| you really should be asking yourself if a tech company is
| right for you, as a one man/woman operation. There are
| countless other ways to make money online. Etsy,
| Craigslist, Shopify, etc.
|
| I don't know if this was to intended to directed at me,
| but all of the tools mentioned imply using them with git
| or other version control, hence Github actions / CI.
| Kubernetes does not spontaneously mess up your
| configuration, well intentioned developers do.
| Willingness to learn new-ish technology puts you in a
| much better standing for running a tech business.
|
| The snapshot/restore method is fine if you don't plan on
| updating very often, but this isn't a good alternative to
| infrastructure as code. I would make a base image that
| bootstraps your node to a cluster in Packer and then hand
| off all the deployment of nodes/DNS/Loadbalancer wiring
| in Terraform. Then just snapshot your database volumes as
| normal and deploy with your orchestration.
| throwaway894345 wrote:
| > The whole "cattle not pets" thing is fine once you obtain
| product market fit and your product needs to scale up. At that
| point you'll have time and money to do it - before then you're
| just wasting cycles.
|
| Is this true? At my last company we wasted a bunch of time
| every week dealing with the accumulation of ad-hoc changes in
| different environments creating different behavior. When we
| pivoted to a continuous deployment model (we also moved from
| EC2 to ECS/Fargate), all of this time went away as did all of
| the guess-work and fear of deploying to production (because
| production very rarely deviated from lower environments with
| respect to behavior, because all environments were
| reproducible). It also enabled us to stand up whole
| environments with the press of a button, which made it a lot
| easier for developers who were interating on infrastructure (we
| had a lot of async ECS/Lambda workloads). I'm sure if we were
| smarter or had the right kind of discipline we could have made
| pet EC2 instances work, but we benefited a lot from moving to
| cattle/containers.
|
| NOTE: I also suspect that cattle/EC2 is a lot harder than
| cattle/containers, but that may also just my inexperience with
| the former. I would really like to know how to do reproducible
| EC2 instances properly, but from the research I've done, it
| seems like one has to reinvent a good chunk of Kubernetes.
| akiselev wrote:
| There may be a rare exception here or there where network
| effects or some other unique market need require a startup to
| treat their infrastructure as cattle, but otherwise it's
| absolutely true. Running `git init --bare` on a server,
| setting up some remote origins, slapping some bash scripts
| into the git hooks folder, some .service files for systemd,
| and then running `git push origin dbhost && git push origin
| apihost && git push origin ...` is a hell of a lot simpler
| than even getting a toy version of kubernetes up and running.
| For the developer with average linux skills, it's probably
| even easier than figuring out which cloud orchestration
| monstrosity to choose. Throw in Github actions and baby,
| you've got a stew going!
|
| Maybe I'm misunderstanding the whole "pets vs cattle" thing
| but you don't need to lose repeatability or give on process
| altogether; it's a false dichotomy. Just don't dive headfirst
| into the massive complexity that is "scalable" devops - you
| can still use terraform or docker compose or whatever to
| deploy your application and provide repeatable
| development/staging/test infrastructure.
| throwaway894345 wrote:
| > is a hell of a lot simpler than even getting a toy
| version of kubernetes up and running.
|
| Getting it off the ground is one thing, keeping things
| reproducible so you can stand it back up reliably if the
| instance goes down is another thing. You need to know what
| are the relevant changes that people have made to the
| instance over its lifetime in order to reproduce them on
| the new machine. Maybe this is not what people mean by
| "pets vs cattle", but they seem pretty closely related if
| nothing else. I guess the thing I care about is
| "reproducibility" and for all of its complexity, Kubernetes
| makes the happy path pretty clear in this regard whereas
| with EC2 you need Ansible and a whole bunch of playbooks to
| reproduce things like SSH, logging, monitoring, process
| management, etc that Kubernetes or ECS or whatever give you
| out of the box. And if you find that you need to scale
| beyond one or two instances (not everything is a CRUD
| webapp, after all) especially autoscaling, then it seems
| like the EC2 story becomes even more complicated (you now
| need something to automatically invoke Ansible with the
| right playbooks for each node). I'm probably biased by my
| experience (aren't we all?) but it seems like Kubernetes or
| ECS/Fargate are simpler in these regards.
| AlchemistCamp wrote:
| > And if you find that you need to scale beyond one or
| two instances (not everything is a CRUD webapp, after
| all) especially autoscaling, then...
|
| Have you _ever_ been working a solo project that needed
| autoscaling? If so what was it doing that was so resource
| intensive per $ earned that it was still a solo project?
| throwaway894345 wrote:
| Picture an analytics application--something that has to
| crunch a bunch of data per request, and your users are
| mostly visiting from 9-5. Depending on the size of the
| user's data source, they could easily use a whole CPU and
| a lot of memory for each request and requests can take up
| to 60s or maybe even multiple minutes. You need to run
| more than a handful of machines, so you can either
| overprovision or autoscale, but in either case you need
| some amount of reproducibility to wrangle all of those
| machines and you'll probably want to plan for them to
| come and go because you probably don't want to pay for a
| bunch of high-end machines sitting idle every night.
| Optimization is nontrivial so you'll get around to it
| eventually and maybe even hire, but hiring your first
| employee is a lot harder than hiring your 101st employee,
| so you're not going to do it right now but you still need
| a solution to your problem...
| akiselev wrote:
| _> Getting it off the ground is one thing, keeping things
| reproducible so you can stand it back up reliably if the
| instance goes down is another thing._
|
| Are we talking about pet servers or kubernetes here?
| Jokes aside, I think you're underselling how complex
| Kubernetes is and overselling how complex logging,
| monitoring, process management, et al are. You don't get
| any of those things with kubernetes "out of the box"
| unless you've got an ops team or someone's got a year
| plus experience running one cloud provider's version. It
| seems really easy cause we've got one click clusters and
| a bunch of great UIs but all the time people spend
| chasing down problems and wrangling the extra complexity
| of k8s in production gets papered over because it's the
| hot new thing.
|
| The bash history for the setup above fits on a single
| page and since the advent of Nix and now Terraform,
| repeatability hasn't been a problem. The harder part is
| discipline among coworkers but Linux user/group
| permissions go a long way towards making it readonly for
| debugging purposes while still giving fine grained
| control over servers.
| throwaway894345 wrote:
| > Jokes aside, I think you're underselling how complex
| Kubernetes is and overselling how complex logging,
| monitoring, process management, et al are. You don't get
| any of those things with kubernetes "out of the box"
| unless you've got an ops team or someone's got a year
| plus experience running one cloud provider's version.
|
| I'm pretty sure cloud providers give you logging and
| monitoring out of the box (as well as a bunch of other
| stuff) and Kubernetes itself is a process manager with
| its own "SSH" (kubectl exec) and so on. I'm not wed to
| Kubernetes either--you could use ECS/Fargate or whatever.
| But to do something comparable in an EC2 environment
| requires a fair amount of experience just to get to get
| the basic things that Kubernetes (or ECS) gives you out
| of the box. Of course, if you're well-versed in VMs
| already then I don't think you'll get much value out of a
| container solution for simple workloads, but if you're
| not familiar then I think container solutions are easier.
| But again, I might be biased by my experience.
| noodle wrote:
| I think it entirely depends on the path you're taking. For
| example, I'd disagree with the quoted section you made for a
| different reason. I'd almost always suggest early stage
| startups to use something like Heroku (if it works for them),
| which gives them the ability to pay a small premium in order
| to never have to spend too much time dealing w/ devops stuff.
| Pre product-market-fit, that's wasted time/effort unless
| specific devops needs are essential to getting there.
| fweespeech wrote:
| > Is this true? At my last company we wasted a bunch of time
| every week dealing with the accumulation of ad-hoc changes in
| different environments creating different behavior.
|
| That is an issue a disciplined one-man operation won't have
| since (generally) they have a Dev and a Prod environment, the
| changes would be made in Dev first then duplicated in Prod.
|
| If you have 2+ developers, you have environment drift like
| you experienced because (generally) Dev is the local
| environment on the laptop or otherwise a distinct environment
| for each developer. So now you have 3+ environments you need
| to sync and then discipline starts to fall apart as you have
| to communicate every change.
| throwaway894345 wrote:
| What happens to the disciplined single dev when their EC2
| instance falls over in either environment? How do you get
| things back in sync without code to automatically stand
| things up in the right state? And if you're going through
| the work of writing/maintaining that code, are you saving
| anything over using Kubernetes (consider out of the box,
| Kubernetes gives you logging, ssh, process management,
| service discovery, etc)?
| fweespeech wrote:
| Not everyone uses EC2 which is prone to fall over.
|
| And the disciplined single dev documents their changes.
| That is why it works in a 1 man shop but not at scale,
| there is always someone who is unreliable once the group
| gets large enough.
| treis wrote:
| You definitely want "one click" deployments from the git go.
| Then it's just a small tiny step from that to your servers
| being cattle.
| dasil003 wrote:
| When you say "we" it sort of implies this was not a one-man
| operation.
| xmodem wrote:
| My take would be that once you need another environment than
| staging+prod, that's the time to move to at the very least
| move to containers, and probably think very hard about either
| a hosted Kubernetes or something like Fargate.
| Axsuul wrote:
| That's not to say you shouldn't use Kubernetes as a solo
| founder eventually. Kubernetes does a lot of the devops heavy
| lifting for you making your job as a solo founder much easier.
| mwcampbell wrote:
| Since you're using Python on the back end, which WSGI or ASGI
| server do you use?
| joshmn wrote:
| Serial one-man SaaS builder here with a pair of soft-landings and
| one big hit:
|
| I would agree with others who have opined that this is overkill.
| You couldn't pay me to use Terraform or Kubernetes for my SaaS
| unless it was a much larger team.
|
| My stack usually consists of this: A framework I am comfortable
| with that removes a lot of boilerplate (happens to be the one I
| know best in the language I know best), the database I know best,
| the memory store I know best, Turbolinks for load times, a theme
| from ThemeForest (with the commercial license), self-hosted
| analytics, Amplitude, and Heroku.
|
| The author mentions "lessons learned" regarding Clickhouse and
| Kubernetes. I'm not sure what their original goal was when
| starting their SaaS. Usually mine is financially motivated more
| than learning things.
|
| What I'm really saying is that just go with what you know best.
| Having to scale is a good problem to have. Pre-optimization is
| the root of all evil -- asking "is x the right stack for y?" will
| always be yes when you ask in the x subreddit.
|
| Stop thinking and build.
| csomar wrote:
| I agree about Kubernetes but not about Terraform. Terraform is
| easy to understand, and it's basically just declarative
| configuration. You have some Cloudflare records for your
| domain? You can put them in a file, wiki or declare them in
| Terraform. So maybe just use Terraform and get the benefit of
| free deployment?
| amzans wrote:
| Thanks for sharing your thoughts!
|
| To clarify, this has already helped me to ship features to my
| customers quickly. I actually spend little time working on the
| stack. Last time I touched the infrastructure components was
| probably a few weeks ago.
|
| Panelbear was originally built and launched in a weekend ($5/mo
| DO instance with SQLite), and I've been working on it for the
| past 3 months. I have been releasing a new feature every week.
| That is, in addition to my full-time job, so most of the time
| we're talking about 2 hours per day tops.
|
| I'd also like to clarify that I am not suggesting this stack
| should be used by other solo founder SaaS. I actually advice
| against it in my post :)
|
| I just wanted to share my stack, as it has worked really well
| in my case, and I thought it'd be interesting material for
| discussion.
| joshmn wrote:
| That's really great, happy to hear.
|
| I didn't mean to refute what you shared. In fact I was
| reinforcing some of your points. Doing things the cheap way
| is arguably the best way. Learning new tech while building is
| good, but I wouldn't recommend new tech to build a SaaS.
|
| My concern was copycats. Some starters reading your post may
| have this feeling that "because Panelbear did it with
| Clickhouse and Kubernetes and Django, that's the only way to
| do it." What it really should read is "because Panelbear used
| what he knew best, he was able to focus on getting customers;
| that's the only way to do it."
| amzans wrote:
| > used what he knew best, he was able to focus on getting
| customers
|
| That's what I was going for :) Now I realize that I should
| have highlighted that part more on the blog post.
| ecf wrote:
| Please, please, please listen to this person's advice about
| Terraform and the like.
|
| The last startup I was at hired a DevOps engineer to come in to
| completely containerize our simple Rails monolith at a time
| where they were just simply way too small to warrant it.
|
| Development velocity plummeted. Deploys started to take half an
| hour. Features weren't being released. The professionals our
| app was servicing lost trust in the engineering team.
|
| All in the name of checking off a box on the CTO's list of
| "things that Google does".
| slow_donkey wrote:
| Not sure what 'containerize' means in this context, but
| adding a Dockerfile, building the image and changing your box
| to use docker should definitely not reduce velocity or
| increase deploy time to half an hour...
| deckard1 wrote:
| it's never that simple.
|
| With docker you have to worry about how containers talk to
| each other. Which at a bare minimum means exposing ports
| and adding a network layer. Suddenly you find yourself in
| the weeds with docker-compose and debating whether or not
| it's actually suitable for a production environment, when
| they recommend using swarm instead. Then you find out swarm
| is on shaky ground and now you're hearing about nomad and
| ten different other solutions just to avoid k8s.
|
| Infrastructure-as-code is a wonderful idea. But the reality
| is it's a full time job. There will always be orphaned
| containers and things that need cleaned up and automated.
| And if you don't, then your environment will run out of
| space or RAM and all devs will be sitting there doing
| nothing.
|
| Building docker images also takes time, especially if you
| don't optimize the image. The simplest deploy workflow I've
| seen was a git hook (post-update, I think) that ran a few
| commands when the repo is updated. It'd really be hard to
| make up for the efficiency of that workflow after messing
| about with docker for days.
| dbmikus wrote:
| If it's a monolith you don't have to worry about
| composing multiple containers. I've put a monolith in
| Docker so I could plop it on Google Cloud Run.
| SmellTheGlove wrote:
| OOC what framework do you use?
|
| More broadly, can you help me with an opinion on my present
| struggle? Here goes:
|
| I have a lot of ideas, a couple of which solve problems for me
| and I think are even _good_ ideas. However, none have shipped
| because I'm spending an inordinate amount of time building out
| what is essentially my own SaaS template. Is it worth investing
| the time in doing that, or are some of the commercial SaaS
| templates out there (sjabloon, bullettrain, etc)
|
| I prefer Python/Flask, but I'm trying to learn Rails now, since
| a lot of the small saas ecosystem seems to exist there.
| joshmn wrote:
| I'm a Rails guy. I've been working with it for the last 10
| years and it (now) allows me to be hyper-productive. I've put
| other languages and frameworks into production but nothing
| allows me to focus like Rails does.
|
| There is a meaningful amount of boilerplate that remains for
| any stack if you're using it for a SaaS. It may not hurt to
| invest in a commercially-available solution that takes care
| of billing.
|
| For some products (super-hyper-MVP), I've gotten away with
| having a `companies` table with a `state` column which was
| either `active`, `inactive`, or `past_due`. I would update
| this manually from Stripe every day. When it became a chore
| (aka "I am spending an hour on this every day and my time is
| better spent elsewhere") I only then wrote code to handle it.
|
| There are solutions like Recurly or Chargebee that take a way
| a lot of pain on a platform basis. Those may be helpful in
| managing some of the complexities, but they come at a cost:
| financial, vendor-based, flexibility.
|
| It's important to keep in mind that your ultimate goal is to
| get customers validating your idea. While it's important that
| you conduct a meaningful transaction in exchange for solving
| their problem, that does not mean you need to handle every
| single last billing case.
|
| Accept their money, let your solution solve their problem,
| and repeat.
|
| If you want to talk more my email is in my profile.
| SmellTheGlove wrote:
| That's great insight and I really appreciate you taking the
| time to reply. I have it in my head that I need to get to a
| state where I have the boilerplate "done" - able to handle
| accounts, users (for areas where the two need to be 1:M or
| vv), admin, and basic subscription billing. I'm trying to
| get to the point where I have this thing, and each MVP is
| just an incremental build on top, but instead I have this
| half-baked thing and a lot of undelivered ideas. I suppose
| there are no shortcuts and I need to hammer at it, but as
| you said, not go nuts with handling edge cases.
| [deleted]
| wernst wrote:
| I'm working on a product to help developers quickly get
| started and manage their SaaS projects. If you have a moment
| I'd like to hear more about your experience. To quote the
| other commenter: "If you want to talk more my email is in my
| profile." :)
| ThePhysicist wrote:
| Seems it's another cookie-less, privacy-friendly Google Analytics
| alternative. This time from Germany!
|
| It's pretty cool that there's so much going on in this space, but
| is it really wise going into the market with seemingly the exact
| same features that Plausible, Simple Analytics, Fathom, etc.
| offer? Even Cloudflare recently entered the privacy-friendly
| analytics market with a free product, so it seems that market is
| getting really crowded. Then again, every (commercial) website
| probably needs such a solution, so maybe the market is big
| enough.
|
| I wonder though if these cookie-less solutions can give people
| the insights they need? You can do only very simple overall
| statistics and funnel analyses with this approach. Maybe that's
| enough for most websites though?
| amzans wrote:
| Thanks for the feedback.
|
| Yes, I understand I'm entering a crowded market, but Panelbear
| is still in the early stages, and I'm trying to understand what
| problems my customers have that I could solve / how much value
| can I bring to them.
|
| A crowded market also means more options for you as a customer.
| Specially when it comes to privacy-friendly tools, not only
| analytics, I'd argue that there's not enough options yet.
|
| I initially built it for myself, as I was not fully satisfied
| with the existing solutions. And I do intend to offer more
| features than what you currently see, but unfortunately my time
| is limited and it's going to take a while to bring Panelbear to
| the feature-level I'd like it to be :)
| [deleted]
| lnsp wrote:
| This seems like a pretty big stack for a single person to
| administrate - how much time do you spend on doing operations vs
| development?
| romanovcode wrote:
| Exactly, I was expecting something like React, Next.js,
| Firebase, Mailchimp. This list looks huge to manage as a solo
| developer.
| amzans wrote:
| Right now the operational effort is pretty minimal to be
| honest. I spend most of my time developing new features and
| talking my customers.
|
| I know it seems like a lot of tools, but most of them are set
| up once and forget. Except for the occasional round of
| dependency updates. But even for that I have automated
| dependency/container scanning to detect vulnerabilities, and
| get notified if updating an image is recommended.
|
| Most of the stack consists of "platform" tools, such as the
| ingress-nginx, external-dns, or cert-manager. So it's stuff I
| take with me for every project. It's like a personal Heroku
| I've been building, but way cheaper and fully customizable.
|
| I've been iterating on this stack over the years with various
| other projects, and also learned a lot from running Kubernetes
| in production at my full-time job, so it's not something I'd
| advise for someone who just wants to deploy their MVP for the
| first time.
| vbsteven wrote:
| Replace Python/Django with Java/Kotlin/SpringBoot and you
| pretty much have my preferred project stack, which also
| organically grew due to being exposed to these platform tools
| in my day job.
|
| Kubernetes/Terraform and friends are really useful as a solo-
| dev if, and only if you have the required experience with
| them.
| jrochkind1 wrote:
| What _would_ you advise for someone who doesn 't have the
| pre-existing k8 expertise etc?
|
| The ops environment still looks overwhelming to me, if
| there's a way to do it sustainably without a really heavy-
| weight ops infrastructure, I haven't figured it out. Like,
| something that to me requires like a full-time job just to do
| ops, although maybe not if you've spent some years learning
| the ops tools, but then same same.
| redisman wrote:
| I don't think diving into kubernetes makes any sense for a
| 1 person shop if you don't already know it. People love to
| evangelize about k8s more than your average tech but it's
| just one (IMHO overkill) way to do things. A better bet I
| think is to leverage tools from cloud providers. They
| specifically offer many different easy to use scaling
| platforms for a premium for small/not experienced teams.
| Heroku has been mentioned a bunch, something like Elastic
| Beanstalk on AWS is super easy for the first year or two of
| a company. Or just go for a single machine somewhere and
| worry about the 5% chance you need more than that when that
| happens.
| amzans wrote:
| Yes, this is what I would also recommend.
|
| You can get really far with the managed services from
| your cloud provider.
|
| If you're already familiar with Docker containers, just
| that already gives you plenty of options. I think every
| platform now provides a way to just run containers behind
| a load balancer with a few simple steps.
|
| Yes, maybe it's a form of vendor lock-in, but if your
| worry is acquiring customers, and growing a company,
| Kubernetes is probably not helping you in this case.
| Wheaties466 wrote:
| any chance you could expand on this?
|
| "I know it seems like a lot of tools, but most of them are
| set up once and forget. Except for the occasional round of
| dependency updates. But even for that I have automated
| dependency/container scanning to detect vulnerabilities, and
| get notified if updating an image is recommended."
| dobg24 wrote:
| PM for DO Kubernetes here. My views are biased.
|
| This is an insightful article. A learning for me was how the
| author managed to switch multiple cloud providers even while
| being a one man SAAS.
|
| Kubernetes is overwhelming because of 2 things: Overload of
| terminology, and Distributed systems day 2 operations.
|
| Author succeeds so well because he has a starter stack (install,
| CI pipeline, secure, monitor, scale) maintained as code, and it
| works every time.
|
| For someone starting new, the learning curve is high.
| Bootstrapping is easy, but day 2 on kubernetes is hard. Benefits
| outweigh is learning curve imho.
|
| Specific to DigitalOcean kubernetes API server issues, we have
| rolled out some resource provisioning improvements for newly
| created clusters very recently. Also making ongoing improvements
| to backend monitoring.
| amzans wrote:
| Thanks for the response! To clarify, I still a happy customer
| of DO, and would still use it for some other projects.
|
| I have also had a fair share of issues with AWS services in the
| past (Athena, they took care of it a few months later), and GCP
| too. And I understand that no product is ever perfect.
| smu wrote:
| Seems like there are a couple of tech stack posts on HN lately
| and I certainly enjoy reading them.
|
| But as a techie, the magic to me no longer lies in the product
| building, but in the 'finding the first 10-100' customers part.
|
| Have there been any posts on that lately?
| Wirerack wrote:
| I'd definitely appreciate seeing something like that too. After
| a couple of "build it first" failures I've come to see the
| wisdom in finding your customers and validating your idea
| first.
|
| I've read several of these SaaS walkthroughs and it invariably
| seems to follow this pattern:
|
| 1. Author has a blog with a large following on some topic.
|
| 2. Finds niche in that topic.
|
| 3. Makes a product and pushes it via their blog.
|
| 4. "Incredibly" their product gets tons of customers.
| amzans wrote:
| Going from 0 paying customers to 1 is really difficult.
| Specially if you're asking for a recurring subscription.
|
| Getting noticed is one of the hardest parts. Just having a
| great product is no longer enough.
|
| For every Basecamp, there are probably tens, or even hundreds
| of similar competitors.
|
| Can I name a few? Maybe.
|
| What about the top 10? Probably not, and that's exactly the
| problem.
| Retailer wrote:
| To get an idea off the ground, I use Google App Engine (GAE) with
| Python, Google's Datastore, Flask, Bootstrap. It works, doesn't
| cost much and removes a lot of complexity.
|
| GAE's offering of free (and auto-renewing) certificates also
| makes things cheaper.
| wenbin wrote:
| Awesome list!
|
| I haven't read comments yet, but I bet some people would
| criticize the tech stack as "too complex" or "not perfect" or
| "not even mention my favorite tech"...
|
| 1. Typically tech stack starts very simple, then evolve into
| something a bit more complex. It's normal.
|
| 2. If this tech stack is the author's most familiar tech stack
| and it gets jobs done, then it's a perfect tech stack for the
| author & the business. There's not a tech stack that works well
| for every developer, every company, every business...
|
| 3. Treat this tech stack as a data point. Find other data points
| on the internet. And you'll come up with your own "perfect tech
| stack", just for you, for your specific business.
| michaelbuckbee wrote:
| Important thing to keep in mind with this article is that this is
| for OPs data analytics SAAS where he's ingesting a mass amount of
| data, has different uptime requirements, etc than many other SAAS
| applications.
| atlgator wrote:
| I expected a lot less for "one man." Kudos to you OP.
| naicuoctavian wrote:
| That seems overkill. @levelsio ran his $1M business on "FTP"
| https://twitter.com/levelsio/status/1327451757975375874
| officialchicken wrote:
| I kinda wish the dogfood part was mentioned earlier... but sure
| glad I caught it at the end. An article on your analytics
| bootstrapping would be neat - how (did) you do analytics early?
| nojito wrote:
| The secret behind this stack is not its simplicity, but rather
| it's simply the stack they know the best.
| anonfunction wrote:
| Have you considered Amazon's SES for transactional email?
| ticmasta wrote:
| Just a single data point warning: I've had nothing but bad
| experiences with blacklisted, shared IPs from SES. Everything
| gets flagged as spam.
| brudgers wrote:
| How long did it take you to learn enough about all those
| technologies? How much of it was on the job?
| amzans wrote:
| Most of my learning was on the job, and in building some open-
| source projects that I have released over the years, for
| example: - https://github.com/anthonynsimon/bild -
| https://github.com/traduora/traduora
|
| I still have a lot to learn, but IMO nothing beats struggling
| with something for a long time, and pushing along until you're
| no longer terrible at it.
|
| I feel that most of what I know I learned by starting projects
| on topics I initially new nothing about, and sticking to it.
|
| Regarding on the job learning, I have been working with
| Python/Scala for my full-time job over the past 3.5 years, and
| that helped too. Specially in terms of running multi-regional
| services, and the challenges that come with that.
|
| We run several applications on Kubernetes using AWS (combined
| >2k req/s at peak time), and that was a big challenge for me
| from which I learned a lot. Specially when you're on-call, and
| one faulty node brings down the entire cluster, that fails over
| to another region and repeat :)
| amzans wrote:
| First of all, thank you all!
|
| Just the discussion on this post alone, is a goldmine for anyone
| trying to figure out what worked, and what not for others. This
| is why I love HN.
|
| To clarify a point about my article, I think everyone should do
| what works for them. Just because my unconventional stack for a
| solo founder works great for me, doesn't mean it will do the same
| for you.
|
| Your mileage may vary, and it all comes down to tradeoffs.
|
| Also, I'm sorry if I haven't been able to reply to each question,
| this post got way more attention than what I expected.
|
| But I'm happy to answer specific questions, feel free to ping me
| on Twitter: https://twitter.com/anthonynsimon
|
| Cheers!
| xyst wrote:
| Hi Anthony - do you have any concerns with your current
| employer (Stylights) trying to make an IP claim on your one man
| saas company?
| amzans wrote:
| They have been very supportive, and signed legally binding
| documents to allow me to work on this.
|
| Oh, yeah. We're also hiring :)
| robertlagrant wrote:
| Very, very similar to the tech stack we have in my engineering
| teams (other than we use Flask and SQLAlchemy instead of Django).
| Really like it. I've not heard of ClickHouse before, but that
| looks interesting. (If I had a requirement around time series, I
| was thinking of checking out Timescale -
| https://www.timescale.com.)
| zomgwat wrote:
| As a one-man team operating a 10+ year old SaaS product, I've
| done two things that have helped keep things sustainable. The
| frontend continues to be server generated. PJAX style partial
| page updates is (mostly) dynamic enough. The maintenance burden
| of operating a JavaScript frontend is too high to justify for a
| 1-2 person team.
|
| The second thing I've done is avoid containers. VMs work fine for
| many types of applications. That's especially true if
| provisioning and configuration is mostly automated. A product
| like Google Cloud Run looks interesting for a few low-volume
| backend services that I operate. Containers are a good fit there
| because it simplifies operations rather than increases
| complexity. The core infrastructure will remain VMs for the
| foreseeable future.
|
| I began doing Ruby and Ruby on Rails (RoR) development in 2006.
| Ruby had been around for awhile but the growing popularity of RoR
| was driving a lot of changes in the ecosystem in those years. It
| was a fun time but I was working for a large company that allowed
| me the time to keep up with everything. I see today's frontend
| and container ecosystems in the light of that experience. I'm now
| more content to wait it out and let the dust settle as much as I
| enjoy learning new technology.
| herodoturtle wrote:
| I'm glad you shared this. I've been reading the comments here
| with much interest but simultaneously also a sense of impostor
| syndrome, for I've been running my one-man SaaS on generic LAMP
| since 2005, and aside from adopting jQuery early on, I haven't
| much touched any other piece of exciting tech that's come out
| since.
|
| My old and boring stack works just fine on the VMs that it runs
| on, and and continues to support me and my family financially
| with little to no downtime and decent work/life balance.
|
| Of course I'm aware of the cons of programming in PHP versus
| other languages, but after 20 years of coding in it, I like to
| think that my code isn't all that bad.
|
| Still, I'm reading some comments here and feel like I'm waaay
| behind the tech curve with my use of such an old stack, and am
| somewhat scared to admit it.
|
| Your comment brought me relief :)
| ticmasta wrote:
| You didn't seem to get much of a reaction, probably because of
| your recommendations to go with proven (read: old & boring)
| tech, but I appreciate it. Front-end churn is real and, coupled
| with rapidly evolving and ever-abstracting containerization
| approaches, staying on top of it is a full-time job, best done
| as an employee.
| arcturus17 wrote:
| FWIW, I disagree with GP. I'm more productive in React than
| in SSR, and I'm much better at code design and architecture
| with it. React is pretty much old and boring by now.
|
| Just build in what you know.
| zomgwat wrote:
| > _Just build in what you know._
|
| Yup, I agree.
|
| The apparent difference in our situations is that you know
| React and everything that comes with it. It seems like
| that'd be a good choice for you.
|
| I'm not proficient in any of the currently popular frontend
| architectures. Gaining that proficiency and moving a 10+
| year old product to a SPA type architecture would be a
| massive investment. I enjoy learning new things and pushing
| things forward but I can't justify that investment when it
| comes to the frontend. Instead, I invest in other areas to
| move forward in.
| zomgwat wrote:
| Thanks!
|
| Best done as an employee is spot on.
| revskill wrote:
| To me, the biggest headache of one-man SaaS is that you have to
| write API by code.
|
| I always use API-generation code for my products. The real value
| i bring to customers is my database, not API.
| davidsawyer wrote:
| What tools do you use for that?
___________________________________________________________________
(page generated 2020-11-23 23:00 UTC)