4 ms·

I wrote a satirical blog post on Docker/k8s in 2015 [1]. At the time, I actually felt docker was the future, but it became clear over the next few years that it

I wrote a satirical blog post on Docker/k8s in 2015 [1]. At the time, I actually felt docker was the future, but it became clear over the next few years that it was too much. The complexity of docker /infra/devops is overwhelming, and something much much simpler is clearly needed. I don't know if Dark (my startup trying to solve this) is going to take over, but it's pretty clear that the current complexity is unsustainable. This goes double if recession/layoffs/etc is happening due to COVID. People are going to need to spend a lot less on engineering, and the amount being spent on engineers that maintain infra is an obvious starting point. I would expect people to switch to much simpler infrastructures, and reduce the complexities of their stacks by necessity. [1] https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/

rozhok 7y ago
>The complexity of docker /infra/devops is overwhelming, and something much much simpler is clearly needed. I'm very disappointed with the fact that now one cares about simplicity nowadays. Everyone gets excited by k8s, then gets excited about tools around it (k3s, kops, helm, etc, etc) but no one understands that those are incredible complex tools with high cognitive overload. This is 2020. Why do I have to think about 'containers' and 'nodes', why do I have to wait 30 mins while my pipeline will build image and trigger k8s to redeploy the things, why do I have bother with tons of YAML? 10 years back we've got Heroku and surprizingly no one tries to disrupt the space of infrastructure simplifying then. Everyone just tries to get things more and more complex. The Dark ecosystem is perfect example of what backend should be. I don't agree that we need new language though, but at least Dark tries to solve complexity. While others just bring more and more leaky abstractions to the table. Even your comment doesn't received any response. Why? People don't like to get they code just to work without all the infrastructure burden? I really really don't get it.
taylodl 7y ago
Be careful. The whole point of Docker/k8s was to simplify operational complexity - and to that end it's done a great job. Yes k8s has complexity, but it's a known and knowable complexity vs. the unknown complexities of the processes of yore. Does that mean there can't be improvements? Of course not. If you're working on simplifying things even further then great. But I'm concerned with your ability to execute if you believe Docker/k8s have made things more complicated because that signals to me you may not realize where the complexities lie. Meanwhile I'd love to hear about your ideas to make things less complex.
- myu701 7y ago
  > Yes k8s has complexity, but it's a known and knowable complexity vs. the unknown complexities of the processes of yore. TL;DR -> I see what you are saying, but there are methods to make your infrastructure consistent and keep the manual drift away that do not require k8s-level complexity. Both for monoliths and microservices. Because we talk of the processes of yore, I will use a simple application architecture in the form of a web site that clients access that CNAMEs to a load balancer. The load balancer distributes traffic to web servers, which each make back-end connections to a database. This could also be load balancer to hosts that just run single-host instances of docker CE/EE as well - microservices can be done through this setup as well. If they are designed correctly, they shouldn't "need" to all be in one cluster, after all, these are durable microservices, not sharded bits of a monolith, right? :) You have 4 basic tools, which with not a lot of thought can be used as a foundational platform for many, many workloads. Aside from your codebase, you have the following (and/or their competitors) Hashicorp Terraform JetBrains TeamCity Octopus Deploy With a build server, a deployment platform, and a configuration management platform, you can get 98% of 'web scale' (all the scale you are really gonna get + plenty of runway for all but the FAANGs among us) for WAY less daily cognitive load. This applies to the DevOps team, the developers, the support cannon fodder (note if this is too true, and you are in leadership - please help this by empowering your cannon fodder), the DBAs, all of 'em. 1. Programmers check in their code to source 2. TeamCity runs unit/integration/regression tests. Pass? Publish to nuget feed for Octopus 3. Terraform sets up automated DB, web server, load balancer infrastructure for the servers, configured for whatever your company's definition of 'production server' is 4. Octopus deploy takes the newest build artifact from TC nuget package and deploys it to those servers. In the above process, if you need to scale up: 1. modify the count of web servers in terraform 2. Terraform apply 3. wait for TF to complete its provisioning of new servers 4. wait for Octopus to recognize the new servers as deployment targets for your code (in this scenario, you write TF such that it will install the Octopus agent and set deployment target) 5. Deploy your code to the new servers 6. Have Terraform reconfigure the load balancer to expect these web servers to work but start in a disabled state 7. the load balancer will detect they are now passing health checks, enable them, and poof, they are serving traffic. You have infrastructure as code, you have CICD, you have scalability for miles, and not a docker registry, helm chart, istio policy, or rancher needed. Best of all, your helpdesk, intern developers, even non-tech managers can cognitively follow the process. Need to patch? Cattle, not pets says: 1. Terraform: reconfigure load balancer to drain connections on the boxes to patch 2. Terraform: reconfigure lb to remove from LB when done 3. Terraform: destroy the boxes 4. Terraform: spin me up same number of new boxes. Using packer or a fresh AMI, the new box will be patched, then have TF set configs, install etc. as done with the original boxes 5. Octopus: deploy code to all known web servers 6. TF: add boxes to load balancer PS: sorry this grew into a wannabe blog post with handwave set to maximum.

