12 ms·

What I don't understand is why AWS squandered this opportunity. Given the popularity of Lambda, they clearly saw the market for completely managed services. The

What I don't understand is why AWS squandered this opportunity. Given the popularity of Lambda, they clearly saw the market for completely managed services. They could have designed a platform where users upload containers and AWS runs them. No servers, no crazy settings, etc. Instead, they created this entire platform where you still have to run the entire EC2 infrastructure, there is no service discovery, etc. They essentially created a half baked Mesos or Kubernetes clone. I'm still shocked when I hear companies going "all in" on ECS.

codemac 10y ago
A good friend told me that he felt that Google Cloud and AWS had "a severe lack of imagination". Imagine what you could do if you didn't even assume a process model? All app state just resident in memory, but magically persisted? Who needs object storage, re-invent the pointer! We could have lived in the future, now it seems we're permanently wed to the past.
- mschuster91 10y ago
  > Imagine what you could do if you didn't even assume a process model? All app state just resident in memory, but magically persisted? Who needs object storage, re-invent the pointer! Take your usual Java, NodeJS or Ruby payload, enjoy your memory leaks eating up your space.
- count 10y ago
  We're starting to get to the point where these giants can innovate like that. It wasn't 3 years ago that 'nobody serious' was 'trusting' cloud providers like AWS/GCE with anything important. This is still the very early days, as evidenced by the ridiculous growth numbers being posted YoY.
- gtaylor 10y ago
  > A good friend told me that he felt that Google Cloud and AWS had "a severe lack of imagination". I don't know about that. Google Container Engine (hosted Kubernetes) is actually pretty awesome and imaginative. It's feeling like GCP's niche is going to have a sizable containerization element. If you browse around their docs, you'll find that GKE/containers have started creeping into the examples for seemingly unrelated services. They're not just dipping a toe in. More generally, I feel like GCP's container strategy is just leagues ahead of AWS' at this point. While this article was thin on substance, ECS is definitely difficult to set up and maintain. If I'm going to go through all of that trouble, I might as well run my own Kubernetes or Mesos setup and not be locked into ECS.
  - _asummers 10y ago
    I know you can deploy Kubernetes on AWS, though I have not tried myself. What, if you have tried it, is it lacking from the GCP version?
    - gtaylor 10y ago
      It's not that it's lacking at all, but on GCP I just click a few buttons and Google spins a Kubernetes cluster up for me. They handle my node OS upgrades for me. They've also got a really slick in-place rolling cluster upgrade setup. The primary difference on AWS is that you are doing all of this yourself instead. This isn't bad for everyone, but I've got the option of having Google do it in addition to doing it myself on GCP. As a bonus, Kubernetes abstracts a lot of inter-provider differences away. I can move between providers more easily, or even run across multiple providers (cluster federation). ECS is severely limited and slow to evolve, by comparison. They got to market first, but their overall container strategy is now inferior to GCP's. They're still ahead in many other ways, though. I just feel like containers are GCP's sweet spot.
      - boulos 10y ago
        Kubernetes was out well before ECS. And technically we launched GKE in public Alpha before ECS (which was a week or so later at re:Invent). If you mean before we called it a GA service, then you're right (but the team wanted it to be based on what they considered Kubernetes 1.0).
    - lobster_johnson 10y ago
      Google has been unusually/surprisingly environment-agnostic when it comes to Kubernetes, and it has ample support for AWS: It will read EC2 metadata (instace tags, AZ placement), it will automatically provision route tables and ELBs, and can attach EBS volumes. As such, it integrates almost as well with AWS as with GCP. It's telling that Google has lots of experience with containers, because GCE is a smoother environment to deploy Kubernetes in. Perhaps the most visible is the one-IP-per-pod/one-IP-per-service design requirements of Kubernetes, which fits directly into GCE's super-flexible IP address space (an amazing, modern L3 SDN), whereas on AWS you have to work around AWS's creaky, old-hat VPC system and its positively stone-age security group system. As a result, a lot of people are resorting to overlay solutions like Flannel, Weave and Calico (overlays on top of overlays!). GCE's networking, in short, is amazing, and AWS's isn't. GKe's automatic cluster setup is also impressive. GKE will create a master for you and you just tell it how many nodes you want. Disappointingly, the Kubernetes dashboard is not integrated into the GCE admin, but it's likely that they're working on a new one for that. Because of the lack of a UI, though, GKE feels a bit unfinished right now. That said, it's obvious from even a casual glance that GCP as a whole is a lot less mature than AWS. The SDK situation is a mess compared to AWS. Google's complicated style of authentication is particularly onerous on developers. Google's services feel less nailed down than AWS; for example, CloudSQL exists as two (incompatible, afaik) versions, and there are multiple APIs that are marked as beta-quality (Google is slowly adopting gRPC throughout their system as an alternative to REST APIs). Some of their services offer odd design decisions; for example, Pub/Sub is clearly a clone of SQS, down to its more annoying features (no proper fanout support, and plenty of latency), but it also innovates on it by supporting "realtime" delivery... which for some reason only supports push events. Go figure. Overall, Google Cloud Platform feels a bit half-hearted, unpolished and ramshackle in many places, even though clearly there's a lot that is technically solid. This impression is partly due to the messiness of the documentation. As with Kubernetes itself, it seems Google likes to developer faster than they can document. I do think that GCP will, in time, be much better than AWS. They are clearly innovating in many ways that Amazon isn't, especially in containerization.
