4 ms·

It is pretty cool but not really serverless, you are still handling http requests via Amazon API gateway and in general you are relying and paying for quite a l

It is pretty cool but not really serverless, you are still handling http requests via Amazon API gateway and in general you are relying and paying for quite a lot of Amazon services. Not sure how much better this approach is to serving image magic via PHP for example, it would be good to see some numbers.

philsnow 11y ago
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.
ahallock 11y ago
The point is you don't provision your own servers, not that servers don't exist somewhere executing your code. People seem to be taking the marketing too literally.
- larrys 11y ago
  It's good add copy and ranks high on the link-bait scale. They say after all: "and then unit and load tested it, all without using any servers." ...with a title of "Microservices without the Servers" when what they mean is "without provisioning any servers yourself" which is obviously much less attractive. My curiosity was peaked by the title the title, inserting "w/o provisioning" would have not gotten me anywhere near as interested in the topic.
  - angrow 11y ago
    Would you apply the same analysis if I claimed I could buy a t-shirt from a store without using any factories?
- logn 11y ago
  No it's not taking this too literally. I re-read the architecture a few times then stepped through the source to make sure I wasn't missing something. I was thinking that maybe the servers were only used to deploy the image processing code to the client which could then run the code locally. But that's not the case. Serverless implies that a server is not required after an installation step and that you only need your local device. Or perhaps too that you only need a collection of like clients to do something P2P. Just because you as the developer don't have to think about the server doesn't make it serverless.

philsnow 11y ago

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.

ahallock 11y ago

The point is you don't provision your own servers, not that servers don't exist somewhere executing your code. People seem to be taking the marketing too literally.

larrys 11y ago
It's good add copy and ranks high on the link-bait scale. They say after all: "and then unit and load tested it, all without using any servers." ...with a title of "Microservices without the Servers" when what they mean is "without provisioning any servers yourself" which is obviously much less attractive. My curiosity was peaked by the title the title, inserting "w/o provisioning" would have not gotten me anywhere near as interested in the topic.
- angrow 11y ago
  Would you apply the same analysis if I claimed I could buy a t-shirt from a store without using any factories?
logn 11y ago
No it's not taking this too literally. I re-read the architecture a few times then stepped through the source to make sure I wasn't missing something. I was thinking that maybe the servers were only used to deploy the image processing code to the client which could then run the code locally. But that's not the case. Serverless implies that a server is not required after an installation step and that you only need your local device. Or perhaps too that you only need a collection of like clients to do something P2P. Just because you as the developer don't have to think about the server doesn't make it serverless.