[JeffMarmalade]

lol sorry about that. It's kinda hard finding the right line in the website promo text between technical detail and something friendly enough to catch visitors' attention.

The premise of running Docker for Mac or other VMs as a development environment is usually so you can run the exact same set of services in development as you run in production. Isolated meaning you can delete the stack, rebuild it, start it up on another machine without any fear of it being affected by macOS updates. With D4M or VMs this is at the expense of not running it directly on your Mac natively, but rather inside the VM.

So to answer your question ("What's it actually do?"), it runs the same services as you might run in docker, with similar upsides (separated from the OS, rebuildable, shareable etc) but without the downsides.

Many developers have experienced first-hand the hassles involved in running D4M or a VM for development. However, those solutions really seem to work for some, so if that's you, Indigo is probably not of interest :)

Anyhow, thanks for the feedback, and if you can suggest anything I could/should say on the site specifically, please do!

[lukeholder]

I think we get that, the question is how do you isolate everything without a VM or docker?

[snorremd]

Exactly. From the web page it seems that "isolation" here is basically just installing separate copies of services/libs (php, nginx, etc) under an IndigoStack controlled folder and then running them on a port not already taken by another service. One of the benefits of Docker is explicitly that it does a change root and thus provides an isolated file system in which to run your code. It also creates separate network interfaces for the process to isolate it from your host network.

This has a number of benefits including protecting sensitive files/info in your home folder from rogue dependencies and allowing you to easily toss the dev environment into a black hole once it's no longer needed. If IndigoStack somehow implements isolation using chroot or other MacOS/Darwin equivalents it should be explained on the web page. Otherwise I think the marketing text is misleading:

> Bare metal. With the best of virtualized.

Edit:

I do like the idea of something like IndigoStack though. Being able to describe a dev environment programatically/declaratively and then having something take care of setting that up is nice. If you're a pure MacOS shop then something platform specific like this is probably an okay solution.

[tastemykungfu]

"isolation" most likely done by the automagick configuration using different ports...

Different Ports != Isolation..

But hey, marketing.

[bovermyer]

Interesting that you assumed it's just using different ports, and then judged the author based on your assumption.

There are other ways to achieve process isolation in a Unix environment without relying on Docker or virtualization.

[JeffMarmalade]

Thanks for giving me the chance to hide under the marketing rock :) But you're right and I will have a good think about what I'm implying by describing it as isolated. "Isolated" means things to me in this context, but it legitimately implies other stuff as raised in this thread, which Indigo does not attempt to do. I don't want to mislead anyone, marketing jargon or not.

[bongobingo1]

via docker and a VM.

[lukeholder]

It doesn't use docker or a VM

[sgt]

Why would you run Docker in a development environment? I know that people do this, but I just can't fathom why. Docker images should be built using a build server and deployed to staging and production. If you have a sane development environment - whether it's a virtualenv in Python or maven based in Java, it's pretty predictable.

I run databases however in Docker on my Mac.

[darkwater]

The idea is to have the same build pipeline that works locally or in prod. In the end it keeps being an holy grail because dev requirements usually differ from prod requirements (i.e. code hot-reload as fast as possible with interpreted languages in dev vs slimmest possible image in prod).

[leadingthenet]

You can just have multiple stages in the same Dockerfile, one for dev and another for prod, and have your docker compose yml file target the dev one.

[darkwater]

Yes, I did exactly this at $DAYJOB, the holy grail for me would be to have the exact same build process without any "if $environment". But anyway I agree it is good enough.

[joekrill]

Because as a developer you can simply run `docker-compose up` and have your development environment working immediately without having to ensure you have all the necessary dependencies installed locally.

And even if you think setting up a "sane development environment" is simple, it gets much more complicated as you add additional languages and versions of those languages, and their underlying frameworks, etc. For example if you look at NodeJS alone: we have things like nvm to switch between Node release versions because you'll often have different projects relying on different versions of Node. Or you could just use Docker and it's baked in, basically.

[bovermyer]

Just because you have a particular workflow doesn't mean other people don't have a different one.

What if someone's dev environment requires a running Redis server, PostgreSQL, and MinIO? And what if you need to keep those instances free of cruft from other projects? Hey, you know what works for that? Docker!

Or what if you need to mock several AWS services locally, because you don't want to be paying for actual AWS or polluting other environments while working on something? Hey, you know what works for that? Docker!

[pizza]

It's easy

[Sophistifunk]

So it's just fork-execing services that are compiled natively for Mac? In what way is that "isolated" or "the same as production"?