- deleted 10y ago
  [deleted]
- nikanj 10y ago
  I heartily recommend this essay http://scholar.harvard.edu/files/mickens/files/thenightwatch.pdf http://scholar.harvard.edu/files/mickens/files/thenightwatch... , for gems like "Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis."
  - codemac 10y ago
    I love James Mickens with all my heart. All of it.
- jacques_chester 10y ago
  > Imagine what you could do if you didn't even assume a process model? We have that world, it's called single-process apps. And it's awful from the point of view of security, scalability and disaster recovery. > All app state just resident in memory, but magically persisted? You need transactions or this ends unhappily. Some languages truly grok transactional updates to state. Most do not. In the meantime, you've rate limited the entire system to the slowest component. > We could have lived in the future, now it seems we're permanently wed to the past. Your friend overlooks that extremely intelligent people have looked into these things. They usually had extremely important disadvantages, which sufficiently offset the advantages that mere momentum kept the majority approaches as the majority approaches. Your friend also seems to have left it as an exercise for the reader on how one is meant to deal with distributed systems. The short answer is: it is hard, and trying to create the seamless illusion that the network doesn't exist hasn't really panned out. The speed of light is a cruel limit.
maslam 10y ago
There are lots of cases where AWS builds services that are not revolutionary but purely evolutionary. Consider Amazon Redshift, their data warehouse. You would _think_ Redshift, with its poor elasticity and tight coupling of compute and storage would suck compared to BigQuery, which is a truly new way of doing things. However, the combination of "it's just Postgres(-ish)" and rapid feature iteration make it a pretty good system to use. Most importantly, the cost model is very good. TL;DR it really depends on the service.
- yeukhon 10y ago
  I actually find it interesting you would Redshift as the example to justify evolutionary of AWS service offering, also plus the cost. The cost of running Redshift is very expensive, even with reserved instance.
  - maslam 10y ago
    @yeukhon - for the performance you get, Redshift is quite affordable. Keep in mind it's an always-on data warehouse - there's really no way to make it much cheaper than AWS does because they're incurring compute costs. What are you comparing it to? Hadoop?
    - ec109685 10y ago
      If you are only querying occasionally BigTable has cost advantages since latent storage cost is much lower.
- boulos 10y ago
  Amusingly RedShift was licensed: > It is built on top of technology from the massive parallel processing (MPP) data warehouse ParAccel by Actian. so I think it's hard to draw conclusions from it. [0] quote is from the Wikipedia entry (https://en.m.wikipedia.org/wiki/Amazon_Redshift https://en.m.wikipedia.org/wiki/Amazon_Redshift)
