6 ms·
> I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or
by rcv 1y ago
> I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues.
Sounds great if you're only running a single web server or whatever. My team builds a fairly complex system that's comprised of ~45 unique services. Those services are managed by different teams with slightly different language/library/etc needs and preferences. Before we containerized everything it was a nightmare keeping everything in sync and making sure different teams didn't step on each others dependencies. Some languages have good tooling to help here (e.g. Python virtual environments) but it's not so great if two services require a different version of Boost.
With Docker, each team is just responsible for making sure their own containers build and run. Use whatever you need to get your job done. Our containers get built in CI, so there is basically a zero percent chance I'll come in in the morning and not be able to run the latest head of develop because someone else's dev machine is slightly different from mine. And if it runs on my machine, I have very good confidence it will run on production.
- const_cast 1y ago[flagged]
- Bnjoroge 1y agowhat they described is a fairly common set up in damn near most enterprises
- nazgul17 1y agoBoth can be true
- sroerick 1y agoWherefore art thou IBM
- fulafel 1y agoEnterprises are frequently antipattern zoos. If you have many teams you can use the modular monolith pattern instead of microservices, that way you have the separation but not the distributed system.
- const_cast 1y agoYeah most enterprise software barely works and is an absolute maintenance nightmare because they're sprawling distrivuted systems. Ask yourself: how does an enterprise with 1000 engineers manage to push a feature out 1000x slower than two dudes in a garage? Well, processes, but also architecture. Distributed systems slow down your development velocity by many orders of magnitude, because they create extremely fragile systems and maintenance becomes extremely high risk. We're all just so used to the fragility and risk we might think it's normal. But no, it's really not, it's just bad. Don't do that.
- latentsea 1y agoI like how you didn't even ask for any context that would help you evaluate whether or not their chosen architecture is actually suitable for their environment before just blurting out advice that may or may not be applicable (though you would have no idea, not having enquired).
- const_cast 1y agoMuch like parallel programming, distributed systems have a very small window of requirement. Really less than 1% of systems need to be distributed. Are you Google? No? Then you probably don't need it. The rest is just for fun. Or, well, pain. Usually pain.
- latentsea 1y agoI like how you didn't even enquire as to what size organisation they worked in order to determine if it might actually be applicable in their case.
- const_cast 1y agoI never said it was applicable to them, in fact I said the opposite: > Obviously that ship has sailed for you, but I mean in the general sense. In the general sense, no, you don't need a distributed system. Even if you have billions of dollars worth of revenue - no, you don't need a distributed system. I know, because I've worked on monoliths that service hundreds of thousands of users and generate billions in revenue. If you're making YouTube, maybe you need a distributed system. Are you making YouTube? Probably not. You can, of course, choose to make a distributed system anyway. If you want to decrease your development velocity 1000x and introduce unbelievable amounts of complexity and risk.
- latentsea 1y agoWe're there at least 1000 engineers working on that system you worked on?
- sroerick 1y agoOK, this seems like an absolutely valid use case. Big enterprise microservice architecture, I get it. If you have islands of dev teams, and a dedicated CI/CD dev ops team, then this makes more sense. But this puts you in a league with some pretty advanced deployment tools, like high level K8, Ansible, cloud orchestration work, and nobody thinks those tools are really that appropriate for the majority of devteams. People are out here using docker for like... make install.
- AlphaSite 1y agoHaving a reproducible dev environment is great when everyone’s laptop is different and may be running different OSes, libraries, runtimes, etc. Also docker has the network effect. If there was a good light weight tool that was better enough people would absolutely use it. But it doesn’t exist. In an ideal world it wouldn’t exist, but we don’t live there.
- adastra22 1y agoDocker is that lightweight tool, isn’t it? It doesn’t seem that complex to me. Unfamiliar to those who haven’t used it, but not intrinsic complexity.
- a012 1y ago> Having a reproducible dev environment is great when everyone’s laptop is different and may be running different OSes, libraries, runtimes, etc. Docker and other containerization solved the “it works on my machine” issue
- SkiFire13 1y ago> so there is basically a zero percent chance I'll come in in the morning and not be able to run the latest head of develop because someone else's dev machine is slightly different from mine. It seems you never had to deal with timezone-dependent tests.
- sroerick 1y agoWhat are timezone-dependent tests? Sounds like a bummer
- SkiFire13 1y agoI once had to work with a legacy Java codebase and they hardcoded the assumption their software would run in the America/New_York timezone, except some parts of the codebase and tests used the _system_ timezone, so they would fail if run in a machine with a different timezone.