101–110 of 259 posts
GAE's offering of free (and auto-renewing) certificates also makes things cheaper.
Earlier quoted context omitted.
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).
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.
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.
Earlier quoted context omitted.
I'd actually suggest PostgreSQL + Hasura + React with Ant Design or Material UI
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.
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.
Earlier quoted context omitted.
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…
> 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…
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?
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 feedin…
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 fea…
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.
Earlier quoted context omitted.
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!
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 pl…
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 feedin…
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 databas…
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 i…
Earlier quoted context omitted.
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…
> 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…
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.