Starting redis manually isn't that much harder though:

    brew install redis
    redis-server

I personally feel that people reach for Docker too quickly. It's worthwhile to learn how things actually work so that you know what to do when Docker eventually fails you.

For me, it's less about the ease of starting one thing than it is the ease of juggling a lot of things. I've got docker containers on my machine for multiple work projects and a few organizations I do volunteer dev work for. Between them, I'm running two versions each of Ruby and Python and a number of instances of Postgres and MySQL, plus local Redis containers for three separate projects. Shifting between them is as simple as docker-compose down/cd/docker-compose up. When I'm done developing for the day, I just take everything down and bring it back the next morning.

when you have to manage a large number of services with a bunch of different devs touching things, Docker is almost required to get a consistent development state.

There's literally nothing wrong with reaching for Docker right away. It allows you to have the same, repeatable development environment. Maybe you deploy to production without Docker, but any project I start I'll reach for Docker right away.

> i will not read the linux source documentation like he suggested to get isolation for my services.

that are likely running as root on a base kernel that is out of date with vulnerabilities..