moosingin3space 10y ago
ECR might be the only good thing about ECS, but even that is still clunky!
- gtaylor 10y ago
  Google's GCE isn't much better. CoreOS's Quay is the best that I've seen. Nice UI, and a head start over Docker Hub's image security scanning.
  - gtaylor 10y ago
    Whoops, I'd edit this but apparently my mobile app doesn't support such a thing. GCE in the parent should be GCR (Google Container Registry).
  - SEJeff 10y ago
    Have you by chance seen Redhat's Openshift? It is some nice features built with Kunernetes as the core.
    - gtaylor 10y ago
      I haven't checked it out yet personally. I'm not sure what else I'd want to put on top of Kubernetes, though. The only thing I'm really left wanting right now is distributed cron (which is supposed to be landing in 1.4).
  - lobster_johnson 10y ago
    Do you know if Quay (or anyone else) solves the compilation issue? The issue is that if you compile anything in your Dockerfile, you end up installing the compiler as well as producing unnecessary build artifacts, which will still remains as a layer that must be downloaded even if you uninstall the compiler and clean up after yourself. In other words, a bunch of unnecessary cruft. This applies not just to compiled languages, but to any language (Node.js, Ruby) that relies on a build phase as part of getting dependencies. The proper fix is to perform the compilation outside of the main container (for example, by starting a throwaway build container that you only use for compilation) and then copy the final artifacts into the final container. But I don't know of any hosted solutions that support that workflow.
derefr 10y ago
I think you misunderstand the purpose of AWS (as do most people.) AWS isn't for greenfield projects (or, at least, that's not where they make the majority of their revenue); AWS is literal "virtual infrastructure", in the sense that it's the stuff you hand an ops team to manage. You can take an experienced internal ops team that was managing physical infrastructure for some BigCorp (servers, switches, etc.), and migrate them to AWS instead, and there will be a 1:1 mapping between their problems and AWS's offerings. ECS isn't for people who wanted 'managed infrastructure' in the "so we don't have to have a dedicated ops-team at all" sense. ECS is for ops-teams who were previously managing e.g. an OpenStack Nova cluster with an LXC-driver backend, and now want the virtual equivalent of that. Just like EC2 is built for ops-teams who were using VSphere or Xen.
- jamiesonbecker 10y ago
  > ... there will be a 1:1 mapping between their problems and AWS's offerings I don't know if you meant it that way, but I laughed out loud when I read that!
  - derefr 10y ago
    I didn't not mean it that way. :)
- dmourati 10y ago
  I disagree with your assessment. I say this as an ops person, actively migrating workload from on premise physical infrastructure to the public cloud. EC2 is not built for ops teams at all. It is built for developers. The VSphere/Xen analogy doesn't hold up. Amazon is explicitly abstracting away the physical and software stack that ops teams would build and mantain onsite. AWS gives you back an API and a reference client. Nothing to install, no physical hosts to buy, no network switches to configure. Simply focus on your compute requirements and go from there.
  - derefr 10y ago
    Maybe "ops" is an imprecise designation for the organizational role AWS is intended to target, but "developer" is definitely incorrect. My position is that AWS is designed for a particular usage pattern: one where a large enterprise organization has a particular department that consumes, configures, and manages AWS's virtual infrastructure (just like an ops team consumes, configures, and manages physical infrastructure), and then, in turn, provide an internal IT-services abstraction to the rest of their organization, using AWS as the "backend" for (some or all of) those services. None of AWS's services are created from the perspective of use by application developers; they don't present application-level interfaces, nor do they expect (unlike PaaS services) that the application can be rewritten to conform to the shape of the infrastructure. The application is taken as a given. IaaS APIs are created such that an internal IT services department can receive a request from an application developer to provision a cluster for their (fixed) application, and can respond to that request by hitting AWS APIs, instead of by paging ops staff. In smaller organizations, these lines blur under "devops" sensibilities, where the developers effectively do their own IT services. But in organizations where this boundary is clear, AWS lives inside it, not anywhere where developers can see or touch it. AWS's 'idiomatic' use is to be a transparent drop-in backend replacement that the application developers in the company won't even be aware that ops has switched over to—except to notice that there are now likely fewer ops people overall.
madeofpalk 10y ago
Have you seen ElasticBeanstalk's ECS setup? We've went 'all in' on that and it's been fairly successful for us so far. We use a combination of long-lived servers (spin up one stack which lasts for multiple versions/deployments) for our test environments, and then we do blue-green deployments for production which gives it a complete new stack for every deploy. We've been running a bunch of services on it for a months and its been fine.
- maslam 10y ago
  @madeofpalk, I haven't seen that, actually. I'll look into it.
