The more I use Docker the more I realize that GCE is going to smoke AWS and Azure in the future with regards to deploying a containerized infrastructure.
This is mostly because turn-key kubernetes on GCE is light years ahead of what ECS provides. It almost makes amazon's offering seem like a joke.
This might level the playing field a bit by having Docker itself provide the infrastructure management software instead of it being tied to a particular service.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
This is mostly because turn-key kubernetes on GCE is light years ahead of what ECS provides. It almost makes amazon's offering seem like a joke.
This might level the playing field a bit by having Docker itself provide the infrastructure management software instead of it being tied to a particular service.