4 ms·

I don't agree with the last paragraph. Your C++ example is orthogonal to the deployment aspect because it discusses the application. Kubernetes and the fragile

by rocho 6y ago

I don't agree with the last paragraph. Your C++ example is orthogonal to the deployment aspect because it discusses the application. Kubernetes and the fragile shell scripts are about the deployment of said application. How are you going to deploy your C++ application? Both options are available, and I would wager that in most cases, Kubernetes makes more sense, unless you have strict requirements.

jrumbut 6y ago
In a world where your architecture is that simple I don't think kubernetes would be the choice for long. I think for the average application there's still something to be said for manual cross-layer optimization between infrastructure, application, and how both are deployed. What I mean is we can't yet draw too clear a line between the application and how it's deployed because there are real tradeoffs between keeping future options open and getting the product out the door. A strength of kubernetes is that if you get good at it it works for a variety of projects, but a lot of effort is needed to get to that point and that effort could have gone into something else.
- p_l 6y ago
  Even then there's the question of "where are the logs?" "how is the application deployed?" etc.
zelly 6y ago
Kubernetes is for orchestrating a distributed system. What I was suggesting is to (1) make a monolith and (2) make it fast, light and high-throughput. The goal of your service is to reliably serve users at scale; this is just another way of doing it, just much more esoteric. A "C++ monolith" allows me to potentially bypass a lot of this deployment stuff because it could serve lots (millions) of users from a single box.
- harpratap 6y ago
  >Kubernetes is for orchestrating a distributed system. No it's not. You can use it to run bunch of monoliths too. K8s provides a common API layer that all of your organisation can adhere to. Just like containers are a generic encapsulation of any runable code.
  - lr4444lr 6y ago
    Sure, but you could just use plain Docker for the monolith. Containerization isn't the issue. If you're not orchestrating and connecting an array of services, what's the value add of K8s?
    - harpratap 6y ago
      Standardization of deployment logic, configuration management, networking, rbac policies, ACL rules, etc etc. across on-prem or any cloud provider. I can leave my current job, jump into a new one and start providing value within less than couple of days. Compared that to spending weeks if not months trying to understand their special snowflake of an infrastructure solving the same problems already solved a million times before.
- tsss 6y ago
  > A "C++ monolith" allows me to potentially bypass a lot of this deployment stuff No it doesn't. Let's assume you write that application as a C++ monolith. Congratulations, you now have source code that could potentially serve 10k users on a toaster... If only you could get it onto that toaster. How are you going to start the databases it needs? How are you going to restart it when it crashes, or worse: When it still runs but is unresponsive. How are you going to upgrade it to a new version without downtime? How are you going to do canary releases to catch bugs early in production without affecting all users? How do you roll back your infrastructure when there is an issue in production? How do you notice when your toaster server diverges from it's desired state? How do you handle authorization to be compliant with privacy regulations? I'd love to see that simple and safe shell script of yours which handles all those use cases. I'm sure you could sell it for quite a bit of money. What you fail to understand is that k8s never was about efficiency. Your monolith may work at 10k users with a higher efficiency but it can never scale to a million. At some point you can't buy any bigger toasters and have no choice but to make a distributed system. Besides, microservice vs monolith is orthogonal to using k8s.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - mrmonkeyman 6y ago
    Handling 1-5 "toasters" instead of 2.500 "microservices" is a piece of f'ing cake. You don't need orchestration. Sure, you have to actually understand the system and low-wage workers are probably not a good fit, but don't make this about engineering because it has nothing to do with it. Simple SaaSes with 500 users running on 500 servers is now the norm. Sure, then you need to get creative. The commenter referred to serving million users with a single digit amount of boxes. It is easy, it is possible. It requires you to actually know things though.
