> But i can see ko being good alternative if you for some reason do not want to install docker on your computer but still be able to build docker containers.
Docker is a much bigger dependency than ko, involving a daemon and a socket you have to manage and secure. ko is a only a go program, and builds are straight-forward and lightning fast compared to Docker.
Importantly, ko also removes the need for a Dockerfile. Yes, as you point out a Dockerfile can be simple, but but the best part is no part. Dockerfile has plenty of foot guns and best practices to learn so if at the end of the day all you need is a go binary on a container ko will serve you much, much better.
Although Dockerfiles have the benefit of migrating existing workloads to containers without having to update your toolchain, I definitely prefer the container-first workflow. Cloud Native Buildpacks(https://buildpacks.io/) are a CNCF incubating project but were proven at Heroku. Buildpacks support common languages, but working on a Go project I've also had a great experience with ko(https://ko.build/). Free yourself from Dockerfile!
I'm not really thrilled with Cloud Native Buildpacks.
They are optimized for the Heroku style use case of being able to create a "universal builder", which will detect and build projects of various types (node, python, go. java, etc).
The problem is that the buildpacks in such universal builders are pretty much black boxes to people trying to use them in projects, and often end up handling simple cases, but failing for more complex, or if flexible enough to handle most projects, ends up being rather arcane.
Of course, you can end up creating your own buildpacks for your company that do just what you need, but even then you may have some projects with really complex requirements. For such complex projects, you made need to create a special buildpack.
Lastly, buildpacks don't provide full flexibility in the output. For example, a minimal container for a program written in Go only needs a single layer with the resulting executable set as entrypoint. You can't make that with buildpacks. In practice most "stacks" will provide some full OS environment, like an apline or ubuntu image. On top of that is a mandatory runtime layer container the `/cnb/lifecycle/launcher` executable. Finally your buildpack outputs are layered on top of that.
(Admittedly there is work-in progress that would allow specifying some other base image via Dockerfile, and you could specify "FROM scratch". This would mean an empty base layer, on which the launcher layer, the config layer, app layer, which is a little better, but still not as nice as a fully customizable output.)
I live in the neighborhood and have bought a few sodas from the machine. I always assumed it was locksmith, they are powering the machine and I've never seen nor heard a reason to believe it was anyone else.
It was a cute novelty, and if you're not picky it's a fast soda, but honestly it was just stocked with cheap, off-brand gross soda. Would have been genius if occasionally it gave you something interesting (or at least good).
It certainly used to! That machine introduced me to a weird variety of things when I lived near it almost 20 years ago. Cheap thrills as a broke young 'un.
Thanks to it, I still have to try strange sodas when I am traveling--especially abroad. It's not always good, but it's always fun.
Have you visited the Coca Cola museum in Las Vegas?
Not sure if it still exists, but I went in 2000. They had about 100 different sodas from around the world.
These days, I haven't had any soda in years. 35+ grams of sugar per can is a terrible idea.
There's also one in Atlanta, and I think maybe Orlando as well. Always fun to see the tourists getting surprised by the one bitter drink in the whole collection (Beverly, from Italy). Wikipedia claims it was discontinued 12 years ago, except for the Coke museums.
> Google might do this for a lot of reasons, and none of them seem to be good.
As a Play Store developer, I give Google the benefit of the doubt. By the way, before you assume a nefarious purpose, consider all Android phones connecting to the Play Store (by definition) have an auto-updating root process. Why does Google need to impersonate an application developer? This is fundamentally why Commonsware scare tactics don't resonate with me, the application has less privileges than the system and the app store, the calls are coming from inside the house!
But, there are more common and mundane reasons. Honestly, a lot of people lose their private signing key. And if that happens, no more updates to your app. By using App Signing, Google can help regenerate a key for you. They want to make this ability consistent across their whole store, that's why they're making the change.
They can also optimize the app bundle the device downloads from the store, as the store will know the target screen size, localization, CPU architecture, etc. The current workflow forces the application engineer to upload separate apk configurations. So this is also an improvement.
You're correct that some Google Cloud zones are in the same physical building. However, the separate zones are designed with independent power, cooling, and networking. So, failure events usually affect only a single zone.
Docker is a much bigger dependency than ko, involving a daemon and a socket you have to manage and secure. ko is a only a go program, and builds are straight-forward and lightning fast compared to Docker.
Importantly, ko also removes the need for a Dockerfile. Yes, as you point out a Dockerfile can be simple, but but the best part is no part. Dockerfile has plenty of foot guns and best practices to learn so if at the end of the day all you need is a go binary on a container ko will serve you much, much better.