3 ms·

> but don't pretend that Herzner let's you click your way into a highly-availale nosql data store. The idea you can click your way to a highly available, produ

by 1dom 1y ago

> but don't pretend that Herzner let's you click your way into a highly-availale nosql data store. The idea you can click your way to a highly available, production configured anything in AWS - especially involving Dynamo, IAM and Lambda - is something I've only heard from people who've done AWS quickstarts but never run anything at scale in AWS. Of course nobody else offers AWS products, but people use AWS for their solutions to compute problems and it can be easy to forget virtually all other providers offer solutions to all the same problems.

ApolloFortyNine 1y ago
>The idea you can click your way to a highly available, production configured anything in AWS - especially involving Dynamo, IAM and Lambda With some services I'd agree with you, but DynamoDB and Lambda are easily two of their 'simplest' to configure and understand services, and two of the ones that scale the easiest. IAM roles can be decently complicated, but that's really up to the user. If it's just 'let the Lambda talk to the table' it's simple enough. S3/SQS/Lambda/DynamoDB are the services that I'd consider the 'barebones' of the cloud. If you don't have all those, you're not a cloud provider, your just another server vendor.
- manquer 1y ago
  > Lambda are easily two of their 'simplest' Not if you want to build something production ready. Even a simple thing like say static IP ingress for the Lambda is very complicated. The only AWS way you can do this is by using Global Accelerator -> Application Load Balancer -> VPC Endpoint -> API Gateway -> Lambda !!. There are so many limits for everything that is very hard to run production workloads without painful time wasted in re-architecture around them and the support teams are close to useless to raise any limits. Just in the last few months, I have hit limits on CloudFormation stack size, ALB rules, API gateway custom domains, Parameter Store size limits and on and on. That is not even touching on the laughably basic tooling both SAM and CDK provides for local development if you want to work with Lambda. Sure Firecracker is great, and the cold starts are not bad, and there isn't anybody even close on the cloud. Azure functions is unspeakably horrible, Cloud Run is just meh. Most Open Source stacks are either super complex like knative or just quite hard to get the same cold start performance. We are stuck with AWS Lambda with nothing better yes, but oh so many times I have come close to just giving up and migrate to knative despite the complexity and performance hit.
  - motorest 1y ago
    > Even a simple thing like say static IP ingress for the Lambda is very complicated. Explain exactly what scenario you believe requires you to provide a lambda behind a static IP. In the meantime, I recommend you learn how to invoke a lambda, because static IPs is something that is extremely hard to justify.
    - manquer 1y ago
      Try telling that to customers who can only do outbound API calls to whitelisted IP addresses When you are working with enterprise customers or integration partners it doesn’t even have to be regulated sectors like finance or healthcare, these are basic asks you cannot get away from . people want to be able to know whitelist your egress and ingress IPs or pin certificates. It is not up to me to say on efficacy of these rules . I don’t make the rules of the infosec world , I just follow them.
      - motorest 1y ago
        > Try telling that to customers who can only do outbound API calls to whitelisted IP addresses Alright, if that's what you're going with then you can just follow a AWS tutorial: https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc-internet.html https://docs.aws.amazon.com/lambda/latest/dg/configuration-v... Provision an elastic IP to have your static IP address, set the NAT gateway to handle traffic, and plugin the lambda to the NAT gateway. Do you think this qualifies as very complicated?
        manquer 1y ago
        This architecture[1] requires the setup of 2 NAT gateways (one in each AZ), a routing table, an Internet Gateway, 2 Elastic IP and also the VPC. Since as before we cannot use Function URLs for Lambda we will still need the API Gateway to make HTTP calls. The only parts we are swapping out `GA -> ALB -> VPC` for `IG -> Router -> NAT -> VPC`. Is it any simpler ? Doesn't seem like it is to me. Going the NAT route means, you also need to have intermediate networking skills to handle a routing table (albeit a simple one), half the developers of today never used IP tables is or what chaining rules is. --- I am surprised at the amount of pushback on a simple point which should be painfully obvious. AWS (Azure/GCP are no different) has become overly complex with no first class support for higher order abstractions and framework efforts like SAM or even CDK seem to getting not much love at all in last 4-5 years. Just because they offer and sell all these components to be independently, doesn't mean they should not invest and provide higher order abstractions for people with neither bandwidth or the luxury to be a full time "Cloud Architect". There is a reason why today Vercel, Render or Railway others are popular despite mostly sitting on top of AWS. On Vercel the same feature would be[1] quite simple. They use the exact solution you suggest on top of AWS NAT gateway, but the difference I don't have to know or manage it, is the large professional engineering team with networking experience at Vercel. There is no reason AWS could not have built Vercel like features on top of their offerings or do so now. At some point small to midsize developers will avoid direct AWS by either choosing to setup Hetzner/OVH bare machines or with bit more budget colo with Oxide[3] or more likely just stick to Vercel and Railway kind of platforms. I don't know how that will impact AWS, we will all still use them, however a ton of small customers paying close to rack rate is definitely much much higher margin than what Vercel is paying AWS for the same workload is going to be. -- [1] https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html https://docs.aws.amazon.com/prescriptive-guidance/latest/pat... [2] this https://vercel.com/docs/connectivity/static-ips https://vercel.com/docs/connectivity/static-ips [3] Would be rare, obviously only if they have the skill experience to do so.
