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

31–40 of 146 posts

Re: It's the Future

#31

Post by pbiggar »

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.

Re: It's the Future

#32

Post by greghendershott »

jakejake wrote: post #18
VieElm wrote: post #11

Well these technologies are there to help bring Google type infrastructure for businesses that need it. If you're running a CRUD app just fine on Heroku you don't need to do any of this and you shouldn't. When your availability starts having problems or your data is getting too much for one machine, you start having problems of scale. Where you are in terms of scaling issues should lead you to the next iteration of t…

Seems to be the problem with a lot of technologies. If you're a HN reader, you can start to get the feeling that you're falling behind if you're not doing these things. Even though they are totally inappropriate for the majority of us who are working on smaller systems.

Often there's some tension between individual career development and what makes sense for the project and company.

Ideally, managers create opportunities for people to exercise the former in a sandbox (e.g. some variation of "20% time"), without YAGNI-ing up the project.

Sorry did I say sandbox? I meant container.

Re: It's the Future

#34

Post by unoti »

aerovistae wrote: post #6

This is exactly how I feel whenever people start talking about this stuff. Is that bad? I know this is a satirical post but it seems like a pretty faithful depiction of reality.

This is really nothing new. It's a DevOps version of Joel on Software's famous essay about Architecture Astronaughts from 2001: http://www.joelonsoftware.com/articles/fog0000000018.html

Re: It's the Future

#35

Post by lstamour »

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.

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 remote debugging tools. The point, especially with ops involved, is that your dev box is a snowflake and you want the least amount of manual configuration possible. It's not a requirement. Your app will run fine in production without it simply by testing in production. But few people willingly recommend that approach, even as pretty much everyone does it at some point or another. Even the best emulation of production won't prevent the need for debugging in production when a bug isn't caught before it gets deployed ;-)

Re: It's the Future

#36

Post by aerovistae »

unoti wrote: post #34
aerovistae wrote: post #6

This is exactly how I feel whenever people start talking about this stuff. Is that bad? I know this is a satirical post but it seems like a pretty faithful depiction of reality.

This is really nothing new. It's a DevOps version of Joel on Software's famous essay about Architecture Astronaughts from 2001: http://www.joelonsoftware.com/articles/fog0000000018.html

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.

Re: It's the Future

#37

Post by icebraining »

stephengillie wrote: post #19
beat wrote: post #12

Earlier quoted context omitted.

Production workflow and inventory management are totally greenfield. No one has ever written apps for that stuff before, nope.

Can we make it cheaper than we can buy it? Is their purchase price more expensive than my hourly wage for a few months?

There are open source CRM/ERP systems available for free, no need to buy anything.

Re: It's the Future

#38

Post by pbiggar »

lstamour wrote: post #35
pbiggar wrote: post #31

Earlier quoted context omitted.

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.

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

#39

Post by rdsubhas »

thinkdevcode wrote: post #30
canistr wrote: post #16

Earlier quoted context omitted.

New, new hotness is React Native (or whenever FB decides to make it also available on Android) and JSBlocks.

New, new, new hotness is Aurelia! Get with the times! http://aurelia.io/ Edit: just wanted to point out that this post was only partially satirical. I absolutely am in love with Aurelia atm.

atm

Re: It's the Future

#40

Post by vbezhenar »

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 enough for Facebook, of course.
Post reply on HN