Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's the Future

blog.circleci.com

Post reply on HN
Print view View original

91–100 of 146 posts

Re: It's the Future

#91

Post by imaginenore »

vbezhenar wrote: post #40

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.

Re: It's the Future

#92

Post by walterbell »

angersock wrote: post #74
benmathes wrote: post #63

Earlier quoted context omitted.

Big platforms tend to be different things to different people. Might help to have a different "what is docker?" page for the various roles you encounter. For CIOs: click here For developers: click here For sysadmins/devops: click here For platform providers (e.g. heroku): click here.

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.

> Whenever I see a product segmented that way, I'm immediately suspicious.

If each message is delivered privately to each segment, prisoners-dilemma style, caution is warranted.

If all messages are public to all segments, the product story has likely become modular and coherent.

Re: It's the Future

#93

Post by msane »

pbiggar wrote: post #31
msane wrote: post #27

To the position that containerization is needless complexity for simple or non-scaling apps: one of the benefits of containers is it can create development environments which can be identical to your production environment(s); no matter what platform you're always running the same code, same artifacts, same images. Virtualization does this too, but at great cost. I wish the kinks were better worked out at this point…

But (and this is a thing I've been working on) do you really want your dev environment to be identical to your production environment? I think you don't. As an example, suppose you use Go. Your dev environment is 500mb of compilers and toolchain. Your production environment is (hopefully) a container with a single static binary on it.

you're absolutely right, one needs to build images sans all of the dev toolchain and with staging/production flags. but the deps and parts they share in common should be identical. this is a hairy problem to solve, but containers are the solution, mixed with the right pattern, whatever it is. I might not want my dev containers to run on prod, but I want my staging/prod containers to be able to run on my local or whatever environment has the container/orchestration tool.

Re: It's the Future

#94

Post by icebraining »

imaginenore wrote: post #91
vbezhenar wrote: post #40

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.

If you have continuous backups, it's actually not that bad. You can recreate a server fairly rapidly from a full system backup.

Re: It's the Future

#95

Post by dzhiurgis »

digi_owl wrote: post #61
aerovistae wrote: post #36

Earlier quoted context omitted.

From that article: "The Architecture Astronauts will say things like: "Can you imagine a program like Napster where you can download anything, not just songs?" hahahahahhaha bittorrent.

Even Napster was used for non-music stuff towards the end, by renaming archives as mp3. And the basic protocol was later adopted for more generic sharing systems, never mind the number of clones that came about after Napster was lawyer bombed. Bittorrent is just the latest in a long string of P2P systems, with the biggest difference being the lack of a central search server.

The next replacement Soulseek is still very alive today.

Re: It's the Future

#96

Post by jlarocco »

shykes wrote: post #48
akanet wrote: post #4

It 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…

> 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

I have two thoughts on this.

First, if CIOs and IT directors are calling, then it's possible they're confused by the website, too.

Second, the README is definitely better, but would be even better by being more specific and exaggerating less. If it's targeted to web apps and back end services, say that in the first place, instead of "any application." Can I run iPhone apps in Docker? Are there Docker packaged apps in the iTunes store? If my application runs on an Arduino, can it also use Docker?

Re: It's the Future

#97

Post by S4M »

nether wrote: post #49
Animats wrote: post #3

Ah, l33t for system architects. A few days ago, the CTO of Soylent, the food drink, was describing their elaborate computer infrastructure. They have one (1) product and a simple web site. Based on their sales volume, they do about two sales a minute. That could run on a HostGator "Hatchling" account for $4/month, using one of the seven off the shelf shopping cart/payment programs HostGator offers.

Soylent had exceptionally poor order handling prior to their latest round of funding. The way they've run their business and development seems like a total joke. 6-10 month order delays over a year since they started selling? (Not to mention charging orders before shipping) "Most scientific food" - zero clinical trials? Are you shitting me?

It's also crazy that they don't let you order one sample to test it. There is no way I will pay $70 for 28 meals if I don't know if I will like it.

Re: It's the Future

#98

Post by peu4000 »

vbezhenar wrote: post #40

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…

That's great if it's just you and you don't care about your site breaking because you didn't test your code outside of your Mac.

More users, more developers, larger sites require more than just Jim Bob installing CentOS and tomcat on a pizza box.

It doesn't always require Docker + this tech or that tech, but you will have to put some automation in place.

Re: It's the Future

#99

Post by NeutronBoy »

ezy wrote: post #75
akanet wrote: post #53

Earlier quoted context omitted.

I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ . There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural t…

"I find that position to be very hard to understand - devtools live or die by their adoption" Some of the time, that is true, but not all the time, maybe not most of the time -- you are putting the cart before the horse. In fact, I would argue that this is an anti-pattern. Yes, you might use (e.g. to pick 2 unrelated domains) Hadoop or Python because they are popular, but consider how they got popular in the first pl…

> To be clear, I find Docker, the tool, useful, I just think it doesn't need "Marketing", it needs a useful webpage

What exactly do you think Marketing is? It's not all about BS, it's about communicating a message. If that's a simple webpage, then so be it. Often an idea or product is far too complicated to explain through 2-3 lines of text and needs more.

Re: It's the Future

#100

Post by Animats »

joezydeco wrote: post #64
nether wrote: post #49

Earlier quoted context omitted.

Soylent had exceptionally poor order handling prior to their latest round of funding. The way they've run their business and development seems like a total joke. 6-10 month order delays over a year since they started selling? (Not to mention charging orders before shipping) "Most scientific food" - zero clinical trials? Are you shitting me?

Might want to read this: https://medium.com/@alando46/how-we-spent-500-on-tech-to-shi... If you knew how most modern warehouse/shipping facilities ran their IT, your head would spin.

Figures. They overbuilt their public-facing web system, and underbuilt their fulfillment system. Reading that, you can see the problem - their order system, fulfillment system, and order tracking system didn't talk to each other properly. You don't just ship stuff blind; you read back the carrier's online shipping data and match it with the orders, so you know you didn't miss anything. Otherwise, you don't know you screwed up until the angry customer calls you.
Post reply on HN