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.
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.
>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.
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?
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.
> 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.
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.
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.
so you build your docker images all by yourself using just a dockerfile and your statically linked app based on RHEL - for all that HIPPA and PCI compliance?? Iirc the current hottest shit of this shitshow (the dockerhub-using "ecosystem") was to use ansible in you docker builds because it's oh so declaratiev.
No, not just for HIPAA/PCI compliance, that's just one of the many benefits. Here's some more reasons why I love Convox, Kubernetes/ECS, Docker:
* Effortlessly achieve 100% uptime with rolling deploys
* Running a single command to spin up a new staging environment that is completely identical to production
* Easily spinning up identical infrastructure in a different AWS region (Europe, Asia, etc.)
* Easily spinning up infrastructure inside a customer's own AWS or Google Cloud account for on-premise installations
* Automatic SSL certificates for all services. Just define a domain name in your Convox configuration, and it will automatically creates a new SSL certificate in ACM and attach it to your load balancer.
* Automatic log management for all services
* Very easily being able to set up scheduled tasks with a few lines of configuration
* Being able to run some or all of my service on AWS Fargate instead of EC2 with a single command
* Ease of deploying almost any open source application in a few minutes (GitLab, Sentry, Zulip Chat, etc.)
well, I am not really interested in your convox-ads but more in your claim that it somehow makes the typical docker-workflow of running random-software from the net somehow HIPPA and PCI-compliant? That's an interesting claim, especially with your description of it as zero-effort.
No, Convox doesn't automatically make any application compliant. Convox makes it far easier to achieve HIPAA/PCI compliance by easily setting up compliant server infrastructure:
Note that dedicated instances are no longer required for HIPAA compliance [1]. Also note that the private Convox console is completely optional. You can achieve all of this with the free and open source convox/rack project: https://github.com/convox/rack
As I mentioned in my original comment, you still need to do a lot of work to set up company policies and make sure your application complies with all regulations.
You should also be aware that I'm comparing Convox with some other popular options for HIPAA-compliant hosting:
* Datica: https://datica.com (I think it starts around $2,000 per month, but not 100% sure)
These companies do provide some additional security and auditing features, but I think there's no reason to spend thousands of dollars per month when Convox can get you 95% of the way in your own AWS account. PLUS: If you have any free AWS credits from a startup program, you might not need to pay any hosting bills for years.
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.
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.