5 ms·

Nice proof that serverless might be great for projects with a couple of endpoints. In real life projects, you get a ton of YAML spaggetti boilerplate code and

Nice proof that serverless might be great for projects with a couple of endpoints. In real life projects, you get a ton of YAML spaggetti boilerplate code and when you hit the endpoint limit on your deployment you will need to start splitting your code over multiple deployments. Compare this with other frameworks where you can actually program your URL router (Django, Rails & co) and it's definitely a step backward. When you've past the PoC stage, DynamoDB is the first thing you want to replace with PostgreSQL because you need data integrity and migrations. But that's not your only problem .... When endpoints depend on each other, then it becomes pretty tricky to deploy, cause you'll need to wait until your first endpoint is deployed before you can deploy your second endpoint. So, you're out of the nice "immutable image deployment" paradigm, which means that your frontend code will have to support both old and new versions of each endpoint, just like your backend code will have to support both old and new data structure versions in DynamoDB, as the deployment of a chain of endpoint will take a while and will not be done atomically. This will slow down development velocity for sure. If you intend to make a real life project live over many fast iterations, then isolating yourself in a proprietary framework like serverless is the last thing you want to do in my experience. So yeah, for a two-endpoints "Hello World" project where autoscaling is valued over iteration speed, then serverless and dynamodb might be a solution to consider, as long as you're willing to isolate yourself in proprietary frameworks. That said, you can have autoscaling with iteration speed using open source frameworks anyway (ie. with GKE) so why bother with serverless at all ? Anything you can do with serverless can be done better with k8s and any actually powerful framework such as Django, Rails, Dancer, perhaps even Laravel, CakePHP or Symfony if PHP is your thing. But let's face it, 99.999% of projects don't need more than 99.9% of uptime which is extremely easy to achieve with a single dedicated server, which gives you a lot of hardware for cheap (unlike AWS). Once you've outscaled a RAM128GB dedicated server then it's time to consider extracting parts of your app into something like serverless.

nostrebored 7y ago
Regarding programmatic endpoint handlers, these solve completely different problems. Different to the point that there's no reason that you can't employ one on top of the other. When you start hitting endpoint limits there's a very strong sign that you've had responsibility creep for a microservice, or even worse you're treating your serverless deployment as a monolith. Your insistence on integrity issues with DynamoDB is also strange. Religious adherence to ACID is not going to be your silver bullet for application design. Learning how to reason about distributed systems and their eventual consistency is necessary to begin with in most cloud setups. Anything you can do with serverless can be done better with k8s? Cool, have it provision my underlying infrastructure
- 1337shadow 7y ago
  The thing is that a lot of times serverless is mentioned as "the future", most people I've seen understand "silver bullet": https://aws.amazon.com/fr/blogs/apn/serverless-containers-are-the-future-of-container-infrastructure/ https://aws.amazon.com/fr/blogs/apn/serverless-containers-ar... As for provisioning, I mentioned GKE already, but I can throw in some more: https://www.scaleway.com/en/docs/get-started-with-scaleway-kubernetes-kapsule/ https://www.scaleway.com/en/docs/get-started-with-scaleway-k... https://www.ovh.com/world/public-cloud/kubernetes/ https://www.ovh.com/world/public-cloud/kubernetes/ https://github.com/bbelky/hkube https://github.com/bbelky/hkube https://github.com/kubernetes-sigs/kubespray https://github.com/kubernetes-sigs/kubespray
  - qaq 7y ago
    "Religious adherence to ACID is not going to be your silver bullet for application design. Learning how to reason about distributed systems and their eventual consistency is necessary to begin with in most cloud setups." So you just X10 the development costs for no good reason. Also as a user of many FANG services that are using eventually consistent stores color me unimpressed by the user experience. Considering that a startup or even a F500 company has a pretty low chance of hiring people of the same caliber as those systems were designed by this is nog a good solution for 99% of the projects.
  - mdaniel 7y ago
    > https://github.com/bbelky/hkube/blob/master/hkube.go https://github.com/bbelky/hkube/blob/master/hkube.go I cannot fathom the process through which one arrived at that file. It started out looking like someone who did not know that shell scripting was a thing, only to morph into a golang program writing out a shell script and exec-s it: https://github.com/bbelky/hkube/blob/master/hkube.go#L193 https://github.com/bbelky/hkube/blob/master/hkube.go#L193 The icing on the cake is committing a compiled binary for some unknown platform into git
