5 ms·

Same question. I'm a one man band who wants to be scalable, but doesn't want to get married to a particular cloud. So Kubernetes appears to be the default recom

Same question. I'm a one man band who wants to be scalable, but doesn't want to get married to a particular cloud. So Kubernetes appears to be the default recommendation. Are there better alternatives?

vorpalhex 1y ago
Docker compose, docker swarm if you outgrow that.
- herval 1y ago
  I tried that in the past and found it extremely unreliable as a production environment. Documentation was also non-existent and I'd have to manually handle clusters, setup my own observability and log stack, etc. Any cloud provider these days gives you all that out of the box for K8s, so I'm, not sure the time one would invest on Swarm really makes sense?
  - vorpalhex 1y ago
    You will be married to a particular cloud. Either you go all in on someones setup or you get to do it all yourself. That's true for any service. Either you drink the AWS/GCP/Axure koolaid or you make your own. Whether it's k8s or Swarm or whatever doesn't matter.
    - JustExAWS 1y ago
      Out of the long list of things a five person startup needs to be worried about, “cloud lock in” doesn’t make the top 10 or even top 20.
      - vorpalhex 1y ago
        Dolla bills. Cloud LockIn is Price LockIn. Last startup I was in 5x'd our runway by using dynamic spot pricing across multiple clouds. Also sounds like the software has to support multiple clouds to sell to clients.
        JustExAWS 1y ago
        This startup is probably just a web server though. Let’s not pretend that multi cloud doesn’t have administration cost, network latency when using one cloud your data can literally be on the same server rack as your compute if you need it to be at best or at worse be in the same data center. That also begs the question if you need the cheapest costs possible, wouldn’t you be better off at a colo and have your processing and data in the same data center and not have to spend extra on cloud costs?
    - dangus 1y ago
      It’s not really black and white as you describe it, there’s a huge spectrum between “do it all yourself” and “go all in on someone’s setup.” Different cloud services have different levels of difficulty in migrating in or out of them. You can also mix levels of abstraction for different layers of your product. For example, you can host something on a bare EC2 instance fronted by nginx (let’s encrypt for certs) with an RDS database and that’s going to be far more portable to someone else’s cloud than deploying to Lambda behind an ALB using AWS certificate manager. You still didn’t “do it all yourself” because RDS still took a solid chunk of your work away even though you did nginx and your deployment to EC2 on your own. In the case of RDS it’s one of the more trivial services to move to another provider or move to bare metal since you’re just running a standard database and all your app needs is a connection string. (I’m not claiming this is a real architecture that makes sense, just an example of how different layers can be chosen to be managed or unmanaged).
      - vorpalhex 1y ago
        Unless you start using a non-portable RDS feature. Or you set up RDS auth using the preferred AWS method which is non-portable. Or you come to depend on a performance feature of RDS hosting. Or..
        dangus 1y ago
        1. Rare, and easy to avoid, even if using Aurora. Anything without "Aurora" in the name is a plain database engine with no Amazon customization (e.g., PostgreSQL). 2. Not correct, IAM authentication is not the preferred connection method, and it has a performance limit of 200 connections per second. It's intended for access by humans and not by your applications. In my experience I've never seen any organization set it up. The other authentication methods are not AWS specific (Kerberos/password auth). Easy to avoid. 3. Most performance features of RDS have some kind of non-AWS equivalent. AWS isn't reinventing the wheel as a database host.
more_corn 1y ago
Heroku Vercel AWS ECS What’s your business? Do you have product market fit? Do you benefit enough from the three things K8S does well to pay the cost in increased complexity, reduced visibility, and increased toil? If you can’t immediately rattle off those three things, you don’t need it. Don’t you want to just focus on the problem you’re solving for your customers and not the infrastructure that makes your app go? Every startup I’ve seen doing k8s should not have been. Every startup I’ve seen not using k8s didn’t need it. (Except a startup who moved from beanstalk which nobody should ever use, and they could have done better by moving to something like ecs) I’ve seen a startup lose their entire DevOps team and successfully go a year without it because their core app was on heroku. What’s that worth in dollars? What are those dollars worth in opportunity cost?
otterley 1y ago
> I'm a one man band who wants to be scalable, but doesn't want to get married to a particular cloud. (AWS employee, but opinions are my own) Just pick a cloud provider and move on. All of the top-tier providers can scale. Choose the one you're most comfortable with and move on. Focus on the things that matter for your business like building the right product and getting customers. If you have regret later, it's going to be because you were so wildly successful that it is now an actual business risk and/or your customers demand it. But don't make this decision based on a problem you don't have and are unlikely to have in the next 12-24 months, if ever. Cloud agnosticism is rarely a functional or strategic requirement of any given business, and it's usually very expensive to implement--more than any savings you might achieve by pitting providers against each other (which you can't do anyway unless you are big enough to be a strategic customer).
- delichon 1y ago
  I'm writing a public statement platform, and a core design priority is to avoid being Parlered, since human moderation is not an option. Responding to court orders is inevitable, but responding to cloud provider demands isn't quite, yet.
  - dangus 1y ago
    The thing is that avoiding cloud vendor “lock-in” won’t necessarily help you here. If it isn’t cloud provider demands it’ll be someone else involved in serving your content, could go all the way down to your ISP.

