4 ms·

This removes nearly all of "devops". You don't have to mess around with figuring out how many ec2 instances you need (or deal with auto-scaling groups), how to

This removes nearly all of "devops". You don't have to mess around with figuring out how many ec2 instances you need (or deal with auto-scaling groups), how to secure the linux or whatever you stick on the ec2 instances, etc. There's still a ton of creating zip file artifacts of your lambda payloads (instead of pushing to a magic git repository that amazon controls, say), so there's a bit of "build monkey"ing to do instead of "devops"ery. But I think a lot of shops will be happy to make that trade, as "build" is closer to their core experience than "devops".

maratd 11y ago
Yes, you get rid of devops. You gain vendor lock-in. You are now tied to the Amazon platform. If they shut down or suspend your account, for any reason, you are out of business. You are also paying premium for the platform, with the cost of devops built in. I'll take an open ecosystem that gives me options to migrate my business anytime over a proprietary solution.
- curiousjorge 11y ago
  pretty much this. amazon can at any point shut down any of these services or nerf it. if you built everything up to this point on amazon and they shut it down, it's more work.
  - maratd 11y ago
    To add to your point, they have done this before and are still doing it. There is no guarantee of continued service. http://recode.net/2015/03/18/amazon-will-shut-down-amazon-webstore-its-competitor-to-shopify-and-bigcommerce/ http://recode.net/2015/03/18/amazon-will-shut-down-amazon-we...
    - duskwuff 11y ago
      Amazon Webstore wasn't part of AWS, though. It was part of their commerce wing - very different.
      - curiousjorge 11y ago
        remember PiCloud? they shut down after I spent a quarter building around their API calls. I never want to repeat that mistake and you also get the bonus of being able to sell your source code or deploy local cloud if an enterprise are willing to pay extra for it.
- andyidsinga 11y ago
  There's always this tension, its really interesting. I think the open ecosystem approach will work well for apps/systems that are more established and have a predictable and sustainable user base and related revenue stream to maintain the system. But for new ideas, early stage startups, the open eco-system approach will be a lot more work than using the high-level services providers like amazon are developing ...basically a no-stack approach can help one quickly find some product / market fit. Once some level of baseline level of utilization is understood then switching to a more difficult, but less-locked in approach would be smart. all that said, there's probably a middle ground here too (but arguably not) -- where one deploy's using docker containers, private registry & image repo, s3 for static immutable storage and some open database like PostgreSQL on RDS. All that could be layered on top of AWS and other providers -- but it will still be a PITA to move the whole thing. BTW -- take a look at the elasticbox product -- they really have an interesting approach to cloud that sort of obviates the lock-in issue by allowing one to build apps across clouds from the start using their "boxes" metaphor.
treve 11y ago
I'd say that most people don't need auto-scaling, and this configuration is almost definitely harder to understand and learn than a simple php script that works everywhere.
- jshen 11y ago
  NO it's not harder to understand. If you are doing anything remotely serious, then your php script needs to be on multiple servers for redundancy, it needs to be behind a load balancer, you have to be responsible for the security of the VMs the php script runs on, and on and on and on and on. Edit: well, unless you run your php script in a PaaS like Google App Engine.
  - treve 11y ago
    Yet, most people probably still FTP their php files onto a shared hosting environment. And for most people, that's actually good enough.
NDizzle 11y ago
Maybe this statement will date me, but I don't really like this trend of having to deal with less things. I mean, sure, it's more simple to get started. But when things break you are screwed because nobody really knows what is going on.
andyidsinga 11y ago
yep -- the devops part is valuable on the app creator/dev's side and this architecture is very valuable on the amazon/cloud service provider's side too. The smaller the scheduled unit of code is, the more densely they can pack the workloads and make more efficient use of their system ...squeezing out the pennies at their scale makes a lot of sense. I've seen some vendor lock in comments here -- but certainly the big 3 or 4 service providers will have these features figured out soon - and seems to me some open source to schedule functions across compute will appear in no time that could be used by the smaller providers. replicating all the other features is much harder -- this is a great moat amazon has built.
rycfan 11y ago
Sorry, this is actually factually incorrect. As shown in another thread here, this service does not infinitely auto-scale (the recommendation was to use Kinesis), so you still have to know which services to choose, which is pretty much a full-time job with the number of different services offered these days.

