This is a rather naive view. AWS and Azure provide A LOT more than just VMs/containers (EC2) as a service.

Just having Docker won't give you the same that you can get from AWS RDS, S3, Glacier, Redshift, Route 53, etc.

Sure, but you can get similar things from Google Cloud SQL, Google Cloud Storage, Google Cloud Storage (Nearline), BigQuery, and Google Cloud DNS.

So then the question for me is do I want to deal with Google or Amazon? I pick Amazon every time because I'd never want to depend on Google, who hates customer service and sucks at it.

And you forgot sales, which they suck at even worse, and is critical to success in the cloud (to sell to Enterprises).

Not sure how Spotify ended up using GCE instead of any other providers. The downtime story was hilarious.

They don't understand enterprise challenges. They think they do, but are wrong because they think everything's a software problem.

The most annoying thing about ECS is how it looks like docker-compose (v1) but is just different enough to be incompatible. At my last job, we were evaluating containerization, and we nearly gave up after seeing how awful ECS was to make work.

Having been running a large scale production system on ECS for well over a year now, I'd like to say that ECS is hardly a bad choice; it's incredibly stable, integrates with proven AWS technologies (CloudFormation, ELB, etc) and it just works without having to manage clustering. All it needs is a layer of usability on top, which you can get from things like Empire and Convox.

While native Docker clustering is cool in theory, I think the vast amount of complexity around networking makes it unsuitable for production deployments at this time. If stability is more important than bells and whistles, ECS is great choice. Docker's production story, outside of simply running containers, has a lot to be desired.

Can you point to some of the instabilities?

I'm assuming you're referring to instabilities in Docker networking. I can't point to anything specific, but that's because we've seen it as an unnecessary layer of complexity, that's trying to solve a problem that most companies don't/won't have.

DNS + a load balancer is proven and stable. We have 65,536 available ports on linux, and doing port mapping to prevent conflicts across containers is trivial (Empire handles this for us). Client side service discovery is usually unnecessary for most Docker use cases (stateless services), where a load balancer is a better fit (why push load balancing to clients? Would you expect your browser to have to load balance when visiting google.com?).

I'm sure there are cases where networking overlays are a good fit, I just haven't found one yet.

You don't have to use overlay. Docker networking is pluggable and any networking configuration supported by Linux can easily ne expised to Docker via network plugins. The most common configurations (bridge, nat, host networking, no networking, overlay) are built-in.

    > I'm assuming you're referring to instabilities in Docker networking

I don't know... whichever instabilities you were thinking of when you said "If stability is more important than bells and whistles..."

A better comparison is probably Amazon's Elastic Beanstalk / Docker integration.

http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create...

second on beanstalk/docker - beanstalk does simplify quite a bit about running a fleet of docker images (and non-docker stuff too), uses standard aws tools (cf, elb, rds, ecs, vpc), has zero downtime deployment built in, automated server upgrades, app monitoring, environment cloning etc...

one nick against beanstalk is that it could be faster doing all those things, but it's tolerable considering alternatives.

Terraform + any old CI + Elastic Beanstalk works wonderfully for deploying docker apps on AWS.

What does beanstalk do exactly? I stopped using it once I needed multi-container deployments but I know that's supported now.

No, elastic beanstalk is terrible.

Works great for us so far. Care to elaborate?

I've been using Elastic Beanstalk for some time now and while I find it quite useful for people who just want to get Docker to production without investing to much time into Orchestration, it looks to me like there is a bit of price to pay for that 'simplicity':

   - Elastic Beanstalk does not provide a native Docker experience. You're forced to use AWS own way of defining services and dependencies (Dockerrurn.aws.json, which comes in two versions). This means you cannot longer use docker-compose, and not all of the options from `docker run` are available (logging driver,  privileged containers, though I think the ability to run privileged containers was recently added).
    - From my personal experience deployment times can be unacceptable long ranging from 5 - 20 mins. They get longer as you add more instances to the environment or if the instances are not powerful enough.

I think Elastic Beanstalk makes a good choice for starters or for not so mission-critical applications.

As a result of the points explained above I'm now looking into more Docker-centric solutions such Rancher/Kubernete or Docker's UCP.

I can't get GPU instances on GCE and high CPU instances max out at 32 vCPU which is a blocker for me.

After further review, they don't seem to have a product similar to SNS, looks like I might be able to do most of the same things with Pub/Sub though.

As you said, SNS is mostly covered with PubSub but SQS and any sort of RDS for something other than MySQL are absent (notably Postgres). I like GCE a lot and we use it at $work but there's no excuse at this point to not have feature parity.

