What up peeps.
For the past few weeks, I've dabbled and played around with Docker and Homestead (a prepackaged Vagrant box with Laravel goodies) just to see what's in store. But still, I can't see how much I'm gaining for the effort when my current setup (locally installed PHP7.2+Postgres+Redis etc. on a Linux box which is pretty much identical to my production setup) already works. Can someone fill me in? Maybe I'm looking at it the wrong way.
Thanks for your input!
Top comments (9)
VMs and Containers are useful if:
If you can recreate development environment easily without a VM, it is totally fine. In such cases, installing from a script or using Chef/Puppet/Ansible playbooks are also valid alternatives.
This is basically it; using something like Vagrant, docker-compose, or minikube for your local environment just because tends to have a pretty miserable effort:reward ratio.
"...pretty much identical to my production..." So it is not 100% parity w/ the production machine. Wait until that one OS package changes and you up date locally, spent a month building a new feature that relies on that new OS package version but production will not be updated until next quarter and YOU have to spend weekend re-writing the feature.
"Works on my machine" ... guess you machine is production now, seriously. You work machine is not the 8 year old Thinkpad with the broken keyboard 'cause you fancy Macbook Pro now has to host that feature that only runs on your machine.
Your operations people will also greatly appreciate the effort of doing your due diligence in ensure the application install/operation/load/shutdown/etc will indeed operate as expected.
Going back to the item of environmental parity. Given the levels of abstraction required to execute even the simplest web application removing fear uncertainty and doubt (FUD) as much as possible pays off in the longer term.
Now, if your project is a small side hustle, class project, non PII proof of concept; then yes, parity is overkill. But that one time you spend all weekend stuck figuring out why a feature does not work, only to find out it is some low level OS package minor version change or slightly different API (see
sedon OSX vs Ubuntu) you will come to value parity.Hope this helps out and is not to ranty. I've been bit by this issue to many times.
I appreciate your thoughts on this, it really gave me a new perspective on the issue.
And yeah, I agree that removing uncertainty is a good payoff for the effort. I personally haven't experienced an OS package disparity messing up my production setup, so I guess getting environment parity is a good way to make sure I never experience it at all.
Glad I could provide a different perspective. Life everything else in life 'there is not perfect answers, only trade-offs', so I will not pretend to be dogmatic about solution options.
I hesitate to agree with "..never experience it at all.". Nothing in life (or computing) is assured.
If you are so included, feel free to message me any time.
Wait a second, do you mean that even if I build two identical images there's still a chance for disparity? Or you're just giving me advice and I misunderstood it lol.
General life advice. :)
What if you want to need an older version of redis for another project? Or a newer version of postgres? Or you want to experiment with clustering strategies?
Not only is it nice to stay in tune with prod, but it's also really flexible to develop with. You can change your entire architecture via text files, and that's pretty tough to beat!
It's also really great for experimentation. You can spin up the ELK stack with a single file and pay no attention to which version of Java or Ruby are required. In fact, you don't even need to know they are required which really lowers the "barrier to innovation".
I use Lando these days, and the advantages over installing the dependencies locally are: