5 ms·
I think the "local maximum" we've gotten stuck at for application hosting is having a docker container as the canonical environment/deliverable, and injecting s
by aeldidi 1y ago
I think the "local maximum" we've gotten stuck at for application hosting is having a docker container as the canonical environment/deliverable, and injecting secrets when needed. That makes it easy to run and test locally, but still provides most of the benefits I think (infrastructure-as-code setups, reproducibility, etc). Serverless goes a little too far for most applications (in my opinion), but I have to admit some apps work really well under that model. There's a nearly endless number of simple/trivial utilities which wouldn't really gain anything from having their own infrastructure and would work just fine in a shared or on-demand hosting environment, and a massively scaled stateless service would thrive under a serverless environment much more than it would on a traditional server.
That's not to say that I think serverless is somehow only for simple or trivial use cases though, only that there's an impedance mismatch between the "classic web app" model, and what these platforms provide.
- daitangio 1y agoYou are ready for misterio: https://github.com/daitangio/misterio https://github.com/daitangio/misterio A tiny layer around stareless docker cluster. I created it for my homelab and it gone wild
- aeldidi 1y agoThat's really interesting, I might actually use that for mine too. Thanks for sharing.
- mattmanser 1y agoDocker is much like microservices. Appropriate for a subset of apps and yet touted as being 'the norm' when it shouldn't be. There are drawbacks to using docker, such as security patching and operational overhead. And if you're blindly putting it into every project, how are you mitigating the risks it introduces? Worse, the big reason it was useful, managing dependency hell, has largely been solved by making developers default to not installing dependencies globally. We don't really need Docker anywhere near like we used to, and yet it persists as the default, unassailable. Of course hosting companies must LOVE it, docker containers must increase their margins by 10% at least! Someone else down thread has mentioned a tooling fetish, I feel Docker is part of that fetish.
- dalberto 1y agoHard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.
- andersmurphy 1y agoDepends on the language. Java or Go you really don't need docker.
- aeldidi 1y agoThere's some truth to this too honestly. At $JOB we prototyped one of our projects in Rust to evaluate the language for use, and only started using Docker once we chose to move to .NET, since the Rust deployment story was so seamless.
- dalberto 1y agoHaven't deployed production Java in years, so I won't speak to it. However, even with Go's static binaries, I'd like to leverage the same build and deploy process as other stacks. With Docker a Go service is no different than a Python service. With Docker, I use the same build tool, instrument health checks similarly, etc. Standardization is major. Every major cloud has one (and often several) container orchestration services, so standardization naturally leads to portability. No lock-in. From my local to the cloud.
- mattmanser 1y agoWhat are you isolating it from? Everything runs on it's own box these days anyway.
- aeldidi 1y agoYeah that's becoming increasingly true. I guess it really depends on what your setup is.