- sheeshkebab 10y ago
  Second on beanstalk... I'm no sure why anyone would even bother with raw esc - just let aws manage it all using beanstalk. It certainly still relies on elb/dns and whichever env vars for "discovery" stuff, but it beats rolling your own infrastructure management using ecs/cloudformation etc.
  - jon-wood 10y ago
    Beanstalk is great when you're at a scale that can justify one or more instances per application, but raw ECS works better when you've got lots of low traffic services that don't saturate even a single small instance.
    - needcaffeine 10y ago
      This. And microservices makes beanstalk too expensive.
- santoriv 10y ago
  +1 for ElasticBeanstalk Docker deployments. I looked at ECS first about a year ago and ran into a lot of the same messes the OP did. ElasticBeanstalk was way more straightforward and the CLI is pretty decent. One thing we did run into was that very occasionally environmental variables wouldn't show up inside deployed containers so we had to bake all the application secrets into the build process. A little annoying but nothing too terrible. Otherwise everything has been pretty great.
skywhopper 10y ago
Two things, I think. One, AWS is putting a huge bet on getting huge Enterprise customers to migrate their datacenters to the cloud. So a lot of the new services in the last couple of years have been centered around making it easier to transition big Fortune 500 companies' infrastructure before MS or Google acquires those companies and the tens of billions of future ongoing guaranteed revenue they represent. But number two, I get the impression that AWS has some severe underlying technical debt that comes from original architecture decisions from 10 years ago, and that they are pouring a lot of current resources into addressing those problems, and getting customers off the old crusty stuff. For example, there's a major transition coming to make EC2 IDs much longer so they can remain universally unique, but that's a painful transition. Then there's weird stuff like the "classic" non-VPC accounts where security groups are identified by name. And all the services that don't have tags, and the fact that it's easier to operate multiple AWS accounts than to partition permissions within one account. But they are working on fixes for all these things, but a lot of them are buried so deep in the architecture that it's taking some time. But in a couple of years when some of the new things on the horizon come to fruition, I think we'll see more aggressive iteration on managed serverless infrastructure options.
org78 10y ago
We had that conversation with them too, and they just show you how every feature you'd get in kubernetes ECS can also do in a round about way or will do once another AWS service is updated. But for some reason are cagy when it comes to solving for "just run this artifact somewhere for me". It's as though they see their model as being a competitive advantage over kubernetes. shrug

codemac 10y ago

A good friend told me that he felt that Google Cloud and AWS had "a severe lack of imagination". Imagine what you could do if you didn't even assume a process model? All app state just resident in memory, but magically persisted? Who needs object storage, re-invent the pointer! We could have lived in the future, now it seems we're permanently wed to the past.

