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

“It's The Future”

circleci.com

Post reply on HN
Print view View original

431–440 of 536 posts

Re: “It's The Future”

#431

Post by TeMPOraL »

lj3 wrote: post #426
CaptSpify wrote: post #374

Earlier quoted context omitted.

> tools that "seem cool" make their lives easier at the expense of everything else. I'd argue the opposite. Instead of spending time reflecting on how cool and useful their code is, or hardening it up, devs spend too much time reinventing the wheel. All this work to learn the next new fad is killing productivity.

Easier might not be the right word. 'tools that allow them to be lazier' might be more accurate. Gluing together pieces somebody else wrote and trying to get them all to work with as little effort as possible and are surprised when it doesn't work well. > devs spend too much time reinventing the wheel I'd argue the opposite. They spend too much time not reinventing the wheel. They strap factory made bicycle wheels on…

Or learn about better wheels designed by smart people back in the 60s and 70s, when no one had the capability to just keep sticking wheels onto cars to see what works - so they had to rely on thinking and solid engineering practices instead.

Re: “It's The Future”

#432

Post by daveroberts »

mirekrusin wrote: post #293
pmelendez wrote: post #59

Earlier quoted context omitted.

I do have a positive micro-service experience, and although we are still in that process of breaking down our monolith SOA based app, we have seen the benefits already. The more dramatic effect was on a particular set of endpoints that have a relative high traffic (it peaks at 1000 req/s) that was killing the app, making upset our relational database (with frequent deadlocks) and driving our Elasticsearch cluster cra…

Do you think the result could also be a dramatic improvement if you kept old system and do those other things except splitting into microservices? I can't get my head around how people introduce changes to their system if they have to update 12 different microservices at once? It must be horrible. Often you hear stories how people are converting monolithic app to microservices - but this is easy. Rewriting code is ea…

Multiple microservices are supposed to have different data backends, so that they are completely independent. Splitting your data up this way isn't all roses, but ideally the services are isolated so an update to one doesn't affect the others.

Re: “It's The Future”

#434

Post by davesque »

pbiggar wrote: post #334

Author here. To answer some questions: yes this is obviously poking fun at Docker, but I also do really believe in Docker. See the follow-up for more on that: https://circleci.com/blog/it-really-is-the-future/ In a self-indulgent moment I made a "making of" podcast about this blog post, which is kinda interesting (more about business than tech): http://www.heavybit.com/library/podcasts/to-be-continuous/ep... And if y…

I like the humility on display here. And I'm not trolling or being sarcastic.

Re: “It's The Future”

#435

Post by prodigal_erik »

IshKebab wrote: post #194
mbrock wrote: post #183

Earlier quoted context omitted.

How do you write "foo | bar" in Python?

How often do you actually need to do that. 99% of `foo | bar` command could easily be `foo > a && bar < a` which is pretty trivial to do in Python.

Now you have to clean up 'a'. And decide whether /tmp or /var/tmp or a dir on some other filesystem has enough space to hold all of 'a' until 'bar' is finished. Is it a security problem that other processes could snoop the contents of 'a' or even tamper with it?

Re: “It's The Future”

#437

Post by badminton1 »

Well, repeating buzzwords and pushing for early technology adoption for the sake of early technology adoption seems to be dumb, as the article implies.

But new technology is necessary and early adopters are necessary. Iteration is necessary. Don't punish it.

Re: “It's The Future”

#439

Post by jondubois »

vpol wrote: post #46
jondubois wrote: post #40

Kubernetes/Docker will become increasingly accessible to developers and it will loosen the reliance on lock-in PaaS like Heroku - This is the future; I'm betting everything on it. With tools like Rancher http://rancher.com , you can already see things moving in that direction. Next step is rancher-as-a-service. When it comes to developers, I think open systems will always prevail in the end (it's just more flexible).

I thought it's more important WHAT you run inside containers than containers itself. I got really upset about this rancher tool because it doesn't design my database schema. Shit, future was so close.

You still have to write code, define your database schema and declare config files to specify how containers should be orchestrated but soon open source developers will start creating frameworks/boilerplates which capture some of these requirements and which can automatically run and scale on Kubernetes/Swarm/Mesos and this will greatly speed up application development and deployment.

Right now, we think of frameworks as being components (part of) larger software systems - But in the future, frameworks will provide the foundations for entire software systems - They will be be responsible for declaring their own network topologies and resource requirements and they will be capable of scaling automatically to any number of machines.

Developers will extend and customize the framework with their own logic but the framework itself will handle all the difficult stuff related to its own operations.

Post reply on HN