- nathan_f77 6y ago
  I run a Dockerized monolithic application in ECS, and I'll be switching to Kubernetes soon. I am 100% sold on this approach and will never go back to any deployment methods that I've used in the past (Capistrano, Ansible, Chef, Puppet, Saltstack, etc.) I use Convox [1] which makes everything extremely simple and easy to set up on any Cloud provider. They have some paid options, but their convox/rack [2] project is completely free and open source. I manage everything from the command-line and don't use their web UI. It's just as easy as Heroku: convox rack install aws production convox apps create my_app convox env set FOO=bar convox deploy You can also run a single command to set up a new RDS database, Redis instance, S3 bucket, etc. Convox manages absolutely everything: secure VPC, application load balancer, SSL certificates, logs sent to CloudWatch, etc. You can also set up a private rack where none of your instances have a public IP address, and all traffic is sent through a NAT gateway: convox rack params set Private=true This single command sets up HIPAA and PCI compliant server infrastructure out of the box. Convox automatically creates all the required infrastructure and migrates your containers onto new EC2 instances. All with zero downtime. Now, all you need to do is sign a BAA with AWS and make sure your application and company complies with regulations (access control, encryption, audit logs, company policies, etc.) I run a simple monolithic application where I build a single Docker image, and I run this in multiple Docker containers across 3+ EC2 instances. This has made it incredibly easy to maintain 100% uptime for over 2 years. There were a few times where I've had to fix some things in CloudFormation or roll back a failed deploy, but I've never had any downtime. My Docker images would be much smaller and faster if I built my backend server with C++ or Rust instead of Ruby on Rails. But I would absolutely still package a C++ application in a Docker image and use ECS / Kubernetes to manage my infrastructure. I think the main benefit of Docker is that you can build and re-use consistent images across CI, development, staging, and production. So all of my Debian packages are exactly the same version, and now I spend almost zero time trying to debug strange issues that only happen on CI, etc. So now I already know I want to use Docker because of all these benefits, and the next question is just "How can I run my Docker containers in production?". Kubernetes just happens to be the best option. The next question is "What's the easiest way to set up Docker and Kubernetes?" Convox is the holy grail. The application language or framework isn't really relevant to the discussion. [1] https://convox.com https://convox.com [2] https://github.com/convox/rack https://github.com/convox/rack P.S. Things move really fast in this ecosystem, so I wouldn't be surprised if there are some other really good options. But Convox has worked really well for me over the last few years.
- CyanLite2 6y ago
  You're totally confusing performance/throughput with reliability. No, "a single box" is NOT reliable.

by rocho 6y ago

jrumbut 6y ago

In a world where your architecture is that simple I don't think kubernetes would be the choice for long. I think for the average application there's still something to be said for manual cross-layer optimization between infrastructure, application, and how both are deployed. What I mean is we can't yet draw too clear a line between the application and how it's deployed because there are real tradeoffs between keeping future options open and getting the product out the door. A strength of kubernetes is that if you get good at it it works for a variety of projects, but a lot of effort is needed to get to that point and that effort could have gone into something else.

p_l 6y ago
Even then there's the question of "where are the logs?" "how is the application deployed?" etc.

zelly 6y ago

Kubernetes is for orchestrating a distributed system. What I was suggesting is to (1) make a monolith and (2) make it fast, light and high-throughput. The goal of your service is to reliably serve users at scale; this is just another way of doing it, just much more esoteric. A "C++ monolith" allows me to potentially bypass a lot of this deployment stuff because it could serve lots (millions) of users from a single box.

harpratap 6y ago
>Kubernetes is for orchestrating a distributed system. No it's not. You can use it to run bunch of monoliths too. K8s provides a common API layer that all of your organisation can adhere to. Just like containers are a generic encapsulation of any runable code.
- lr4444lr 6y ago
  Sure, but you could just use plain Docker for the monolith. Containerization isn't the issue. If you're not orchestrating and connecting an array of services, what's the value add of K8s?
  - harpratap 6y ago
    Standardization of deployment logic, configuration management, networking, rbac policies, ACL rules, etc etc. across on-prem or any cloud provider. I can leave my current job, jump into a new one and start providing value within less than couple of days. Compared that to spending weeks if not months trying to understand their special snowflake of an infrastructure solving the same problems already solved a million times before.
