by ksahin on 4/8/21, 12:14 PM with 320 comments
by rory on 4/8/21, 1:33 PM
- Static frontend hosted on Netlify (free unlimited scale)
- Backend server on Google App Engine (connecting to Gcloud storage and managed DB via magic)
I realize I'm opening myself up to vendor lock-in and increased costs down the road (if I even get that far), but I've wrangled enough Docker/k8s/Ingress setups in the past to know it's just not worth the time and effort for a non-master.
by anonymouse008 on 4/8/21, 1:34 PM
I was feeling a bit down on my projects, but this has me amped up seeing how the ultimate goal of working on features rather than deployment is possible, and very real!
Best of luck with Panelbear!
by sa1 on 4/8/21, 2:36 PM
But it's worth realising that one purpose of code organisation in larger companies is to mirror the team organisation. That's a constraint on code that can interfere with the best technical architecture.
You can do better with a monolith in a one-man team!
by wmichelin on 4/8/21, 1:08 PM
by wakatime on 4/8/21, 4:41 PM
* Flask + Flask-Login + Flask-SQLAlchemy [1]
* uWSGI app servers [2]
* Nginx web servers [3]
* Dramatiq/Celery with RabbitMQ for background tasks
* Combination of Postgres, S3, and DigitalOcean Spaces for storing customer data [4]
* SSDB (disk-based Redis) for caching, global locks, rate limiting, queues and counters used in application logic, etc [5]
I like how OP shows the service providers he uses, and why he decides not to self-host those parts of his infra. Also, there's a large up front cost involved for any stack (Rails, Django, k8s). I'd be interested in a more detailed writeup with configs, to try out OP's auto-scaling setup. My configs are linked in the gist below [2] for my non-auto-scaling Flask setup.
I spend about $4,000/mo on infra costs. S3 is $400/mo, Mailgun $600/mo, and DigitalOcean is $3,000/mo. Our scale/server load might be different, but I'm still interested in what the costs would be with your setup.
[1] https://wakatime.com/blog/33-flask-part-2-building-a-restful...
[2] https://gist.github.com/alanhamlett/ac34e683efec731990a75ab6...
[3] https://wakatime.com/blog/23-how-to-scale-ssl-with-haproxy-a...
[4] https://wakatime.com/blog/46-latency-of-digitalocean-spaces-...
[5] https://wakatime.com/blog/45-using-a-diskbased-redis-clone-t...
by hardwaresofton on 4/8/21, 2:59 PM
The "point" of Kubernetes is to drop the difficulty of building a service like Cloud Run to zero. It drops the cost of building a Heroku down to zero. I'd bet my bottom dollar that fly.io and render are running on Kubernetes (maybe they mentioned it somewhere already and I just missed it). With the right cluster set up, building one of those platforms (or others that I won't mention) is almost as simple as setting up stripe checkout and writing a web interface to turn form fields into JSON fields and send them to a kubernetes cluster (possibly with hard multi-tenancy! not to get too into it, but you can literally provision kubernetes clusters from kubernetes clusters, ephemeral or otherwise).
No other tool in the devops world except for maybe the initial orchestrator wave (ansible/puppet/salt/chef) has been this much of a force multiplier. Ok, maybe that's hyperbole, but if adhoc-bash-scripts->ansible is 1->2, Ansible->Kubernetes is similarly 1->2, especially if you consider baked in cloud provider support/innovation.
But here's the secret -- perversely, I'm happy deep down that everyone thinks k8s is too complicated/is a buzzword/isn't worth the effort. All it means to me is that I'm still ahead of the curve.
by ernsheong on 4/8/21, 3:10 PM
- Cloud Run (serverless containers)
- Cloud SQL (via proxy)
- Cloud Monitoring & Logging (formerly Stackdriver)
- Compute Engine (if necessary, e.g. websockets)
- Cloud Build for GitOps (deploy on push)
It's clean and simple (to me). Billing is in one place, nicely separated by projects. Monitoring & Logging is already built in. No need to span multiple dev SaaS tools. So far managed to avoid Redis caching because Golang + Postgres is fast enough, so far. But if you need Redis you can DIY on Compute Engine or try Cloud Memorystore (configure the memory to a low amount for cost savings).
Google Cloud drawbacks: Additional charges necessary to connect Cloud Run to VPC (via proxy instances). Load balancing on GCP ain't cheap ($18/month, though to a larger enterprise that is a rounding error). But in my setup I didn't need these things.
As shown above, I have heavily optimized for cost and simplicity in my setup.
by biztos on 4/8/21, 5:05 PM
If you have a one-person SaaS company, how do you get past customers’ resistance to a single point of failure, namely you?
Do you pretend you’re not just one person? Do you only have customers who could handle losing the service when you, say, run away to meditate on the mountaintop? (Or get run over by a beer truck, or whatever.) Is there some non-obvious solution?
And — back on topic — is the architecture part of that sales pitch? “I’m just one dude, but look how simple this is, it can run itself if I am devoured by mice!”
by tptacek on 4/9/21, 12:01 AM
A suggestion, hopefully helpful: a better approach to securing your admin console than simply layering 2FA onto it would be to expose it to a private WireGuard network. One very easy way to do that is with Tailscale, which will hook up to your GSuite authentication --- Google's 2FA stack will be far better than anything you'd likely build on your own.
Tailscale is disgustingly simple to set up. If you're a product person, it's actually upsetting how easy they've made it to get set up.
by michaelbuckbee on 4/8/21, 1:57 PM
That's not to take anything away from the excellent writeup, but more so that someone who is thinking about starting a SaaS maybe doesn't jump to the conclusion of "I should go learn Kubernetes".
by _gjrn on 4/8/21, 1:23 PM
by yalogin on 4/8/21, 4:02 PM
by efortis on 4/8/21, 4:33 PM
There are two Servers load balanced with DNS.
Each Server has 3 jails (Nginx, App, DB) and 2 NICs
The internal NIC is for replicating the DB, and for the App Servers to target the Primary one.
Diagram and Configs: https://blog.uidrafter.com/engineering/freebsd-jails-network...
by dimeatree on 4/8/21, 1:54 PM
In my situation I am finding the lack of consistent environment a reoccuring issue, the developer environment does not match production. However I kept it simple with Google App Engine Standard and Flex environments, I found the deployment process simple and was enough for me (at the time) - however I am finding we are going to step into dockerland; however I feel like it is very over my head!
by rufusroflpunch on 4/8/21, 1:13 PM
by bellttyler on 4/12/21, 3:22 PM
For our frontend we used Webflow. My friend was able to create the entire marketting site, and all the app UI's without needing help from me. Webflow is an awesome tool for that sort of thing.
For the backend, I built a simple Node/Express API and hosted via Heroku.
To this day, everything is still running fine and the API is processing roughly 200 million requests a month. The total cost to host that on heroku is $50/mo.
You can definitely have a simple stack but have it be highly scaleable!
by ijustwanttovote on 4/8/21, 3:35 PM
Another good read is Wenbin from Listen notes. https://www.listennotes.com/blog/how-i-accidentally-built-a-...
by eandre on 4/8/21, 1:02 PM
by 0xdba on 4/8/21, 1:41 PM
And since it hasn't taken off (and probably won't ever), it just costs me a pennies a month since I'm under their free limits, plus the domain.
by say_it_as_it_is on 4/8/21, 1:21 PM
Regarding the rate limiting, you're load balancing into nginx services that you've configured to limit requests. Are they synchronizing rate limiting state? I can't seem to find nginx documentation supporting this. What value is there in this style of rate limiting, considering User X can send a sequence of requests into a load balancer that routes them to nginx boxes A, B, and C? The big picture that 3 requests were processed for user X gets lost. Your endpoint-level rate limiting, however, may potentially be achieving the synchronized rates if the redis servers in a cluster are synchronizing. I guess I'm asking about the strategy of using multiple lines of rate limiting defense. Is nginx-level rate limiting primarily for denial of service?
The horizontal autoscaler should be based on throughput rather than hardware consumption, shouldn't it? If the req/sec goes below a threshold, spawn a new service. Can anyone comment?
by chrisandchris on 4/8/21, 1:00 PM
That is the closes thing to a number of requests I could find. So this architecture, no matter how solid, is somewhere between „way to large“ and „matches perfect“.
It seems like a solid breakdown on how to deploy your services to k8s and how to properly do CD deployments. But it does never mention whether it actually makes sense at the scale he actually has.
by rajatsx on 4/8/21, 5:57 PM
- A single VPS server to host the app. I love DigitalOcean.
- A single docker-compose file to bring up the entire stack containing the front-end, the back-end and the database.
- Caddy for automatic SSL certificates and proxying.
- JavaScript/TypeScript for building stuff.
- Cloudflare For DNS
by tluyben2 on 4/8/21, 4:45 PM
by Sodman on 4/8/21, 2:27 PM
by dpweb on 4/8/21, 8:00 PM
by pier25 on 4/8/21, 3:20 PM
What about taxes and invoices to other countries?
by throwaway78123 on 4/8/21, 1:45 PM
It turns out Kubernetes is actually perfect for small teams as it solves many hard operational issues, allowing you to focus on the important part of the stack: the application.
The key is to stick to a simple setup (try not to mess with networking config) and use a managed offering such as GKE. We may need a Kubernetes, The Good Parts guide.
by eruci on 4/8/21, 2:28 PM
by singhrac on 4/8/21, 8:14 PM
by igammarays on 4/8/21, 2:55 PM
by anurag on 4/8/21, 4:40 PM
* Automatic DNS, SSL, and Load Balancing
* Automated rollouts and rollbacks
* Health checks and zero downtime deploys (let it crash)
* Horizontal autoscaling (in early access!)
* Application data caching (one-click ClickHouse and Redis)
* Built-in cron jobs
* Zero-config secrets and environment variable management
* Managed PostgreSQL
* DNS-based service discovery with private networking
* Infrastructure-as-Code
* Native logging and monitoring and 3rd-party integrations (LogDNA, Datadog, more coming this month!)
* Slack notifications
More at https://render.com.
by throwaway823882 on 4/8/21, 1:08 PM
by staticelf on 4/8/21, 2:51 PM
As the author say, he already got a lot of experience of it so it worked out great for him but it is probably easier just to install the tech needed for a small company.
Unless you have something very special going on, the dependencies (like databases) are probably not going to be that many.
by alexellisuk on 4/9/21, 8:15 AM
This tech stack looks over-engineered upon first glance, but I don't know much about the author or his product.
I use Kubernetes a fair bit whilst developing OpenFaaS and teaching people about K3s, but there is a whole world of development teams who aren't prepared to consider it as an option. One of the reasons we created "faasd" [2] (single-node OpenFaaS) was to help people who just wanted to run some code, but didn't want to take "Kubernetes mastery 101"
For a small app using a managed service like Cloud Run plus some cloud storage should get you very far. I saw that Heroku is still popular with the indie community, with the author of Bannerbear getting a lot of value from the managed platform.
[1] https://thebootstrappedfounder.com/ [2] https://github.com/openfaas/faasd
by aaronbrethorst on 4/8/21, 3:34 PM
It’s a Rails monolith deployed on Heroku.
I’d rather have the time to build new features for my user base than spend it learning how to use k8s or wrangling AWS through its abysmal console website.
by reubens on 4/8/21, 8:40 PM
by dimitrios1 on 4/8/21, 7:33 PM
I am not sure what the right answer is, but I at least appreciate that there founders out there willing to give the little-er shops a chance. A healthy ecosystem with competition is good for the most amount of people.
by omarhaneef on 4/8/21, 1:57 PM
Ideally, you would get it to the point where a newbie can use it as a reference.
by nicioan on 4/12/21, 7:38 AM
by plnii on 4/14/21, 11:43 PM
by albertTJames on 4/8/21, 7:22 PM
by kparaju on 4/8/21, 4:17 PM
by ilovefood on 4/8/21, 2:32 PM
by de6u99er on 4/8/21, 12:54 PM
I'm just wondering why you don't also run your managed services in k8s?
by peter_d_sherman on 4/9/21, 4:13 AM
>"Web Performance and Traffic Insights
From the small stuff to the big picture, Panelbear gives you the insights you need while respecting the privacy of your visitors. It's simple, and fast."
Price is based on client websites' page views per month, with free tier to 5K page views.
by knodi on 4/8/21, 2:22 PM
by cadbox1 on 4/8/21, 11:33 PM
by ccmcarey on 4/8/21, 2:06 PM
How do you handle database migrations when using an otherwise automated CI/CD flow with gradual deployment?
by mikestaub on 4/9/21, 8:05 AM
by lmarcos on 4/8/21, 2:46 PM
by chpmrc on 4/8/21, 7:33 PM
by system2 on 4/9/21, 8:11 PM
by urashidmalik on 4/8/21, 2:39 PM
by undeadsushi on 4/8/21, 3:00 PM
by lemarchr on 4/8/21, 9:28 PM
by nodamage on 4/8/21, 8:45 PM
by sillycube on 4/8/21, 2:54 PM
Kubernetes is too complicated for me
by yumraj on 4/8/21, 4:57 PM
by mjgs on 4/9/21, 12:34 AM
by nickthemagicman on 4/8/21, 10:41 PM
by umen on 4/9/21, 5:44 AM
by msmagh on 4/9/21, 3:06 AM
by siruva07 on 4/8/21, 1:20 PM
by btbuildem on 4/8/21, 2:44 PM
by wenbin on 4/8/21, 3:42 PM
by mrwnmonm on 4/8/21, 2:50 PM
by dikaio on 4/8/21, 6:41 PM
by eweise on 4/8/21, 6:13 PM
by ThePhysicist on 4/8/21, 12:54 PM
Edit: Maybe the downvoters can explain what they're disagreeing with?
by riantogo on 4/8/21, 6:40 PM
-Inmotion shared hosting (some $10/mo fixed)
-PHP (codeigniter framework) with MySQL
Not very proud in the age of Cloud, but I can’t deal with all the complexities. Command line scares me (which seems to be the requirement these days for any development). Now I have a simple ftp folder mapped directly in VS Code.
by 1hakr on 4/8/21, 3:31 PM