mschuster91 10y ago
> Imagine what you could do if you didn't even assume a process model? All app state just resident in memory, but magically persisted? Who needs object storage, re-invent the pointer! Take your usual Java, NodeJS or Ruby payload, enjoy your memory leaks eating up your space.
count 10y ago
We're starting to get to the point where these giants can innovate like that. It wasn't 3 years ago that 'nobody serious' was 'trusting' cloud providers like AWS/GCE with anything important. This is still the very early days, as evidenced by the ridiculous growth numbers being posted YoY.
gtaylor 10y ago
> A good friend told me that he felt that Google Cloud and AWS had "a severe lack of imagination". I don't know about that. Google Container Engine (hosted Kubernetes) is actually pretty awesome and imaginative. It's feeling like GCP's niche is going to have a sizable containerization element. If you browse around their docs, you'll find that GKE/containers have started creeping into the examples for seemingly unrelated services. They're not just dipping a toe in. More generally, I feel like GCP's container strategy is just leagues ahead of AWS' at this point. While this article was thin on substance, ECS is definitely difficult to set up and maintain. If I'm going to go through all of that trouble, I might as well run my own Kubernetes or Mesos setup and not be locked into ECS.
- _asummers 10y ago
  I know you can deploy Kubernetes on AWS, though I have not tried myself. What, if you have tried it, is it lacking from the GCP version?
  - gtaylor 10y ago
    It's not that it's lacking at all, but on GCP I just click a few buttons and Google spins a Kubernetes cluster up for me. They handle my node OS upgrades for me. They've also got a really slick in-place rolling cluster upgrade setup. The primary difference on AWS is that you are doing all of this yourself instead. This isn't bad for everyone, but I've got the option of having Google do it in addition to doing it myself on GCP. As a bonus, Kubernetes abstracts a lot of inter-provider differences away. I can move between providers more easily, or even run across multiple providers (cluster federation). ECS is severely limited and slow to evolve, by comparison. They got to market first, but their overall container strategy is now inferior to GCP's. They're still ahead in many other ways, though. I just feel like containers are GCP's sweet spot.
    - boulos 10y ago
      Kubernetes was out well before ECS. And technically we launched GKE in public Alpha before ECS (which was a week or so later at re:Invent). If you mean before we called it a GA service, then you're right (but the team wanted it to be based on what they considered Kubernetes 1.0).
  - lobster_johnson 10y ago
    Google has been unusually/surprisingly environment-agnostic when it comes to Kubernetes, and it has ample support for AWS: It will read EC2 metadata (instace tags, AZ placement), it will automatically provision route tables and ELBs, and can attach EBS volumes. As such, it integrates almost as well with AWS as with GCP. It's telling that Google has lots of experience with containers, because GCE is a smoother environment to deploy Kubernetes in. Perhaps the most visible is the one-IP-per-pod/one-IP-per-service design requirements of Kubernetes, which fits directly into GCE's super-flexible IP address space (an amazing, modern L3 SDN), whereas on AWS you have to work around AWS's creaky, old-hat VPC system and its positively stone-age security group system. As a result, a lot of people are resorting to overlay solutions like Flannel, Weave and Calico (overlays on top of overlays!). GCE's networking, in short, is amazing, and AWS's isn't. GKe's automatic cluster setup is also impressive. GKE will create a master for you and you just tell it how many nodes you want. Disappointingly, the Kubernetes dashboard is not integrated into the GCE admin, but it's likely that they're working on a new one for that. Because of the lack of a UI, though, GKE feels a bit unfinished right now. That said, it's obvious from even a casual glance that GCP as a whole is a lot less mature than AWS. The SDK situation is a mess compared to AWS. Google's complicated style of authentication is particularly onerous on developers. Google's services feel less nailed down than AWS; for example, CloudSQL exists as two (incompatible, afaik) versions, and there are multiple APIs that are marked as beta-quality (Google is slowly adopting gRPC throughout their system as an alternative to REST APIs). Some of their services offer odd design decisions; for example, Pub/Sub is clearly a clone of SQS, down to its more annoying features (no proper fanout support, and plenty of latency), but it also innovates on it by supporting "realtime" delivery... which for some reason only supports push events. Go figure. Overall, Google Cloud Platform feels a bit half-hearted, unpolished and ramshackle in many places, even though clearly there's a lot that is technically solid. This impression is partly due to the messiness of the documentation. As with Kubernetes itself, it seems Google likes to developer faster than they can document. I do think that GCP will, in time, be much better than AWS. They are clearly innovating in many ways that Amazon isn't, especially in containerization.
deleted 10y ago
[deleted]
nikanj 10y ago
I heartily recommend this essay http://scholar.harvard.edu/files/mickens/files/thenightwatch.pdf http://scholar.harvard.edu/files/mickens/files/thenightwatch... , for gems like "Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis."
- codemac 10y ago
  I love James Mickens with all my heart. All of it.
jacques_chester 10y ago
> Imagine what you could do if you didn't even assume a process model? We have that world, it's called single-process apps. And it's awful from the point of view of security, scalability and disaster recovery. > All app state just resident in memory, but magically persisted? You need transactions or this ends unhappily. Some languages truly grok transactional updates to state. Most do not. In the meantime, you've rate limited the entire system to the slowest component. > We could have lived in the future, now it seems we're permanently wed to the past. Your friend overlooks that extremely intelligent people have looked into these things. They usually had extremely important disadvantages, which sufficiently offset the advantages that mere momentum kept the majority approaches as the majority approaches. Your friend also seems to have left it as an exercise for the reader on how one is meant to deal with distributed systems. The short answer is: it is hard, and trying to create the seamless illusion that the network doesn't exist hasn't really panned out. The speed of light is a cruel limit.

