I might be mistaken, but I don’t understand how this tool or the practices in this article get you a truly repeatable build.
To me, having a repeatable build means you produce the same binary artifacts when you build your checked-in source code no matter when or on what machine you run the build on. But using a tool like Docker seems to already make this impossible. If a Dockerfile allows you to RUN apt-get install foo, then running that command at time T1 will give you a different answer than running at time T2.
RUN apt-get install foo
It seems to me like you can’t have real repeatability unless you have repeatable dependency semantics all the way down to the language level for each dependency manager you’re using. Tools like Blaze get around this by forcing you to use their own dependency management system that basically requires you to vendor everything, which guarantees repeatability. But I don’t see an analogous system in Earthly.
We debated ourselves a lot about what the right term is for this. From community feedback, we learned that there is a term for 100% deterministic builds: Reproducible builds. Earthly is not that. Bazel is. Earthly (and the practices that this guide talks about) has some consistency, but as you point out, it doesn’t get you all the way. We called this “repeatable builds” as an in-between term. The reasoning is that for many use-cases, it’s better if you are compatible with most open-source tooling, but are not 100% deterministic, rather than go all the way deterministic, but usability is heavily impacted.
No, you are not mistaken. Docker lets you RUN anything inside them, and so they are not reproducible by design. You could write Dockerfiles that are reproducible by not using some features (this is what Bazel does to ensure reproducibility when building Docker images).
The serverless concept solves this problem, because it requires no DevOps to build and deploy applications at scale. But so far, this kind of technology has only been available exclusively from cloud vendors, like AWS, Azure and Google Cloud Platform, forcing users into proprietary technology and having no freedom to run it in private clouds or locally, for development.
…makes no sense. What can serverless possibly mean if you run it on your own servers? What is zero DevOps involvement with a new server-side tool that must be configured to run applications? What is the sound of one hand clapping?
The serverless concept moves the problem, often to an unexpected place.
Hey there, author here. I was just saying that DevOps don’t intervene in the building / deployment of individual apps. DevOps do very much need to exist to maintain the platform itself. It just decouples things and thus reduces the amount of hand-holding.
Thanks, that’s a useful clarification. I do think that some amount of hand-holding is important for its own sake; Allspaw and Hammond’s 2009 description of DevOps focused more on empathy and cooperation between developers and operations folks than on decoupling or hand-offs. If you don’t want to hold hands then a 3rd party commercial platform like Heroku is very appropriate.
It seems like you can only write apps in JS with this. Is that true?
For now Go and JS are supported. Python and Java are coming next. It’s based on gRPC so adding new languages is relatively easy.