21–30 of 30 posts
You could get away with copying artifacts over ssh for a while.
Deployments could still be via Github actions or any other CI/CD tool or even scp.
I have also helped to remove K8s from companies that were experiencing painful points with it, these companies are know very happy with plain-old VMs where their apps just work with minimal maintenance.
I personally choose simple deployment scripts for static webapps, this example works like a charm and runs in under 10 seconds:
- `npm run build && scp page.zip webserver:~/ && ssh webserver "unzip -o page.zip -d /var/www/html/"`
In other more complex projects, I tend to go with ansible, I have 5 year old scripts that still work, I do a few tweaks per year.
A customer uses a similar approach with shell scripts executed as CI/CD by AWS CodePipeline.
Related to the tech stack, nginx is my favorite reverse proxy, I know, everyone talks about Caddy but having used nginx for years, I rarely hit anything I don't know how to handle, and, the community has already posted answers for most common nginx use cases.
OP, is your only experience working with technology companies and trendy startups trying to hit some mega-million valuation? The real world is a lot more messy than the best practices that tech companies come up with. Go work for some local warehouse or AC repair company's IT departments. They might have some technology for managing inventory or scheduling appointments or billing or any one of a hundred tasks that is…
I've been in the industry for 20+ years. My opinion is that the extra complexity that comes from containarization is not necessary at many of the early startups. The benefits are not needed and the costs are hard to see but non-trivial. The companies I worked with either were slowly moving towards containarization, or were already there before I joined. I always thought that it is premature. My pet projects never use…
Now having written that the CD part does come with eye rolling ... i think of last emplyor which seemed to go out of is way to make prod changes small as possible, unorchestrated, paternalistic. Dev installs looked rather different than beta or prod so there was no incentive to improve. And that was fine with management.
Ultimately I think management didn't trust devs. So rather than process improvement it was better to go slow, beurceatric, make devs get approvals as implicit disincentive to change. In their mind devs were qino (quality in name only). Tls and middle managers did QA by approving or rejecting tickets.
Usually good companies think quality is everybody's problem and empower + train accordingly. And nobody serious about quality thinks QAing tickets is quality. No, it spends resources only. That's the only thing 100.0% of all people can agree on when it comes to inspecting quality into CD.
I'm fine with prod approvals but not for blow-by-blow changes
My current employer has far far stringent rollout requirements so elastic scaling et al isn't in scope. It's very planned, determative.
SMEs in particular usually never use Docker or lxc or any other container because usually it's an overengineered approach to a simple php website.
However if you want to develop for these kind of things I found golang to be my trustworthy companion because bundling all assets with go:embed is easy as pie.
I usually just have a self contained binary deployed to those systems and +net capability on the binary and it works.
There are a bunch of hosting providers that try to fix this, though, and focus on "quick respawns" of containers for php web apps. They are rare though. Usually they try to run a two clouds strategy where there is a backup cluster that can be setup quickly when there's a flood of DDoS in either one.
What I also wanted to leave here is this: Every nginx, every ip translation table, every load balancer, every VM will cost you a lot of throughput.
Usually a load balancer is the lazy coder's cache alternative, instead of just making their assets static in the first place. Starts with the webpack bundles and ends somewhere down the HTTP ETags and Pragma headers.
Also in regards to efficiency: check out eBPF, it's definitely worth it. The sheer scale of what eBPF and XDP can do in terms of network requests is absurd to say the least.
OP, is your only experience working with technology companies and trendy startups trying to hit some mega-million valuation? The real world is a lot more messy than the best practices that tech companies come up with. Go work for some local warehouse or AC repair company's IT departments. They might have some technology for managing inventory or scheduling appointments or billing or any one of a hundred tasks that is…
Finance is my domain ... worked/working for large established companies ... no containers or k8s. Yes, there's some presence for R&D or maybe external web or external search but absolutely nothing in front, middle, back office or connections to brokers, exchanges ie. where it's serious. Now having written that the CD part does come with eye rolling ... i think of last emplyor which seemed to go out of is way to make…
I'm at banking and we use containers heavily, they are not just for scaling but also for ease of deployment. We still need approvals for changes in production, but the main reason for being strict with them is legal and less beurceatric.
What did you mean by blow-by-blow?
The basic usage is pretty simple and straightforward.