20 ms·

I can do all of the stacks well, including serverless described or pure ECS Fargate or Kubernetes. From my experience Kubernetes is the most complex with most

by moltar 1y ago

I can do all of the stacks well, including serverless described or pure ECS Fargate or Kubernetes. From my experience Kubernetes is the most complex with most foot guns and most churn.

cybrox 1y ago
Is it? If you compare to serverless, you'd almost have to compare AWS EKS Fargate and with that, there's a lot less operational overload. You still have to learn ingress, logging, networking, etc. but you'd have to do that with serverless as well. I'd argue between AWS serverless and AWS EKS fargate, the initial complexity is about the same. But serverless is a lot harder to scale cost efficiently and not accidentally go wild with function or sns loops.
- dontlaugh 1y ago
  ECS Fargate is simple to set up and scales just fine.
  - NomDePlum 1y ago
    This is my experience too. We served fairly complex data requests, around 200,00 per day, for mobile and commercial users using ECS Fargate and Aurora Postgres as our main technologies and it coped fine. Used Golang and optimised our queries and data structures and rarely needed more than 2 of whatever the smallest ECS Fargate task size is, but if we did it scaled in and out without any issues. Realise that isn't at scale for some but it's probably a relatively common point for a lot of use cases. We put some effort into maintenance, mostly ensuring we kept on an upgrade path but barely touched the infrastructure code other than that. One thing we did do was limit the number of other AWS services we adopted and kept it fairly basic. Seen plenty of other teams go down the rabbit hole.
    - Incipient 1y ago
      >Realise that isn't at scale for some This is one thing that REALLY frustrates me about enterprise. So often the c-suite wants to push for going cloud platforms (aws, azure, snowflake, along with all the costs, "because they need it". It's this narrative of scale that drives these discussions - so few companies are genuinely dealing with 200,000 requests per day!
      - NomDePlum 1y ago
        There are lots of valid business cases for cloud. Scale is way down the list on most. To be fair for this sites audience if there are true startup ambitions it "might" push it higher up than more normal use cases.
        Incipient 1y ago
        Genuine question - have you come across good/useful case studies/summaries of going cloud? All I can really get is "pretty toys", "everyone is going cloud", "we don't need to have network engineers (we now need azure network engineers)", etc.
        NomDePlum 1y ago
        I haven't I'm afraid. I have been involved in several cloud migrations of existing systems. These where all successful and a lot was driven by not having to own and manage the underlying servers and/or the need to replace aged systems at the very last point possible. Like most things understanding the rationale and desired outcome are key. One of the things you get from going to cloud is, as you point out, is a wider group of people who already know and understand key parts of the architecture/infrastructure choices.

by moltar 1y ago

I can do all of the stacks well, including serverless described or pure ECS Fargate or Kubernetes. From my experience Kubernetes is the most complex with most foot guns and most churn.

cybrox 1y ago

Is it? If you compare to serverless, you'd almost have to compare AWS EKS Fargate and with that, there's a lot less operational overload. You still have to learn ingress, logging, networking, etc. but you'd have to do that with serverless as well. I'd argue between AWS serverless and AWS EKS fargate, the initial complexity is about the same. But serverless is a lot harder to scale cost efficiently and not accidentally go wild with function or sns loops.

dontlaugh 1y ago
ECS Fargate is simple to set up and scales just fine.
- NomDePlum 1y ago
  This is my experience too. We served fairly complex data requests, around 200,00 per day, for mobile and commercial users using ECS Fargate and Aurora Postgres as our main technologies and it coped fine. Used Golang and optimised our queries and data structures and rarely needed more than 2 of whatever the smallest ECS Fargate task size is, but if we did it scaled in and out without any issues. Realise that isn't at scale for some but it's probably a relatively common point for a lot of use cases. We put some effort into maintenance, mostly ensuring we kept on an upgrade path but barely touched the infrastructure code other than that. One thing we did do was limit the number of other AWS services we adopted and kept it fairly basic. Seen plenty of other teams go down the rabbit hole.
  - Incipient 1y ago
    >Realise that isn't at scale for some This is one thing that REALLY frustrates me about enterprise. So often the c-suite wants to push for going cloud platforms (aws, azure, snowflake, along with all the costs, "because they need it". It's this narrative of scale that drives these discussions - so few companies are genuinely dealing with 200,000 requests per day!
    - NomDePlum 1y ago
      There are lots of valid business cases for cloud. Scale is way down the list on most. To be fair for this sites audience if there are true startup ambitions it "might" push it higher up than more normal use cases.
      - Incipient 1y ago
        Genuine question - have you come across good/useful case studies/summaries of going cloud? All I can really get is "pretty toys", "everyone is going cloud", "we don't need to have network engineers (we now need azure network engineers)", etc.
        NomDePlum 1y ago
        I haven't I'm afraid. I have been involved in several cloud migrations of existing systems. These where all successful and a lot was driven by not having to own and manage the underlying servers and/or the need to replace aged systems at the very last point possible. Like most things understanding the rationale and desired outcome are key. One of the things you get from going to cloud is, as you point out, is a wider group of people who already know and understand key parts of the architecture/infrastructure choices.