I may be old guy but I never get it. Why do I ever need all this virtualization stuff? I just buy a server, install CentOS, install postgresql, create another user, install java, download&unarchive tomcat and write some simple bash scripts. Voila. Everything works, everything is protected, performance is superb and I can do all that within one day. Good enough to serve few thousand requests per second. May be not eno…
And then that data center has a fire, your server is gone, your data is gone, your business loses X thousands of dollars per day, all because everything was on one server.
It's the Future
121–130 of 146 posts
Re: It's the Future
#122It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you go to https://www.docker.com , you see: "Build, Ship and Run. Any App, Anywhere." Jesus Christ. I get that you're The Future, but make the value prop for me here, at least. Why should I use Docker? What parts of my stack does it replace? When does the cost-bene…
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
It's a VM that doesn't need a full guest OS. It's a sandbox. I'm sure I'm wrong but I can't think of another ELI5 for this.
Re: It's the Future
#123Earlier quoted context omitted.
The point is not that dev and production environments are identical, but that dev staging and production environments are identical. Your dev box can have whatever you like on it, but if it can't fake production behaviours, it's not going to help you catch and debug bugs in production. Of course there are limits. You could, it's perfectly valid, buy twice as much capacity in production and run it twice there. And use…
Yeah, but folks are talking about using containers for actual dev environments. Because you want to make sure everyone is using the same version of the go compilers, etc.
Re: It's the Future
#124Earlier quoted context omitted.
Yeah, but folks are talking about using containers for actual dev environments. Because you want to make sure everyone is using the same version of the go compilers, etc.
Hmm. By that logic, one VM compiles the app and produces or inserts it into another VM runtime environment....?
Re: It's the Future
#125Ughhh this. I just want to give my project to a PaaS and let them figure out everything. I was looking into Google App Engine, but they didn't support some language features I wanted (e.g. Java 1.8, Servlet 3.X["I know, programming in Java? You're stuck in the past"]). So I looked into their new Container Engine. But like this article points out, it makes deployment 500000000 times more complicated than it should be.
Re: It's the Future
#126Re: It's the Future
#127Earlier quoted context omitted.
Whenever I see a product segmented that way, I'm immediately suspicious. That much work means that a) they're trying to sell something because it isn't obviously better and b) they're more worried about messaging than being simple and useful.
> they're more worried about messaging than being simple and useful But useful means different things to different people. To a dev, Docker might mean you keep your environment clean, scripting of automated testing, and have platform agnostic deployments. To the CIO, Docker means your devs spend less time futzing around with their stuff and more time working on the product. Or that he can upgrade his infrastructure g…
Re: It's the Future
#128A seeming eternity ago I let Maven convert apps into war files that supposedly could be deployed into any web application server. What do the new containers add on top of that (or other than that)? Only the option for more services (not just web app, but database, different languages, whatever)? It seems odd having to worry about that kind of thing.
>It seems odd having to worry about that kind of thing. It seems odd having to worry about things that aren't Web apps? Why? Containers are also language-agnostic. .war files are only for JVM languages.
I don't really know docker yet. So if I need a database, rather than instantiating a server with a database, I would create a docker image that runs a database? Then deploy it to some server that can digest docker images (is there a docker image for that)?
The point of war files was not having to worry about the server.
Re: It's the Future
#129Earlier quoted context omitted.
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
> Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md From the perspective of this longtime software developer, this isn't that great either. I'll try to give some specifics. * The terms "container" and "containerization" seem to mean a lot to the author of the document, but they're never defined well and they're used an awful lot despite…