Live data from Hacker News

“It's The Future”

circleci.com

111–120 of 536 posts

Re: “It's The Future”

#111
Man, I dont think this is the future at all. OK, Docker is good and has its propose, and is very good on what its do: "Run only one process in one brand new kernel", but beyond than that, its just a daemon that uses and abuses of linux containers, you can easily scale, but is a pain in the ass to upgrade apps, also you need to run only one process on that. Does not looks like the future for me to have 30 different linux containers running just only one process in each of them, dude, you have a kernel in your hand, why the hell you will run only one process on it? (what the heck, you can protect yourself and scale without be the bitch of a daemon, you just need to know your best friend kernel), you dont need to make micro services for everything, its good ok, but its not the solution for everything like the people are saying...

I really dont have any idea why the people are are so excited about "docker" all the things.

Re: “It's The Future”

#113

Earlier quoted context omitted.

I think that splitting into micro services is valuable if and only if you reach a scale where it makes sense to split into micro services. By scale, I mean the number of people on the team (if you have a lot of people, it can make sense to split into micro-services to limit communication bottlenecks between developers) or in term of traffic, in which case microservices can be very useful to better optimize the system…

I think it's more to do with a need rather than going straight just because you have enough people on a team. For instance, if you find that some of your processing/specific request handling can outperform better by using a different framework, programming language than the ones it's currently developed on, then you should definitely consider a microservice approach by decoupling that specific service/functionality f…

Careful with this one too. Usually adding new features to adapt to a changing marketplace can have new requirements across many of your services that need to be finished quickly. If those services are each in a different language, it can slow everything down by weeks or months.

Multiple platforms is not a problem and generally a good thing as long as it's not excessive. You don't want to be in a case where you have the same number of different platforms as developers or anything like that. I'm guessing there is a rule of thumb here, but I'm not sure what it would be. Max 1 different platform per 5 developers? Something like that.

Re: “It's The Future”

#114

I'm not a web developer but I sometimes put some programs on the web for me and my friends. I use FreeBSD Jails for that. Can someone explain to me the advantages of Docker compared to Jails?

In your use case: pretty much no advantages. Stick with jails and be happy.

Re: “It's The Future”

#115

Earlier quoted context omitted.

I think that splitting into micro services is valuable if and only if you reach a scale where it makes sense to split into micro services. By scale, I mean the number of people on the team (if you have a lot of people, it can make sense to split into micro-services to limit communication bottlenecks between developers) or in term of traffic, in which case microservices can be very useful to better optimize the system…

I think it's more to do with a need rather than going straight just because you have enough people on a team. For instance, if you find that some of your processing/specific request handling can outperform better by using a different framework, programming language than the ones it's currently developed on, then you should definitely consider a microservice approach by decoupling that specific service/functionality f…

>decoupling that specific service/functionality from your current stack.

I do wish people would stop conflating "running in a different service" and "loose coupling". They are completely orthogonal.

I've worked on some horrendously tightly coupled microservices.

Re: “It's The Future”

#116
post #89

I think I will be fine, thanks. I'll stick to my shell scripts, so far they've outlived any other devops fad.

Why not use Python instead? Shellscript is so... chaotic.

I pine for the days of yore when the Unix Philosophy was strong and pure, and every program did one thing well, and only one.

Like the way the shell would fork off an "expr" sub-process to parse a mathematical expression to add two numbers, then write the result to a pipe via stdout, then terminate the process, clean up all its resources, and switch context back to the shell, which then read the serialized sum back in from the other end of the pipe, and went about its business, regardless of the fact that the CPU running the shell already had its own built-in "add" instruction in hardware.

Re: “It's The Future”

#117

I've spun up a lot of kubernetes clusters to test it out. A few months ago I also tested out Flynn, Deis, Deis Workflow, Openstack, and a lot of other options. I still haven't found a simple bootstrap script that gets everything set up on AWS and lets me simply deploy my application. And it's true that storage still seems to be an unsolved problem with kubernetes. Heroku is great, and free for small services. On the…

So, why not ditch AWS and use GCP? Kubernetes cluster setup in one command, or use AppEngine.

Maybe the problem is AWS.

Re: “It's The Future”

#118

I've spun up a lot of kubernetes clusters to test it out. A few months ago I also tested out Flynn, Deis, Deis Workflow, Openstack, and a lot of other options. I still haven't found a simple bootstrap script that gets everything set up on AWS and lets me simply deploy my application. And it's true that storage still seems to be an unsolved problem with kubernetes. Heroku is great, and free for small services. On the…

[deleted]

Re: “It's The Future”

#120

"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…

Maybe so. But didn't the move create a cool Software Architect job position out of nowhere -wink-wink- ?
Post reply on HN