vorpalhex 1y ago

Docker compose, docker swarm if you outgrow that.

herval 1y ago
I tried that in the past and found it extremely unreliable as a production environment. Documentation was also non-existent and I'd have to manually handle clusters, setup my own observability and log stack, etc. Any cloud provider these days gives you all that out of the box for K8s, so I'm, not sure the time one would invest on Swarm really makes sense?
- vorpalhex 1y ago
  You will be married to a particular cloud. Either you go all in on someones setup or you get to do it all yourself. That's true for any service. Either you drink the AWS/GCP/Axure koolaid or you make your own. Whether it's k8s or Swarm or whatever doesn't matter.
  - JustExAWS 1y ago
    Out of the long list of things a five person startup needs to be worried about, “cloud lock in” doesn’t make the top 10 or even top 20.
    - vorpalhex 1y ago
      Dolla bills. Cloud LockIn is Price LockIn. Last startup I was in 5x'd our runway by using dynamic spot pricing across multiple clouds. Also sounds like the software has to support multiple clouds to sell to clients.
      - JustExAWS 1y ago
        This startup is probably just a web server though. Let’s not pretend that multi cloud doesn’t have administration cost, network latency when using one cloud your data can literally be on the same server rack as your compute if you need it to be at best or at worse be in the same data center. That also begs the question if you need the cheapest costs possible, wouldn’t you be better off at a colo and have your processing and data in the same data center and not have to spend extra on cloud costs?
  - dangus 1y ago
    It’s not really black and white as you describe it, there’s a huge spectrum between “do it all yourself” and “go all in on someone’s setup.” Different cloud services have different levels of difficulty in migrating in or out of them. You can also mix levels of abstraction for different layers of your product. For example, you can host something on a bare EC2 instance fronted by nginx (let’s encrypt for certs) with an RDS database and that’s going to be far more portable to someone else’s cloud than deploying to Lambda behind an ALB using AWS certificate manager. You still didn’t “do it all yourself” because RDS still took a solid chunk of your work away even though you did nginx and your deployment to EC2 on your own. In the case of RDS it’s one of the more trivial services to move to another provider or move to bare metal since you’re just running a standard database and all your app needs is a connection string. (I’m not claiming this is a real architecture that makes sense, just an example of how different layers can be chosen to be managed or unmanaged).
    - vorpalhex 1y ago
      Unless you start using a non-portable RDS feature. Or you set up RDS auth using the preferred AWS method which is non-portable. Or you come to depend on a performance feature of RDS hosting. Or..
      - dangus 1y ago
        1. Rare, and easy to avoid, even if using Aurora. Anything without "Aurora" in the name is a plain database engine with no Amazon customization (e.g., PostgreSQL). 2. Not correct, IAM authentication is not the preferred connection method, and it has a performance limit of 200 connections per second. It's intended for access by humans and not by your applications. In my experience I've never seen any organization set it up. The other authentication methods are not AWS specific (Kerberos/password auth). Easy to avoid. 3. Most performance features of RDS have some kind of non-AWS equivalent. AWS isn't reinventing the wheel as a database host.

more_corn 1y ago

Heroku Vercel AWS ECS What’s your business? Do you have product market fit? Do you benefit enough from the three things K8S does well to pay the cost in increased complexity, reduced visibility, and increased toil? If you can’t immediately rattle off those three things, you don’t need it. Don’t you want to just focus on the problem you’re solving for your customers and not the infrastructure that makes your app go? Every startup I’ve seen doing k8s should not have been. Every startup I’ve seen not using k8s didn’t need it. (Except a startup who moved from beanstalk which nobody should ever use, and they could have done better by moving to something like ecs) I’ve seen a startup lose their entire DevOps team and successfully go a year without it because their core app was on heroku. What’s that worth in dollars? What are those dollars worth in opportunity cost?

otterley 1y ago

> I'm a one man band who wants to be scalable, but doesn't want to get married to a particular cloud. (AWS employee, but opinions are my own) Just pick a cloud provider and move on. All of the top-tier providers can scale. Choose the one you're most comfortable with and move on. Focus on the things that matter for your business like building the right product and getting customers. If you have regret later, it's going to be because you were so wildly successful that it is now an actual business risk and/or your customers demand it. But don't make this decision based on a problem you don't have and are unlikely to have in the next 12-24 months, if ever. Cloud agnosticism is rarely a functional or strategic requirement of any given business, and it's usually very expensive to implement--more than any savings you might achieve by pitting providers against each other (which you can't do anyway unless you are big enough to be a strategic customer).

delichon 1y ago
I'm writing a public statement platform, and a core design priority is to avoid being Parlered, since human moderation is not an option. Responding to court orders is inevitable, but responding to cloud provider demands isn't quite, yet.
- dangus 1y ago
  The thing is that avoiding cloud vendor “lock-in” won’t necessarily help you here. If it isn’t cloud provider demands it’ll be someone else involved in serving your content, could go all the way down to your ISP.