icemelt8 7y ago
I am a frontend developer with some knowledge of backend, these technologies are for me. As I cannot understand what k8s does and how to use it.
bazza451 7y ago
Came into the same issues. I hate example projects like these because they are misleading and read like silver bullets. The split stack resources thing is extremely difficult to manage due to serverless not supporting CF params. so you have to use CF cross stack references which are horrible or hack in support like we did. I’ve seen issues where you can’t put the value of a variable as an arn in an event due to the poor abstraction across the top of it as they’ve tried to make it cross provider, completely pointless. Just breaks. Stick with cf/terraform if you’re starting a big project.
com2kid 7y ago
> and when you hit the endpoint limit on your deployment you will need to start splitting your code over multiple deployments. Firebase allows for 1000 functions per project, all of which can be deployed at once. If I have more than a 1000 endpoints sitting in a single folder I'll consider that I've gone a bit too micro on the idea of micro-services! > Anything you can do with serverless can be done better with k8s The cloud vendors work hard to make ecosystem buy-in convenient. E.g. reduced/no egress charges between their services hosting on the same cloud, and smooth integration between services. As an example, with Google Firebase I am using their auth, database, and serverless solutions. When I needed to start storing user assets somewhere it was less than half an hour to get everything working end to end including proper security and permissions in place. Could I have setup a VM and built out some sort of service to manage/serve assets? Sure. There is probably some open source project out there that if I spend a day or two reading up on it I could get it configured, and then get it integrated with my existing auth system. And then I'd have one more VM to manage security updates on, and worry about deploying. With Firebase I get test and production environments all setup for me automatically[1], with separate credentials and the works. It isn't necessarily about scaling speed, it is also about not having to worry about infra.
- 1337shadow 7y ago
  I think you're confused between FaaS and Serverless. Serverless is an Amazon service, Firebase is not serverless, however both are FaaS. I'm talking specifically about AWS Serverless.
  - com2kid 7y ago
    Firebase also offers DBs, storage, and even hosting. I'm confused as to why you say it isn't serverless, AWS's "Serverless" (wow that name...) looks like a suite of existing products advertised under one label. From their splash page it looks mostly equivalent to what Firebase, although it seems Amazon has some functionality that Firebase itself doesn't have (necessitating using the full Google Cloud).
  - dragonwriter 7y ago
    > I think you're confused between FaaS and Serverless. I think you are confused about those. > Serverless is an Amazon service, No, it's not. 1. The “Serverless Application Model” is an AWS functionality (a transform for CloudFormation templates for serverless [see #3] compute.) 2. “Serverless Framework” is an open-source product that is independent of Amazon (though it originally targeted only AWS) which supports multiple cloud provider. 3. “serverless” is a broad concept for cloud computing without managing server instances, encompassing, among other things, FaaS—AWS popularized the term, but it's used generally across the industry. > Firebase is not serverless Someone tell Google: https://cloud.google.com/blog/products/application-development/serverless-in-action-building-a-simple-backend-with-cloud-firestore-and-cloud-functions https://cloud.google.com/blog/products/application-developme...

nostrebored 7y ago

Regarding programmatic endpoint handlers, these solve completely different problems. Different to the point that there's no reason that you can't employ one on top of the other. When you start hitting endpoint limits there's a very strong sign that you've had responsibility creep for a microservice, or even worse you're treating your serverless deployment as a monolith. Your insistence on integrity issues with DynamoDB is also strange. Religious adherence to ACID is not going to be your silver bullet for application design. Learning how to reason about distributed systems and their eventual consistency is necessary to begin with in most cloud setups. Anything you can do with serverless can be done better with k8s? Cool, have it provision my underlying infrastructure

1337shadow 7y ago
The thing is that a lot of times serverless is mentioned as "the future", most people I've seen understand "silver bullet": https://aws.amazon.com/fr/blogs/apn/serverless-containers-are-the-future-of-container-infrastructure/ https://aws.amazon.com/fr/blogs/apn/serverless-containers-ar... As for provisioning, I mentioned GKE already, but I can throw in some more: https://www.scaleway.com/en/docs/get-started-with-scaleway-kubernetes-kapsule/ https://www.scaleway.com/en/docs/get-started-with-scaleway-k... https://www.ovh.com/world/public-cloud/kubernetes/ https://www.ovh.com/world/public-cloud/kubernetes/ https://github.com/bbelky/hkube https://github.com/bbelky/hkube https://github.com/kubernetes-sigs/kubespray https://github.com/kubernetes-sigs/kubespray
- qaq 7y ago
  "Religious adherence to ACID is not going to be your silver bullet for application design. Learning how to reason about distributed systems and their eventual consistency is necessary to begin with in most cloud setups." So you just X10 the development costs for no good reason. Also as a user of many FANG services that are using eventually consistent stores color me unimpressed by the user experience. Considering that a startup or even a F500 company has a pretty low chance of hiring people of the same caliber as those systems were designed by this is nog a good solution for 99% of the projects.
- mdaniel 7y ago
  > https://github.com/bbelky/hkube/blob/master/hkube.go https://github.com/bbelky/hkube/blob/master/hkube.go I cannot fathom the process through which one arrived at that file. It started out looking like someone who did not know that shell scripting was a thing, only to morph into a golang program writing out a shell script and exec-s it: https://github.com/bbelky/hkube/blob/master/hkube.go#L193 https://github.com/bbelky/hkube/blob/master/hkube.go#L193 The icing on the cake is committing a compiled binary for some unknown platform into git

icemelt8 7y ago

I am a frontend developer with some knowledge of backend, these technologies are for me. As I cannot understand what k8s does and how to use it.

bazza451 7y ago

Came into the same issues. I hate example projects like these because they are misleading and read like silver bullets. The split stack resources thing is extremely difficult to manage due to serverless not supporting CF params. so you have to use CF cross stack references which are horrible or hack in support like we did. I’ve seen issues where you can’t put the value of a variable as an arn in an event due to the poor abstraction across the top of it as they’ve tried to make it cross provider, completely pointless. Just breaks. Stick with cf/terraform if you’re starting a big project.

com2kid 7y ago

> and when you hit the endpoint limit on your deployment you will need to start splitting your code over multiple deployments. Firebase allows for 1000 functions per project, all of which can be deployed at once. If I have more than a 1000 endpoints sitting in a single folder I'll consider that I've gone a bit too micro on the idea of micro-services! > Anything you can do with serverless can be done better with k8s The cloud vendors work hard to make ecosystem buy-in convenient. E.g. reduced/no egress charges between their services hosting on the same cloud, and smooth integration between services. As an example, with Google Firebase I am using their auth, database, and serverless solutions. When I needed to start storing user assets somewhere it was less than half an hour to get everything working end to end including proper security and permissions in place. Could I have setup a VM and built out some sort of service to manage/serve assets? Sure. There is probably some open source project out there that if I spend a day or two reading up on it I could get it configured, and then get it integrated with my existing auth system. And then I'd have one more VM to manage security updates on, and worry about deploying. With Firebase I get test and production environments all setup for me automatically[1], with separate credentials and the works. It isn't necessarily about scaling speed, it is also about not having to worry about infra.

1337shadow 7y ago
I think you're confused between FaaS and Serverless. Serverless is an Amazon service, Firebase is not serverless, however both are FaaS. I'm talking specifically about AWS Serverless.
- com2kid 7y ago
  Firebase also offers DBs, storage, and even hosting. I'm confused as to why you say it isn't serverless, AWS's "Serverless" (wow that name...) looks like a suite of existing products advertised under one label. From their splash page it looks mostly equivalent to what Firebase, although it seems Amazon has some functionality that Firebase itself doesn't have (necessitating using the full Google Cloud).
- dragonwriter 7y ago
  > I think you're confused between FaaS and Serverless. I think you are confused about those. > Serverless is an Amazon service, No, it's not. 1. The “Serverless Application Model” is an AWS functionality (a transform for CloudFormation templates for serverless [see #3] compute.) 2. “Serverless Framework” is an open-source product that is independent of Amazon (though it originally targeted only AWS) which supports multiple cloud provider. 3. “serverless” is a broad concept for cloud computing without managing server instances, encompassing, among other things, FaaS—AWS popularized the term, but it's used generally across the industry. > Firebase is not serverless Someone tell Google: https://cloud.google.com/blog/products/application-development/serverless-in-action-building-a-simple-backend-with-cloud-firestore-and-cloud-functions https://cloud.google.com/blog/products/application-developme...