https://gitlab.com/stavros/harbormaster
As far as PaaSes go, it's probably the simplest, and works really well.
Ha! I'm store my data in /data for ages. The only difference is what at first I bothered with tinkering with datadir paths in configuration files, nowadays I just symlink /var/lib/whatsitsname to /data/whatsitsname. I'm lazy and boring.
It's basically a oneliner in bash. KISS
- builds and dependency management, all in one
- works “the same” on my laptop and server
- there’s an easy way to reset services when they break
Containers... just work? Actually, Docker just works. It is rock solid and I'm very delighted I learnt so much of it.
The only thing I'm missing about Docker is a bigger focus on on-the-fly image editing. Like, I love to have these container development environments. I'd love to give some command inside the container and make it magically appear on the Dockerfile if it was successfully executed, so I don't have to manually copy things over when I want to have reproducibility for later.
Still sounds like over-engineering to me. It's trivial to make systemd supervise a service and automatically restart it on failure.
Rootfs is the boring technology, their semantics is clear and most kernels have support for them.
Better: use systemd which has became truly boring and restarts your services automatically and if you don't like systems, plenty of alternatives such as s6 do exist.
Container with it is just a few files in etc and binary blob itself. Same with container-less deployment.
Even totally dodging docker/k8s/nomad/dagger or anything that's even remotely complicated platforms like AWS/DO/Fly.io/Render/Railway/etc obsolete this "simple" approach with nothing but a config file.
I also theorize that the author is likely wasting a boatload of money serving ~0 requests on the staging machine almost all the time, due to him literally switching a floating IP rather than using two distinctly specced machines for production and staging
One day you will be promoted to 'senior engineer' and revise this statement.
Software exists to solve problems. Adding more complexity has to serve a purpose. Just because you read somewhere that Netflix does their deployment in some way, doesn't mean that it's the right way for your environment.
The only thing I disagree with his approach is that they do "ssh <host> git pull". They should just "git push <host>" from their CI machine(or laptop since they have no CI/CD). No reason to allow access to code from the actual server and git is distributed.
They could surely turn off the non-active server but they might be using that for failover. In that case serving zero requests is totally fine.
Author is running gunicorn/flask/nginx, this is trivial for a buildpack and would take like 5-10 minutes tops to set up a robust build/deploy flow with any recent PaaS.
I don't know who needs to hear this, but you don't always need to start a project by reaching for the most complex tool possible. Build up to it and then you won't need convincing to use it.
How actual software delivery is done is a relative term to the systems/needs and the scale you have. You probably have not been in environments where build/deploy tools are over engineered to death, to the point where adjusting it one bit brings down the entire delivery to a halt. If you were able to set those up without such issues, kudos to you.
the sheer arrogance and ignorance of this comment is remarkable
That really smells of desperate developer that need to feel relevant just because they use the latest thing
Like, how the fuck it would be "simpler" if the deploy is literally just running a single script ?
Manual git pushes ensure the highest level of security and error avoidance.
I routinely find myself having to do one-off post-deployment things that would be a nightmare to try and script into the ci flow.
Which is absolutely insane for a website that serves 200 visitors per hour.
From: https://www.reddit.com/r/Python/comments/xobba8/comment/iq05...
How do you deploy a schema that serves both old and new versions? Anyone got any resources on this?
Or until it's been disabled by feature flags.
Dealing with the details of things like SSR vs client side, Apollo caching (cuz w/ Next you are _probably gonna go w/ GQL, and so you probably use Apollo), and monitoring/observability in the Next/Vercel world is hard. You don't have these problems with a simple monolith, and you can sprinkle in your front end magic with whatever lean JS approach you want as you need it.
And to be fair Vercel has some logging and datadog integration, but it is very limited compared to what you can get and can configure as-needed with real agent based monitoring.
I'm increasingly feeling like the 'benefits' of server-side rendering in all its flavors for the big JS frameworks are just a boondoggle and not worth the complexity and cost for _most_ apps, even ones where the cost of an SPA are worth it.
- GQL: the only case where I'd use GQL is where he would likely want to too: building native mobile apps. Otherwise, I'd use tRPC and have fullstack type safety. This is included in my 5 minute estimate because I'd use create t3 app, which has this configured out of the box https://trpc.io/ https://github.com/t3-oss/create-t3-app
- monitoring/observability: not quite sure what you mean, but it's only a few clicks in vercel to have a logdrain or metric drain and configure alerts and dashboards in your tool of choice. And if I wanted to roll the whole thing myself... that's what he did. Rolled it all custom by hand. The difference is I have the option of not reinventing the wheel.
At the end of the day I can get into composing a docker image that is configured just like his prod servers if I need that access, and there's likely already a docker image pre-done that has 99% of what I need, including metrics/monitoring. At which point I could launch my service on any number of hosts that allow direct pushing of built docker images, if my build process goes there.
To each their own, but I think my solution requires far less time to setup and maintain, but costs more, as I said. Manually engineering each system yourself might be fun to you, but it's not to me.
For a basic CRUD app, especially for a solo dev, the monitoring story on Vercel is sufficient and it’s hard to say that their single repo push to deploy setup is more complex than the traditional alternatives.
At large companies, the calculations are different. Even when monoliths would be the best fit, they may still carve out microservices. How else would they be able to ship their org chart? :)
With PHP you just FTP copy a file to the server and it works instantly, no builds, no compilation, no restarts. Compared to Node.js the server feels a lot more robust by default and an uncaught exception doesn't bring down the whole server until restarted.
The biggest plus: you can host a lot of applications on the same stack and by default ALL parts of the stack (Apache, MySQL, PHP) can handle concurrency and load distribution well (with Node.js, for example, by default each application will be mostly single-threaded, you have to manually spawn multiple Node.js instances/workers for it to properly use all the server resources).
Nothing bad with that, thought, and part of its genius is how simple it is.
This also gives you a bit more resilience, if the app on node dies (out of memory/disk/bug/whatever), the proxy will just send the traffic to the other node without having to wait for DNS to switch
> I’ve already mentioned my 2 application servers. But the magic thing that makes it all possible is a floating IP address from DigitalOcean.
To the user nothing changes, including IP.
Everything is recorded in the database and a few pgcron jobs aggregate the data for analytics and reporting purposes every few minutes.
As someone who isn't a programmer (mechanical engineer) but has some programming ability, the idea of designing something like the article author did and sharing it with the world intrigues me.
How much does a setup like you described cost per month? (Or per x/number of users, not sure how pricing works in this realm)
The parent, however, is paying a lot more for a t2.large.
For that kind of money you could almost get a dedicated machine which would be 10x more powerful than a T2.large, but with the hassle of maintenance (though it's not a lot of hassle in reality).
The advantage of AWS is not price. AWS is quite a bit more expensive if you want the same performance. It's either that you can scale up and down on demand, or the built-in maintenance or deployment pipelines.
So you can save money if you have bursty traffic, or save dev time because it's super easy to deploy (well, once you learn how).
Cloud platforms can also have weird limits and gotchas you can accidently hit, like your DB can suddenly start going slowly because you've got a temporary heavy CPU query running, as they don't actually give you very much CPU with the cheaper stuff.
I have the exact same number of visits and run the site with a boring PHP/MySQL setup from a cheap but very reliable 200€/y shared hoster. Deployment via git over ssh as well.
My current boring system for a simple Rails app (https://getbirdfeeder.com) is that I push to GitLab, the CI builds a docker image and does the ssh & docker-compose up -d dance. That way I can deploy / roll back from anywhere even without my computer as long as I can log into GitLab (and maybe even fix things with their web editor). Seems a lot "more boring" to me and having the deploy procedore codified in a .gitlab-ci.yml acts as documentation too.
In small teams it's bad because it's a waste of time. In large teams it's bad because it creates communication overhead (it's also a waste of time but that can be often absorbed if things don't get too crazy). For a single person team it is bad because now they have to depend on their memory and shell history.
There is this thing called shell scripts.
Really nice being able to open up GitHub and manually kick off a deploy -- or have it deploy automatically.
I run something similar on personal site and it's literally just 2 identical configs but with different port/directory and some haproxy config.
(either a copy of production or directly connecting to production instance)
It's true about the hardware, but if you use a container it can run on the exact same software.
This blue-green deployment workflow reminds me of a similar setup used by the creator of SongRender[1], which I found about via the running in production podcast[2]. One thing to be aware of with smaller VPS providers like Linode, DO, and Vultr is that they charge per hour rather than per second. So if you boot up a new VM every time you deploy you're charged for a full hour each time.
[1] https://jake.nyc/words/bluegreen-deploys-and-immutable-infra...
[2] https://runninginproduction.com/podcast/83-songrender-lets-y...
To save your time, use the simplest thing you know how to use. Whatever you can set up easily and gets you serving a hello world on the internet.
To save compute, just don't do stupid things. In particular, you should consider what happens if this project isn't a runaway success. One day, you might want to leave it running in 'maintenance mode' with just a few thousand users. For that, you'd prefer to be running on a $10/month VPS than a $2000/month cloud setup which is going to require constant migrations etc.
Things like automatic failover and loadbalancing are seldom required for 1-man shows - the failure rate of the cloud providers hardware will be much lower than your own failure rate because you screwed up or were unavailable for some reason.
Been using it for our API backends for about ten years.
Computers are fast.
I do miss infra as code mentioned. If shit goes tits up with the infrastructure and everything was setup with clicking around in control panels, ad-hoc commands and maybe a couple of scripts, your recovery time will be orders of magnitude bigger than it has to be.
But who are we to judge, impressive to earn 2,5k every month with it, kudos.