PubSub should handle all of your SQS needs and then some. It's a weird combo of SNS and SQS. Has topics, too.

Firebase Cloud Messaging (FCM) seems like an alternative to SNS, although it isn't part of GCE.

GCE = Google Compute Engine GKE = Google Container Engine

The K is for Kubernetes :)

Pretty sure the parent actually meant GCE in every spot it said GCE.

ECS wasn't too bad. The approach they took made sense when it first came out but Amazon haven't evolved the idea since then. Personally I think that GCE's edge won't come from their container support since AWS and Azure both support k8s but will come from their value-add analytics and data services like BigQuery, Dataflow and so on. If Azure and AWS can't compete on that front then GCE will start to cannabilise the customers who are only still using the respective cloud providers only for infrastructure. GCE still has a long way to go before it becomes a serious contender.

I'm overall pretty optimistic about AWS, but if they do end up losing to another platform I would expect it to be due to this general issue of not iterating on their offerings enough. I can't really recall them ever deprecating a service, e.g. forking something to a v2 and killing off v1after a certain amount of time. So with everything they release they only give themselves one chance to get the core of it right.

SimpleDB got somewhat put out to pasture, in that it technically exists but isn't linked to hardly anywhere in their docs.

Right, but that's kind of the problem. If I were signing up for the first time and needed a simple db, I might see the SimpleDB service in the dashboard and try it out, not knowing its been unofficially deprecated.

Similar from what I can tell with CloudSearch being superceded by Elasticsearch Service. Although their version of elasticsearch is ~2 years old and hasn't been updated since they launched the service, so this may be a case where neither are getting any attention.

The worst part is, AWS support is so tight-lipped in the forums and over web support that there's no way to tell what is still fully supported and what's being silently put out to pasture. You have to look for hints based on what products they're doing webinars about, looking at the momentum of what products they're making tweaks to in the weekly update emails, etc.

What do you mean it has a long way to go? What exactly is missing in GCE compared to AWS? You just stated something you would be an edge in the future, but no cons it seemed like.

Interested to know because we're considering cloud providers.

Quizlet detailed their impressions of EC2 and GCE, and ultimately went with Google:

https://quizlet.com/blog/whats-the-best-cloud-probably-gcp

Thank you, that looks like an interesting writeup!

Isn't there usually some sort of "disclosure: I work for Google"? Your post-history seems very one-sided. :)

Sure, but I wasn't offering an opinion, rather a link :)

GCE is not stable(a kind of forever beta) and misses a lot of the AWS features. It's basically few years behind AWS. I started to hate it but unfortunately I already invested too much in the platform to leave it now. Pro: it's cheaper than AWS.

Would you care to elaborate? What features are missing? What's not stable?

For example there is no AWS Certificate Manager. Someday a similar feature may land on GCP but as usually it will be too little too late. IAM was released only recently. Before IAM the auth & auth on GCP was really a joke. GAE management is still not API manageable. You need to use the sdk which has private APIs to deploy new apps or manage versions. What kind of cloud service is that if it doesn't have an API? GAE email service required you(until recently) to create a paid google apps account for each email address you want to use as sender (WTF??). All this was done manually (e.g. in the browser). Recently the service was totally deprecated(i.e. you are limited at 100 emails per day). Compare that with Amazon SES which was a stable and robust product from day one and still works flawlessly. This is really how GCP relates to AWS. At first glance it looks similar but then you find out that's a stripped down version with various restrictions and stability issues. Last time I've checked the SDK was a mess. Two issues come into my mind: - I couldn't ssh into an instance because the username for a particular distro was different than in the docs - I couldn't deploy a docker based GAE Managed VM(now named flexible VM<see stability>). I understand it's beta labelled but when not even the "example" app is not deployable it says a lot about the product stability.

I could make a long list with such issues... If the price is the most important factor and you need basic cloud features and you are fine with a beta label GCP may work for you, otherwise you should look elsewhere.

Long way to go in catching up with Azure and AWS in relation to market share not in capability. I should have clarified that.

And in terms of larger names, Spotify's infrastructure was recently switched to Google.

https://news.spotify.com/us/2016/02/23/announcing-spotify-in...

gpus

Also a ton of third-party tools and documentation are built with aws support in mind.

Very interesting that GCE wasn't mentioned on the slide of supported infrastructures at the DockerCon keynote today.

It wasn't mentioned because we only launched Docker for AWS and Docker for Azure. We only had the bandwidth to ship 2 versions at the level of quality we wanted, so we picked the most frequently requested providers. I think GCE is a great candidate for the next batch of releases. It all depends on demand. Would you use it?