rozhok 7y ago

>The complexity of docker /infra/devops is overwhelming, and something much much simpler is clearly needed. I'm very disappointed with the fact that now one cares about simplicity nowadays. Everyone gets excited by k8s, then gets excited about tools around it (k3s, kops, helm, etc, etc) but no one understands that those are incredible complex tools with high cognitive overload. This is 2020. Why do I have to think about 'containers' and 'nodes', why do I have to wait 30 mins while my pipeline will build image and trigger k8s to redeploy the things, why do I have bother with tons of YAML? 10 years back we've got Heroku and surprizingly no one tries to disrupt the space of infrastructure simplifying then. Everyone just tries to get things more and more complex. The Dark ecosystem is perfect example of what backend should be. I don't agree that we need new language though, but at least Dark tries to solve complexity. While others just bring more and more leaky abstractions to the table. Even your comment doesn't received any response. Why? People don't like to get they code just to work without all the infrastructure burden? I really really don't get it.

taylodl 7y ago

Be careful. The whole point of Docker/k8s was to simplify operational complexity - and to that end it's done a great job. Yes k8s has complexity, but it's a known and knowable complexity vs. the unknown complexities of the processes of yore. Does that mean there can't be improvements? Of course not. If you're working on simplifying things even further then great. But I'm concerned with your ability to execute if you believe Docker/k8s have made things more complicated because that signals to me you may not realize where the complexities lie. Meanwhile I'd love to hear about your ideas to make things less complex.

myu701 7y ago
> Yes k8s has complexity, but it's a known and knowable complexity vs. the unknown complexities of the processes of yore. TL;DR -> I see what you are saying, but there are methods to make your infrastructure consistent and keep the manual drift away that do not require k8s-level complexity. Both for monoliths and microservices. Because we talk of the processes of yore, I will use a simple application architecture in the form of a web site that clients access that CNAMEs to a load balancer. The load balancer distributes traffic to web servers, which each make back-end connections to a database. This could also be load balancer to hosts that just run single-host instances of docker CE/EE as well - microservices can be done through this setup as well. If they are designed correctly, they shouldn't "need" to all be in one cluster, after all, these are durable microservices, not sharded bits of a monolith, right? :) You have 4 basic tools, which with not a lot of thought can be used as a foundational platform for many, many workloads. Aside from your codebase, you have the following (and/or their competitors) Hashicorp Terraform JetBrains TeamCity Octopus Deploy With a build server, a deployment platform, and a configuration management platform, you can get 98% of 'web scale' (all the scale you are really gonna get + plenty of runway for all but the FAANGs among us) for WAY less daily cognitive load. This applies to the DevOps team, the developers, the support cannon fodder (note if this is too true, and you are in leadership - please help this by empowering your cannon fodder), the DBAs, all of 'em. 1. Programmers check in their code to source 2. TeamCity runs unit/integration/regression tests. Pass? Publish to nuget feed for Octopus 3. Terraform sets up automated DB, web server, load balancer infrastructure for the servers, configured for whatever your company's definition of 'production server' is 4. Octopus deploy takes the newest build artifact from TC nuget package and deploys it to those servers. In the above process, if you need to scale up: 1. modify the count of web servers in terraform 2. Terraform apply 3. wait for TF to complete its provisioning of new servers 4. wait for Octopus to recognize the new servers as deployment targets for your code (in this scenario, you write TF such that it will install the Octopus agent and set deployment target) 5. Deploy your code to the new servers 6. Have Terraform reconfigure the load balancer to expect these web servers to work but start in a disabled state 7. the load balancer will detect they are now passing health checks, enable them, and poof, they are serving traffic. You have infrastructure as code, you have CICD, you have scalability for miles, and not a docker registry, helm chart, istio policy, or rancher needed. Best of all, your helpdesk, intern developers, even non-tech managers can cognitively follow the process. Need to patch? Cattle, not pets says: 1. Terraform: reconfigure load balancer to drain connections on the boxes to patch 2. Terraform: reconfigure lb to remove from LB when done 3. Terraform: destroy the boxes 4. Terraform: spin me up same number of new boxes. Using packer or a fresh AMI, the new box will be patched, then have TF set configs, install etc. as done with the original boxes 5. Octopus: deploy code to all known web servers 6. TF: add boxes to load balancer PS: sorry this grew into a wannabe blog post with handwave set to maximum.