tsss 6y ago
> A "C++ monolith" allows me to potentially bypass a lot of this deployment stuff No it doesn't. Let's assume you write that application as a C++ monolith. Congratulations, you now have source code that could potentially serve 10k users on a toaster... If only you could get it onto that toaster. How are you going to start the databases it needs? How are you going to restart it when it crashes, or worse: When it still runs but is unresponsive. How are you going to upgrade it to a new version without downtime? How are you going to do canary releases to catch bugs early in production without affecting all users? How do you roll back your infrastructure when there is an issue in production? How do you notice when your toaster server diverges from it's desired state? How do you handle authorization to be compliant with privacy regulations? I'd love to see that simple and safe shell script of yours which handles all those use cases. I'm sure you could sell it for quite a bit of money. What you fail to understand is that k8s never was about efficiency. Your monolith may work at 10k users with a higher efficiency but it can never scale to a million. At some point you can't buy any bigger toasters and have no choice but to make a distributed system. Besides, microservice vs monolith is orthogonal to using k8s.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- mrmonkeyman 6y ago
  Handling 1-5 "toasters" instead of 2.500 "microservices" is a piece of f'ing cake. You don't need orchestration. Sure, you have to actually understand the system and low-wage workers are probably not a good fit, but don't make this about engineering because it has nothing to do with it. Simple SaaSes with 500 users running on 500 servers is now the norm. Sure, then you need to get creative. The commenter referred to serving million users with a single digit amount of boxes. It is easy, it is possible. It requires you to actually know things though.
nathan_f77 6y ago
I run a Dockerized monolithic application in ECS, and I'll be switching to Kubernetes soon. I am 100% sold on this approach and will never go back to any deployment methods that I've used in the past (Capistrano, Ansible, Chef, Puppet, Saltstack, etc.) I use Convox [1] which makes everything extremely simple and easy to set up on any Cloud provider. They have some paid options, but their convox/rack [2] project is completely free and open source. I manage everything from the command-line and don't use their web UI. It's just as easy as Heroku: convox rack install aws production convox apps create my_app convox env set FOO=bar convox deploy You can also run a single command to set up a new RDS database, Redis instance, S3 bucket, etc. Convox manages absolutely everything: secure VPC, application load balancer, SSL certificates, logs sent to CloudWatch, etc. You can also set up a private rack where none of your instances have a public IP address, and all traffic is sent through a NAT gateway: convox rack params set Private=true This single command sets up HIPAA and PCI compliant server infrastructure out of the box. Convox automatically creates all the required infrastructure and migrates your containers onto new EC2 instances. All with zero downtime. Now, all you need to do is sign a BAA with AWS and make sure your application and company complies with regulations (access control, encryption, audit logs, company policies, etc.) I run a simple monolithic application where I build a single Docker image, and I run this in multiple Docker containers across 3+ EC2 instances. This has made it incredibly easy to maintain 100% uptime for over 2 years. There were a few times where I've had to fix some things in CloudFormation or roll back a failed deploy, but I've never had any downtime. My Docker images would be much smaller and faster if I built my backend server with C++ or Rust instead of Ruby on Rails. But I would absolutely still package a C++ application in a Docker image and use ECS / Kubernetes to manage my infrastructure. I think the main benefit of Docker is that you can build and re-use consistent images across CI, development, staging, and production. So all of my Debian packages are exactly the same version, and now I spend almost zero time trying to debug strange issues that only happen on CI, etc. So now I already know I want to use Docker because of all these benefits, and the next question is just "How can I run my Docker containers in production?". Kubernetes just happens to be the best option. The next question is "What's the easiest way to set up Docker and Kubernetes?" Convox is the holy grail. The application language or framework isn't really relevant to the discussion. [1] https://convox.com https://convox.com [2] https://github.com/convox/rack https://github.com/convox/rack P.S. Things move really fast in this ecosystem, so I wouldn't be surprised if there are some other really good options. But Convox has worked really well for me over the last few years.
CyanLite2 6y ago
You're totally confusing performance/throughput with reliability. No, "a single box" is NOT reliable.