Live data from Hacker News

Why doesn’t anyone weep for Docker?

techrepublic.com

201–210 of 248 posts

Re: Why doesn’t anyone weep for Docker?

#201
I don't get why k8s is the dominant scheduler. If you have a 3 ~ 6 person platform team that can set one up, or build a secure terraform of CFN codebase to establish an AWS/EKS system, they can be nice. But I've also worked at DCOS/marathon shops where it worked just as well.

The trouble with all these schedulers is they can't go from just one node (where scheduling and processes run on the same node .. and minikube is a hack; not a production system) to 100. You can't just setup a small k8s, and then add a node, and another node, and scale up. You go from a single docker system, to a big managed k8s system.

There needs to be more competition. It's the same deal with the dominance of systemd as the only system layer. Only the small startups seem to be using more lightweight stuff like Nomad, k3s, RancherOS (Rancher is mostly going the managed k8s solution anyway; even though they have their own k3s implementation).

A running k8s system can be okay, but there is a lot of room for improvement (in terms of making it simpler). Both DCOS and k8s seem to waste a lot of resources. Docker could have competed in this space, but everyone complained about all the bugs in Swarm and it never really went anywhere.

I did a writeup on container orchestration systems late last year:

https://penguindreams.org/blog/my-love-hate-relationship-wit...

Re: Why doesn’t anyone weep for Docker?

#202

Earlier quoted context omitted.

I agree. I had some VMs that I wanted to turn into containers. With LXC it was a breeze, and the result is very much like a "lightweight VM". Docker seems more like putting a single application process in a container, which is a very different thing. And if I want to do that, I'll seriously consider running the application in a unikernel (e.g. OSv) instead.

By the way, the lightweight VM project is currently the LXD by Ubuntu/Canonical.

Yeah, LXD is what I have been using. Maybe I should have said "LXC/LXD" instead of just "LXC".

Re: Why doesn’t anyone weep for Docker?

#203
post #96
post #73

Can anyone offer a good guide to DevOps for people who don't directly use these tools but work with engineers who do and would like to learn more? The whole ecosystem of servers, cloud infrastructure (and all of the different offerings there), Docker, Kubernetes, CICD tools etc is a bit overwhelming to get into.

Sure. None of the things you mentioned are DevOps. DevOps is two things: 1. Applying the methods of modern software development (version control, automation, DSLs...) to operations (provisioning, config, deployment, monitoring, backups...). 2. Reducing silo barriers between devs and ops groups so that everyone is working together as a team, rather than blaming each other for poor communication and the resulting messe…

I wish I could upvote this multiple times. Thanks for sharing your knowledge!

Re: Why doesn’t anyone weep for Docker?

#204
post #155
post #151

Earlier quoted context omitted.

In your experience, what is the strongest point of evidence leading to the successful utilization of k8s? > the company has a marketing team driving new development that needs to get to market fast At what point in the growth curve? Are your SRE shipping the new features, or running like a red queen to keep the product developers able to keep shipping? What development process or cycle has overheated with friction th…

:) Successful utilization of k8s, interesting metric, what is your criteria ? >At what point in the growth curve? I have seen properly staffed startups (in silicon valley) leverage the platform to pivot direction fast but overall I would say you need a large enterprise to support it. Ironically the large enterprise which could benefit the most wants to lay ITIL on top of k8s, call it agile and the methodologies confl…

All my mentions of issues or friction in my previous comment was about pre-k8s team's experiences... I try and clarify a few key cases in the following:

> Successful utilization of k8s, interesting metric, what is your criteria ?

Sorry, what pain motivated using k8s, and using k8s relieved that pain.

> I have seen properly staffed startups (in silicon valley)

What is 'proper' for staffing?

>> Are your SRE shipping the new features, or running like a red queen to keep the product developers able to keep shipping? > Yes to both

Is it the appropriate use of a Reliability engineer's skills to develop or change arbitrary features? Or are you saying they are at least Engineers so they should be able to pitch in everywhere... CSS accessibility features or k8s config.