maslam 10y ago

There are lots of cases where AWS builds services that are not revolutionary but purely evolutionary. Consider Amazon Redshift, their data warehouse. You would _think_ Redshift, with its poor elasticity and tight coupling of compute and storage would suck compared to BigQuery, which is a truly new way of doing things. However, the combination of "it's just Postgres(-ish)" and rapid feature iteration make it a pretty good system to use. Most importantly, the cost model is very good. TL;DR it really depends on the service.

yeukhon 10y ago
I actually find it interesting you would Redshift as the example to justify evolutionary of AWS service offering, also plus the cost. The cost of running Redshift is very expensive, even with reserved instance.
- maslam 10y ago
  @yeukhon - for the performance you get, Redshift is quite affordable. Keep in mind it's an always-on data warehouse - there's really no way to make it much cheaper than AWS does because they're incurring compute costs. What are you comparing it to? Hadoop?
  - ec109685 10y ago
    If you are only querying occasionally BigTable has cost advantages since latent storage cost is much lower.
boulos 10y ago
Amusingly RedShift was licensed: > It is built on top of technology from the massive parallel processing (MPP) data warehouse ParAccel by Actian. so I think it's hard to draw conclusions from it. [0] quote is from the Wikipedia entry (https://en.m.wikipedia.org/wiki/Amazon_Redshift https://en.m.wikipedia.org/wiki/Amazon_Redshift)

moosingin3space 10y ago

ECR might be the only good thing about ECS, but even that is still clunky!

gtaylor 10y ago
Google's GCE isn't much better. CoreOS's Quay is the best that I've seen. Nice UI, and a head start over Docker Hub's image security scanning.
- gtaylor 10y ago
  Whoops, I'd edit this but apparently my mobile app doesn't support such a thing. GCE in the parent should be GCR (Google Container Registry).
- SEJeff 10y ago
  Have you by chance seen Redhat's Openshift? It is some nice features built with Kunernetes as the core.
  - gtaylor 10y ago
    I haven't checked it out yet personally. I'm not sure what else I'd want to put on top of Kubernetes, though. The only thing I'm really left wanting right now is distributed cron (which is supposed to be landing in 1.4).
- lobster_johnson 10y ago
  Do you know if Quay (or anyone else) solves the compilation issue? The issue is that if you compile anything in your Dockerfile, you end up installing the compiler as well as producing unnecessary build artifacts, which will still remains as a layer that must be downloaded even if you uninstall the compiler and clean up after yourself. In other words, a bunch of unnecessary cruft. This applies not just to compiled languages, but to any language (Node.js, Ruby) that relies on a build phase as part of getting dependencies. The proper fix is to perform the compilation outside of the main container (for example, by starting a throwaway build container that you only use for compilation) and then copy the final artifacts into the final container. But I don't know of any hosted solutions that support that workflow.

derefr 10y ago

I think you misunderstand the purpose of AWS (as do most people.) AWS isn't for greenfield projects (or, at least, that's not where they make the majority of their revenue); AWS is literal "virtual infrastructure", in the sense that it's the stuff you hand an ops team to manage. You can take an experienced internal ops team that was managing physical infrastructure for some BigCorp (servers, switches, etc.), and migrate them to AWS instead, and there will be a 1:1 mapping between their problems and AWS's offerings. ECS isn't for people who wanted 'managed infrastructure' in the "so we don't have to have a dedicated ops-team at all" sense. ECS is for ops-teams who were previously managing e.g. an OpenStack Nova cluster with an LXC-driver backend, and now want the virtual equivalent of that. Just like EC2 is built for ops-teams who were using VSphere or Xen.

jamiesonbecker 10y ago
> ... there will be a 1:1 mapping between their problems and AWS's offerings I don't know if you meant it that way, but I laughed out loud when I read that!
- derefr 10y ago
  I didn't not mean it that way. :)
