4 ms·
His point about fat binaries is a good one. After using languages with lots of dangling parts such as Java and Ruby, moving to Go was amazing on the deploy end
by tomohawk 7y ago
His point about fat binaries is a good one.
After using languages with lots of dangling parts such as Java and Ruby, moving to Go was amazing on the deploy end.
With the dangling parts languages, you have a VM of some sort, and packages. All that stuff needs to be managed when you're building the app, and when you deploy the app, and when you maintain the app.
With a fat binary you only have to manage that once, and deployment becomes super simple. We actually put off using containers for quite a while because what's the point of putting a single binary into a container? There are reasons, but its much less compelling than if you have all of those dangling parts to manage.
- w8rbt 7y agoI agree 100%. A Go fat binary has all the advantages of Docker with none of the added abstractions and complexities.
- tty2300 7y agoIs it sandboxed from the host system?
- pritambaral 7y agoDocker is not a sandbox. In fact, it is less secure than other containerisation systems. Docker has never been designed for security or sold as a security system.
- newacct77 7y agoWith the obvious downside that you are now writing your application in Go.
- cutler 7y agoOther than the JRE/JDK what other dangling parts does Java depend on? I mean installing the same JRE/JDK at both ends is hardly onerous.
- EdwardDiego 7y agoProviding dependencies mainly. But then JVM development has multiple ways to handle that (fat JARs) etc.
- half-kh-hacker 7y agoIf you don't shade libraries, I imagine managing a classpath can become quite difficult.
- lmz 7y agoDoes Go or other 'fat binary' languages have a better story for this? I know this is an issue for Java when dependency A wants X v1.0 and dependency B wants X v2.1 (incompatible), but not sure how using Go makes this any easier.
- hu3 7y agogo modules allows v1.0 and v2.1 of a lib to coexist in a project because their import paths differ.
- ohiovr 7y agoHow would a fat binary help with system integration like environment variables and entries in /etc ?
- pmontra 7y agoIt's been a long time since I developed in Java but I remember that a webapp and its dependencies can be wrapped into a single .war file. All you have to provide on the server is the JVM and an application server (tomcat, etc.) I'm working with Elixir now and I only have to apt-get Erlang and Elixir. Everything else is included in the build. To be fair if we developed some C extension we could need to install some more apt package. That would go into the ansible server setup scripts. Deployment is not as simple as scp of a file to the server but deployment with distillery is still a single command operation once the deployment configuration file is OK. We're not using docker, which in our case would provide only sandboxing.
- slooonz 7y ago> and an application server (tomcat, etc.) And this is way, way too much. I will need a reverse proxy (nginx/traefik) anyway for non-Java services. Just give me an application that simply listen on a TCP socket (or better yet on an Unix socket) instead of that redundant intermediary that is a configuration/deployment nightmare.
- pixelrevision 7y agoI read this a lot and am genuinely curious why java is considered to be so much more complex than go. From what I understand java is still a “fat binary” that runs in the jvm. The only difference I see is with go I don’t need to install a vm but the tradeoff is my java app would run anywhere whereas I have to compile a go app for my platform. Is there some element about java that I’m missing here?
- tomohawk 7y agoThe best way to manage things is to not have them. With a go binary, you just have the binary. To deploy as a unit, just copy it to a machine. To run it, just run it - it's an executable. You can just give the executable to someone and they can run it. Great for sharing tools and utilities. Great for microservices because you can replace each microservice without impacting the others. With java, you have the JRE, at least one JAR (which likely will contain lots of other jars for any non-trivial application), and likely some sort of script to orchestrate startup. You need a build system to put all that together. If you want to install it, you need something that will package it all up, which will require some thought and tooling. In the end, though, you still will have these separate parts installed on the system. This greatly complicates maintenance, because now that you have a separate JRE, someone might want to reuse that for other things as well. They might argue it doesn't make sense to install the JRE separately for each service, or maybe their install system is incompetent and doesn't allow for that. If this happens, and you want to go to a newer version of your service that requires a newer JRE, you might get stuck because the people who control the deployment will tend to control the JRE that is installed and used. You end up getting stuck with a old JRE, and upgrading it becomes this big coordination issue. Any non-trivial java app will require testing on whatever platform you're targeting. In addition, it will be handicapped by the least common denominator approach of the jvm. With a go binary, on the other hand, you may have to build a separate one for Linux and Mac, but that also tends to free up people's thinking a bit and allow for tailoring the app for each platform. The testing issue is the same as for java apps.
- lkrubner 7y agoSee “Why would anyone choose Docker over fat/uber binaries” http://www.smashcompany.com/technology/why-would-anyone-choose-docker-over-fat-binaries http://www.smashcompany.com/technology/why-would-anyone-choo...