- 1dom 1y ago
  > With some services I'd agree with you, but DynamoDB and Lambda are easily two of their 'simplest' to configure and understand services, and two of the ones that scale the easiest. IAM roles can be decently complicated, but that's really up to the user. If it's just 'let the Lambda talk to the table' it's simple enough. We agree, but also, I feel like you're missing my point: "let the Lambda talk to the table" is what quickstarts produce. To make a lambda talk to a table at scale in production, you'll want to setup your alerting and monitoring to notify you when you're getting close to your service limits. If you're not hitting service limits/quotas, you're not running even close to running at scale.
motorest 1y ago
> The idea you can click your way to a highly available, production configured anything in AWS - especially involving Dynamo, IAM and Lambda - is something I've only heard from people who've done AWS quickstarts but never run anything at scale in AWS. I'll bite. Explain exactly what work you think you need to do to get your pick of service running on Hetnzer to have equivalent fault-tolerance to, say, a DynamoDB Global Table created with the defaults.

by 1dom 1y ago

ApolloFortyNine 1y ago

>The idea you can click your way to a highly available, production configured anything in AWS - especially involving Dynamo, IAM and Lambda With some services I'd agree with you, but DynamoDB and Lambda are easily two of their 'simplest' to configure and understand services, and two of the ones that scale the easiest. IAM roles can be decently complicated, but that's really up to the user. If it's just 'let the Lambda talk to the table' it's simple enough. S3/SQS/Lambda/DynamoDB are the services that I'd consider the 'barebones' of the cloud. If you don't have all those, you're not a cloud provider, your just another server vendor.