maratd 11y ago

Yes, you get rid of devops. You gain vendor lock-in. You are now tied to the Amazon platform. If they shut down or suspend your account, for any reason, you are out of business. You are also paying premium for the platform, with the cost of devops built in. I'll take an open ecosystem that gives me options to migrate my business anytime over a proprietary solution.

curiousjorge 11y ago
pretty much this. amazon can at any point shut down any of these services or nerf it. if you built everything up to this point on amazon and they shut it down, it's more work.
- maratd 11y ago
  To add to your point, they have done this before and are still doing it. There is no guarantee of continued service. http://recode.net/2015/03/18/amazon-will-shut-down-amazon-webstore-its-competitor-to-shopify-and-bigcommerce/ http://recode.net/2015/03/18/amazon-will-shut-down-amazon-we...
  - duskwuff 11y ago
    Amazon Webstore wasn't part of AWS, though. It was part of their commerce wing - very different.
    - curiousjorge 11y ago
      remember PiCloud? they shut down after I spent a quarter building around their API calls. I never want to repeat that mistake and you also get the bonus of being able to sell your source code or deploy local cloud if an enterprise are willing to pay extra for it.
andyidsinga 11y ago
There's always this tension, its really interesting. I think the open ecosystem approach will work well for apps/systems that are more established and have a predictable and sustainable user base and related revenue stream to maintain the system. But for new ideas, early stage startups, the open eco-system approach will be a lot more work than using the high-level services providers like amazon are developing ...basically a no-stack approach can help one quickly find some product / market fit. Once some level of baseline level of utilization is understood then switching to a more difficult, but less-locked in approach would be smart. all that said, there's probably a middle ground here too (but arguably not) -- where one deploy's using docker containers, private registry & image repo, s3 for static immutable storage and some open database like PostgreSQL on RDS. All that could be layered on top of AWS and other providers -- but it will still be a PITA to move the whole thing. BTW -- take a look at the elasticbox product -- they really have an interesting approach to cloud that sort of obviates the lock-in issue by allowing one to build apps across clouds from the start using their "boxes" metaphor.

treve 11y ago

I'd say that most people don't need auto-scaling, and this configuration is almost definitely harder to understand and learn than a simple php script that works everywhere.

jshen 11y ago
NO it's not harder to understand. If you are doing anything remotely serious, then your php script needs to be on multiple servers for redundancy, it needs to be behind a load balancer, you have to be responsible for the security of the VMs the php script runs on, and on and on and on and on. Edit: well, unless you run your php script in a PaaS like Google App Engine.
- treve 11y ago
  Yet, most people probably still FTP their php files onto a shared hosting environment. And for most people, that's actually good enough.

NDizzle 11y ago

Maybe this statement will date me, but I don't really like this trend of having to deal with less things. I mean, sure, it's more simple to get started. But when things break you are screwed because nobody really knows what is going on.

andyidsinga 11y ago

yep -- the devops part is valuable on the app creator/dev's side and this architecture is very valuable on the amazon/cloud service provider's side too. The smaller the scheduled unit of code is, the more densely they can pack the workloads and make more efficient use of their system ...squeezing out the pennies at their scale makes a lot of sense. I've seen some vendor lock in comments here -- but certainly the big 3 or 4 service providers will have these features figured out soon - and seems to me some open source to schedule functions across compute will appear in no time that could be used by the smaller providers. replicating all the other features is much harder -- this is a great moat amazon has built.

rycfan 11y ago

Sorry, this is actually factually incorrect. As shown in another thread here, this service does not infinitely auto-scale (the recommendation was to use Kinesis), so you still have to know which services to choose, which is pretty much a full-time job with the number of different services offered these days.