dmourati 10y ago
I disagree with your assessment. I say this as an ops person, actively migrating workload from on premise physical infrastructure to the public cloud. EC2 is not built for ops teams at all. It is built for developers. The VSphere/Xen analogy doesn't hold up. Amazon is explicitly abstracting away the physical and software stack that ops teams would build and mantain onsite. AWS gives you back an API and a reference client. Nothing to install, no physical hosts to buy, no network switches to configure. Simply focus on your compute requirements and go from there.
- derefr 10y ago
  Maybe "ops" is an imprecise designation for the organizational role AWS is intended to target, but "developer" is definitely incorrect. My position is that AWS is designed for a particular usage pattern: one where a large enterprise organization has a particular department that consumes, configures, and manages AWS's virtual infrastructure (just like an ops team consumes, configures, and manages physical infrastructure), and then, in turn, provide an internal IT-services abstraction to the rest of their organization, using AWS as the "backend" for (some or all of) those services. None of AWS's services are created from the perspective of use by application developers; they don't present application-level interfaces, nor do they expect (unlike PaaS services) that the application can be rewritten to conform to the shape of the infrastructure. The application is taken as a given. IaaS APIs are created such that an internal IT services department can receive a request from an application developer to provision a cluster for their (fixed) application, and can respond to that request by hitting AWS APIs, instead of by paging ops staff. In smaller organizations, these lines blur under "devops" sensibilities, where the developers effectively do their own IT services. But in organizations where this boundary is clear, AWS lives inside it, not anywhere where developers can see or touch it. AWS's 'idiomatic' use is to be a transparent drop-in backend replacement that the application developers in the company won't even be aware that ops has switched over to—except to notice that there are now likely fewer ops people overall.

madeofpalk 10y ago

Have you seen ElasticBeanstalk's ECS setup? We've went 'all in' on that and it's been fairly successful for us so far. We use a combination of long-lived servers (spin up one stack which lasts for multiple versions/deployments) for our test environments, and then we do blue-green deployments for production which gives it a complete new stack for every deploy. We've been running a bunch of services on it for a months and its been fine.

maslam 10y ago
@madeofpalk, I haven't seen that, actually. I'll look into it.
sheeshkebab 10y ago
Second on beanstalk... I'm no sure why anyone would even bother with raw esc - just let aws manage it all using beanstalk. It certainly still relies on elb/dns and whichever env vars for "discovery" stuff, but it beats rolling your own infrastructure management using ecs/cloudformation etc.
- jon-wood 10y ago
  Beanstalk is great when you're at a scale that can justify one or more instances per application, but raw ECS works better when you've got lots of low traffic services that don't saturate even a single small instance.
  - needcaffeine 10y ago
    This. And microservices makes beanstalk too expensive.
santoriv 10y ago
+1 for ElasticBeanstalk Docker deployments. I looked at ECS first about a year ago and ran into a lot of the same messes the OP did. ElasticBeanstalk was way more straightforward and the CLI is pretty decent. One thing we did run into was that very occasionally environmental variables wouldn't show up inside deployed containers so we had to bake all the application secrets into the build process. A little annoying but nothing too terrible. Otherwise everything has been pretty great.

skywhopper 10y ago

Two things, I think. One, AWS is putting a huge bet on getting huge Enterprise customers to migrate their datacenters to the cloud. So a lot of the new services in the last couple of years have been centered around making it easier to transition big Fortune 500 companies' infrastructure before MS or Google acquires those companies and the tens of billions of future ongoing guaranteed revenue they represent. But number two, I get the impression that AWS has some severe underlying technical debt that comes from original architecture decisions from 10 years ago, and that they are pouring a lot of current resources into addressing those problems, and getting customers off the old crusty stuff. For example, there's a major transition coming to make EC2 IDs much longer so they can remain universally unique, but that's a painful transition. Then there's weird stuff like the "classic" non-VPC accounts where security groups are identified by name. And all the services that don't have tags, and the fact that it's easier to operate multiple AWS accounts than to partition permissions within one account. But they are working on fixes for all these things, but a lot of them are buried so deep in the architecture that it's taking some time. But in a couple of years when some of the new things on the horizon come to fruition, I think we'll see more aggressive iteration on managed serverless infrastructure options.

org78 10y ago

We had that conversation with them too, and they just show you how every feature you'd get in kubernetes ECS can also do in a round about way or will do once another AWS service is updated. But for some reason are cagy when it comes to solving for "just run this artifact somewhere for me". It's as though they see their model as being a competitive advantage over kubernetes. shrug