>During the beta period you will be charged only for the Google Cloud Storage storage and network egress consumed by your Docker images.
Dammit google, this is not how you price things. Especially when people have been burned by price jumps on your service before. I don't know why i'd bother integrating with a service when I have no idea what the cost will be.
> Dammit google, this is not how you price things.
It actually is the way Google quite often prices things.
> I don't know why i'd bother integrating with a service when I have no idea what the cost will be.
Then maybe a pre-release service for which Google has not yet developed the experience with usage patterns that will let it price the service appropriately isn't for you. But that's okay, its not intended for everybody -- even everybody for whom the service would be appropriate when GA -- hence the Beta label.
Your quote says it is a beta service. If you are betting the farm on beta services or expecting them not to change under you during a beta period, it really is only your own fault.
This could end up being more expensive than Docker's own or CoreOS's. People would rather pay a flat fee rather than worrying about storage and bandwidth.
A large part of the issue with pricing on Google App Engine (which is the one that still stings for many people) - was that they were building on a relatively proprietary platform.
The advantage of Docker based compute engines is that your lock-in is a lot lower - providers have to compete on price and features without locking customers in.
Where I work, we're always balancing using new AWS features against how hard it would be to migrate out to another provider or take our solutions on-premises.
I really expected for Amazon to release a Container Registry before they took the preview status off ECS. Looks like Google beat them to the punch. I'd still be very interested to see if Amazon will release something soon.
Yes a little bit of competition in the container registry space would be good for everybody. I need to have a closer look how good is this Google offering. One problem that we run into was security when started to use Docker. The management did not want to upload the images to any cloud provider, so we were forced to create a registry in our infrastructure. For this use case Registry 2.0 is going to be a better option.
I imagine that wouldn't be very likely in this case—this is much less like Google's usual "let's build some random thing and see if customers like it", and instead very much in the vein of the way Amazon treats AWS: as a set of infrastructure services they themselves consume, but also happen to expose to the public.
Now, they might make it private in the future, but as long as Google are using containers for everything, I don't think the service is likely to just go unmaintained and fade away.
From what I know of Google's infrastructure, they are very unlikely to be consuming this internally, just like the rest of GCP. Just because they use containers doesn't mean they use this container repository. Just because they use Java web servers doesn't mean they use AppEngine.
They use the external version of App Engine to run any of their customer-facing products? Which ones? Products -- I'm not talking about marketing micro-sites.
> very much in the vein of the way Amazon treats AWS: as a set of infrastructure services they themselves consume, but also happen to expose to the public.
Reference? I've heard (unsubstantiated but believable) rumors that the servers and system that run the amazon website are rather different from the servers and system they sell the rest of us.
Is this specifically aimed at compute cloud users for faster deploys?
I would much rather go with dockerhub than use this. Egress pricing sucks. I'd rather have it from docker, who made the tool for my containers, than google.
What about docker 1.6, with image and container labels? Will Google keep this up to date?
True that, the original LXC library was Google. Then Docker wrote their own implementation called libcontainer (and systemd-nspawn popped about).
While Google made containers possible I think Docker made them happen. I can't imagine committing an LXC container and pushing it to a repo if it weren't for docker. Nor would I want to manage raw networking in LXC. Nor sharing of filesystems.
The bits of containers that made it out into lxc are essentially borglet features. The rest of the infrastructure around it was never released to the outside world, and now docker is recreating some of that infrastructure. We've had borg for a long time ;)
There's lots more detail in the paper about how these pieces relate to each other.
Interesting. I've been using google/docker-registry to have a private docker registry based in Google Cloud Storage for some time now. I wonder what additional benefits this service will provide for the (presumably) higher price once it comes out of beta.
>During the beta period you will be charged only for the Google Cloud Storage storage and network egress consumed by your Docker images.
Dammit google, this is not how you price things. Especially when people have been burned by price jumps on your service before. I don't know why i'd bother integrating with a service when I have no idea what the cost will be.