>> What development process or cycle has overheated with friction that requires k8s? > Upgrading k8s :)

This tautology keeps me away from k8s. Before k8s what pain in the process required using k8s to solve?

> a pipeline getting product to production fast

Does k8s make it fast? Does k8s make it possible? I think I'm deploying "fast", without k8s... But because you keep mentioning ITIL I suppose it's more about the infrastructure changes? Or are you talking about ITIL tension because k8s requires a more liberal policy than ITIL allows?

There is so much assumed context when talking about k8s, the only comprehensible part of these discussions is k8s is a rabbit hole to end all rabbit holes.

Re: Why doesn’t anyone weep for Docker?

#205

Earlier quoted context omitted.

I think that, once you're going that far back in history, it's pretty critical to keep track of the GNU/Linux distinction. Linus just wrote a kernel. And then the GNU userland, which had already been in development since the mid 80s, but was still somewhat lacking a workable kernel, was adopted as the official userland to use with the Linux kernel. And at roughly the same time, IIRC, when Sun decided to migrate their…

Is this Richard Stallman? ;)

No, he wouldn't have called it GNU/Linux: https://www.sudosatirical.com/articles/richard-stallman-inte...

Re: Why doesn’t anyone weep for Docker?

#206

Earlier quoted context omitted.

It would surprise me if Linus even knew about Solaris when he worked on the first release of Linux. Solaris’ first release was in June 1992, with first use of the name in marketing materials in September 1991 ( https://en.wikipedia.org/wiki/Solaris_(operating_system)#His... ) Linus’ famous message was from the same time (September 17, 1991) Calling Linux an open source version of Minix is more appropriate, but it sti…

I think that, once you're going that far back in history, it's pretty critical to keep track of the GNU/Linux distinction. Linus just wrote a kernel. And then the GNU userland, which had already been in development since the mid 80s, but was still somewhat lacking a workable kernel, was adopted as the official userland to use with the Linux kernel. And at roughly the same time, IIRC, when Sun decided to migrate their…

The first Linux distribution I remember using was Slackware on floppy disks, at a time when building a kernel was pretty much necessary to get a working system. A great learning experience, all in all.

However, the point I'd like to make is that it was clear back then just how much was contributed directly by the GNU project, and also how favored GNU's GPL was by developers who wanted to contribute their work.

GNU really did seem like it was everything that made the Linux kernel act and feel like a Unix system, though I had no proper appreciation of that at the time.

Re: Why doesn’t anyone weep for Docker?

#207

Earlier quoted context omitted.

"git checkout X && git pull" ?

If I wanted to bring production down I'd just rm -rf / the database machines instead of using half-measures like that.

I'm just saying you don't need fancy CI-de-jour tech for a home project. If you're on the Atlassian stack Bamboo does pretty solid deployment/test/rollback. With a proper staging and QA environment even a large corp doesn't need much more than git.

Re: Why doesn’t anyone weep for Docker?

#208

Earlier quoted context omitted.

Just some minor clarifications: - DevOps is a peer with Agile and Lean. Scrum and XP are Agile implementations. Scrum doesn't prescribe ways to code, XP does. - 90% of what people develop or run today should be in containers, and not because containers are great, but because of the DevOps patterns of IaC, immutability, reproducibility, homogeneous environments. Whether you run them on your laptop, a VPC, AWS Fargate,…

>> 90% of what people develop or run today should be in containers, and not because containers are great, but because of the DevOps patterns of IaC, immutability, reproducibility, homogeneous environments Sorry but no. Container is __a__ way of achieving a small part of what you are talking about but not the only way. Break it down: - IaC: how do you containerise a load balancer? Terraform gives you infrastructure as…

> - IaC: how do you containerise a load balancer? Terraform gives you infrastructure as code without containers.

1) Terraform should be run in a container so that it will actually behave the way you expect, 2) containers are application environments built based on a Dockerfile, which makes it IaC.