manquer 1y ago
> Lambda are easily two of their 'simplest' Not if you want to build something production ready. Even a simple thing like say static IP ingress for the Lambda is very complicated. The only AWS way you can do this is by using Global Accelerator -> Application Load Balancer -> VPC Endpoint -> API Gateway -> Lambda !!. There are so many limits for everything that is very hard to run production workloads without painful time wasted in re-architecture around them and the support teams are close to useless to raise any limits. Just in the last few months, I have hit limits on CloudFormation stack size, ALB rules, API gateway custom domains, Parameter Store size limits and on and on. That is not even touching on the laughably basic tooling both SAM and CDK provides for local development if you want to work with Lambda. Sure Firecracker is great, and the cold starts are not bad, and there isn't anybody even close on the cloud. Azure functions is unspeakably horrible, Cloud Run is just meh. Most Open Source stacks are either super complex like knative or just quite hard to get the same cold start performance. We are stuck with AWS Lambda with nothing better yes, but oh so many times I have come close to just giving up and migrate to knative despite the complexity and performance hit.
- motorest 1y ago
  > Even a simple thing like say static IP ingress for the Lambda is very complicated. Explain exactly what scenario you believe requires you to provide a lambda behind a static IP. In the meantime, I recommend you learn how to invoke a lambda, because static IPs is something that is extremely hard to justify.
  - manquer 1y ago
    Try telling that to customers who can only do outbound API calls to whitelisted IP addresses When you are working with enterprise customers or integration partners it doesn’t even have to be regulated sectors like finance or healthcare, these are basic asks you cannot get away from . people want to be able to know whitelist your egress and ingress IPs or pin certificates. It is not up to me to say on efficacy of these rules . I don’t make the rules of the infosec world , I just follow them.
    - motorest 1y ago
      > Try telling that to customers who can only do outbound API calls to whitelisted IP addresses Alright, if that's what you're going with then you can just follow a AWS tutorial: https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc-internet.html https://docs.aws.amazon.com/lambda/latest/dg/configuration-v... Provision an elastic IP to have your static IP address, set the NAT gateway to handle traffic, and plugin the lambda to the NAT gateway. Do you think this qualifies as very complicated?
      - manquer 1y ago
        This architecture[1] requires the setup of 2 NAT gateways (one in each AZ), a routing table, an Internet Gateway, 2 Elastic IP and also the VPC. Since as before we cannot use Function URLs for Lambda we will still need the API Gateway to make HTTP calls. The only parts we are swapping out `GA -> ALB -> VPC` for `IG -> Router -> NAT -> VPC`. Is it any simpler ? Doesn't seem like it is to me. Going the NAT route means, you also need to have intermediate networking skills to handle a routing table (albeit a simple one), half the developers of today never used IP tables is or what chaining rules is. --- I am surprised at the amount of pushback on a simple point which should be painfully obvious. AWS (Azure/GCP are no different) has become overly complex with no first class support for higher order abstractions and framework efforts like SAM or even CDK seem to getting not much love at all in last 4-5 years. Just because they offer and sell all these components to be independently, doesn't mean they should not invest and provide higher order abstractions for people with neither bandwidth or the luxury to be a full time "Cloud Architect". There is a reason why today Vercel, Render or Railway others are popular despite mostly sitting on top of AWS. On Vercel the same feature would be[1] quite simple. They use the exact solution you suggest on top of AWS NAT gateway, but the difference I don't have to know or manage it, is the large professional engineering team with networking experience at Vercel. There is no reason AWS could not have built Vercel like features on top of their offerings or do so now. At some point small to midsize developers will avoid direct AWS by either choosing to setup Hetzner/OVH bare machines or with bit more budget colo with Oxide[3] or more likely just stick to Vercel and Railway kind of platforms. I don't know how that will impact AWS, we will all still use them, however a ton of small customers paying close to rack rate is definitely much much higher margin than what Vercel is paying AWS for the same workload is going to be. -- [1] https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html https://docs.aws.amazon.com/prescriptive-guidance/latest/pat... [2] this https://vercel.com/docs/connectivity/static-ips https://vercel.com/docs/connectivity/static-ips [3] Would be rare, obviously only if they have the skill experience to do so.
1dom 1y ago
> With some services I'd agree with you, but DynamoDB and Lambda are easily two of their 'simplest' to configure and understand services, and two of the ones that scale the easiest. IAM roles can be decently complicated, but that's really up to the user. If it's just 'let the Lambda talk to the table' it's simple enough. We agree, but also, I feel like you're missing my point: "let the Lambda talk to the table" is what quickstarts produce. To make a lambda talk to a table at scale in production, you'll want to setup your alerting and monitoring to notify you when you're getting close to your service limits. If you're not hitting service limits/quotas, you're not running even close to running at scale.

motorest 1y ago

> The idea you can click your way to a highly available, production configured anything in AWS - especially involving Dynamo, IAM and Lambda - is something I've only heard from people who've done AWS quickstarts but never run anything at scale in AWS. I'll bite. Explain exactly what work you think you need to do to get your pick of service running on Hetnzer to have equivalent fault-tolerance to, say, a DynamoDB Global Table created with the defaults.