4 ms·
> containerized .Net and Java Gross. If that's the alternative I would rather stick with mainframes. People forget that it's perfectly fine and even better to
by 38 2y ago
> containerized .Net and Java
Gross. If that's the alternative I would rather stick with mainframes. People forget that it's perfectly fine and even better to just run code directly in many cases.
- Yasuraka 2y agoContainers are not VMs, code runs directly on metal and performance is pretty-much-native. https://web.archive.org/web/20150218172511/http://domino.research.ibm.com:80/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf https://web.archive.org/web/20150218172511/http://domino.res... This is from 2015, and it improved from there (e.g. the daemon-less podman matured, NAT is no longer needed). That said, I'd happily take even the performance impact of VMs and order a few more servers, if it means that I won't have to deal with dotnet/java runtimes being shared by multiple applications.
- 38 2y agoIf you need a container, your stack (dotnet/java) sucks. That's why Amazon deprecated the Go container, cause it's just not needed
- consteval 2y agoYes those langs have large runtimes. But even for compiled native languages, if you have a lot of dependencies you will require containers sooner or later. Go doesn't really have the huge dynamic-linking ecosystem. But, if you do and then project X and project Y diverge on versions... you have a problem. Also containers can automate deployment easier. Like the line from bare server -> full deployment is much faster if you use containers.