> - immutability: VMs, AMIs are immutable just like containers are (discounting the entropy that happens in every OS)

True. But containers are easier and more portable, which is important to supporting the other aspects involved. Containers thus are a better general solution.

> - reproducibility: Same, VMs, AMI, Terraform, Ansible all give your that

Containers and VMs just... work. They're just collections of files. Very reproducible. Not 100% - you may need different guest drivers/kernels, different arguments to run your container in your particular system. But they're conceptually and operationally simple.

Terraform and Ansible are garbage fires of reproducibility and immutability. I could write a book on all the different ways these tools fail (most of it stemming from people trying to use them as interpreted programming languages, but also their designs are crap). There are whole frameworks built around Terraform and Ansible just to make sure they work right. They are overcomplicated, fragile bash scripts, and I'm quite frankly sick of using them. I think their entire existence is evidence of a huge gap in understanding how we should be operating systems today. [/rant]

> - homogeneous environments: Not sure what you mean by that [..] I am pretty sure you already have "heterogenous" environment

Those are opposites; homogeneous means "of uniform structure or composition throughout", heterogeneous means "consisting of dissimilar or diverse ingredients or constituents".

A homogeneous environment in a DevOps sense is when all environments have the same components and are operated the same way, and thus provide the closest results possible. This is incredibly important to prevent the classic "Well, it worked on my machine!" dev->production breakdown.

Homogeneous environments apply to lots of different things, but in the context of containers, they ensure that the environment the dev used to build the app is the same as what is in production. They also ensure that any scripts, tools, etc will use the same environment, if they are run in containers. I've wasted so much time in my career "correcting" heterogeneous environments in a bunch of different ways, whereas with containers the equivalent fix is "Please run the correct container version. Thanks"

The more systems you have, the more important this gets. At a certain point, the best choice is just to use baked VMs or containers for everything, everywhere, and containers are just so much easier, almost exclusively because Docker shoved so much extra useful functionality in. (I'll add that I do not necessarily like containers, but I do find them to be the most useful solution, because they solve the most problems in the most convenient ways)

Re: Why doesn’t anyone weep for Docker?

#209
post #160

Earlier quoted context omitted.

Please do me the favor of engaging with what I wrote.

I thought I did? Also, this feels a bit passive-aggressive, did I do something wrong?

It was meant to be polite. Under the guise of "clarifying" what I said, you completely contradicted it, without even doing me the courtesy of addressing my statements directly.

If it helps, my core point is:

DevOps is the name we give to two philosophical ideas. The first idea is that the tools and methods of software development can be used to improve our ability to do operations work. The second idea is that siloing people with operational skill away from people with development skill is a terrible practice.

Along the way, I specifically denounced the idea that DevOps is a single methodology, or that some tools are more DevOps than others, or that DevOps makes prescriptions about what you should do. Those are all things that you immediately advocated.

Re: Why doesn’t anyone weep for Docker?

#210

Earlier quoted context omitted.

What most enterprises think is DevOps is different from what dsr_ wrote. They have admins that maintain their pool of servers. They have developers that are fluent in the stack of their application. They decide they need to have some of that cloud, containers, CI/CD stuff. Turns out they need people who can write code that builds their programs, tests their programs, packages their programs, provisions cloud infrastr…

>> What most enterprises think You mean the companies we regularly fail every aspect of engineering? dsr_ summed up pretty well how Amazon and a bunch of companies think abut DevOps. Coincidentally these companies produce the highest grade of software, tools, services etc. >> Most of their admins say they are not programmers, so it's not their job. What you are describing is the 90s approach to IT. These companies di…

I was not talking about IT companies that produce h/w or s/w goods and services. I was talking about companies that produce other kinds of goods and services and insource or outsource IT services that support their value chain. They don't necessarily feel the same pressure to improve. I agree they are late adopters, but late adopters aren't stragglers. There will still be enough of them in 10 years time.
Post reply on HN