Date: Mon, 17 Apr 2023 14:11:12 -0500 From: Tim Daneliuk <tundra@tundraware.com> To: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: Docker Message-ID: <f73ef99d-7fa9-ed58-2ce7-80aa26462f79@tundraware.com> In-Reply-To: <1751079266.5066266.1681758046058@mail.yahoo.com> References: <20230329053443.6ADA6B6AFED5@dhcp-8e64.meeting.ietf.org> <CA%2B1FSijL50mQ-HveBA4HZeNkSoaORv=aty-15nNLzn9amzY_nw@mail.gmail.com> <6002f636-310b-a9fd-b82f-346618976983@timpreston.net> <CA%2B1FSigV_pPwVW%2BDd8WZYGcNQVt7%2BYOcsnJFoRhS6jL5A636pg@mail.gmail.com> <20230412150350.12f97eb2c9dd566b8c8702d2@sohara.org> <CA%2B1FSihVPCQ6tp8u=aqnLyyOPpCMrnhYGcC8bCUgRbFHTdY5sA@mail.gmail.com> <1535315680.2770963.1681309684072@mail.yahoo.com> <20230412155252.5e38ea4728bd52dc798852fc@sohara.org> <1d0a7ed1-9330-49df-9b66-9ee4387de511@app.fastmail.com> <78F4160A-2D26-4A22-9139-A9132FC42688@ellael.org> <20230417133223.3ef5e26c.freebsd@edvax.de> <CA%2B1FSihn%2BB6LTUm7gof6Nd=niL5=dMvQ46HUv=NJ2%2BNhcLS7RQ@mail.gmail.com> <989A99FE-5DA3-4346-B886-32F8E64BA6F0@nimnet.asn.au> <8714f66b-cd2a-2dd3-67ba-9313522ee1b6@tundrawar e.com> <1096316421.4975742.1681752853038@mail.yahoo.com> <e77a0575-2 38d-9ae7-2301-81e82d38a5be@tundraware.com> <1751079266.5066266.1681758046058@mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/17/23 14:00, Paul Pathiakis wrote: > > I was pretty crotchety when people started with containers and virtualization and... MICROSERVICES.... I was like: you do understand what a scheduler and time sharing are all about right? You know about UNIX, right? You do know about "nice" why would I want to put limits on some simulated machine and expect it will work better than the job control and scheduler of the kernel? I will say that having now spent the better part of a decade around microservices, docker, K8s, et al that the current state of that art allows for a lot of control around resource consumption and scaling/performance. K8s, in particular, gets away from the idea that you have to tune the host and instead allows you to think about optimizing the containers that run there. At least for business applications, the vast majority of the time, the throughput issues are far more about I/O constraints than they are CPU-bound or concurrency issues. Optimizing schedules, nice, pinning CPUs and all the rest make sense when your point of tuning is a single, monolithic kernel running a process model. But with K8s, you can think in terms of logically infinite capacity (at a price, of course) where your optimization surface is the service itself and the class of K8s pod you are running on. This model is not useful for everything. There have been attempts, for example, to decompose the FreeBSD kernel itself into a set of loosely coupled services coordinated via message passing. If memory services, this was the intent of DragonflyBSD but I'm not certain of that. "There are 20 ways to solve a problem. 3 of them will work well enough."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f73ef99d-7fa9-ed58-2ce7-80aa26462f79>