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

281–290 of 536 posts

Re: “It's The Future”

#281

Post by pc86 »

mikepurvis wrote: post #245
shados wrote: post #202

Earlier quoted context omitted.

Yeah, we do micro services, the "real" kind. Not the "SOA with a new name kind", but the "some services are literally a few douzan lines of code and we have 100x the amount of services as we do devs" kind. The thing is, you need a massive investment in infrastructure to make it happen. But once you do, its great. You can create and deploy a new service in a few seconds. You can rewrite any individual service to be la…

"Different teams don't have to agree on coding standards (so you don't argue about it)." Unsure if sarcastic.

Seems like a terrible idea if "different teams" actually means "random assortment of developers for this specific project." If it actually means "different teams," e.g. you rarely if ever would move from one team to another, I don't see the issue if one team uses tabs and one uses spaces, or you have different naming conventions or whatever.

Re: “It's The Future”

#282

Post by avindroth »

rajeshp1986 wrote: post #109

The article perfectly summarizes my frustration and sentiment. These days I hear these buzzwords all time. I work as a consultant for an enterprise product and most people whom I meet they somehow catch these buzzwords and blurt it out in front of everyone during meetings and discussions to either showoff that they know technology and things that are in the market these days(also latest iphone, apple news, tesla, spa…

Our industry is a pop culture. A fad.

Computer science is not a real field.

Re: “It's The Future”

#283

Post by clifanatic »

mikepurvis wrote: post #245
shados wrote: post #202

Earlier quoted context omitted.

Yeah, we do micro services, the "real" kind. Not the "SOA with a new name kind", but the "some services are literally a few douzan lines of code and we have 100x the amount of services as we do devs" kind. The thing is, you need a massive investment in infrastructure to make it happen. But once you do, its great. You can create and deploy a new service in a few seconds. You can rewrite any individual service to be la…

"Different teams don't have to agree on coding standards (so you don't argue about it)." Unsure if sarcastic.

Well, you use the standard you like, and the other team can use the standard they like. Then you write a micro service to convert from one standard to the other.

Re: “It's The Future”

#284

Post by dietrichepp »

wtbob wrote: post #249
jules wrote: post #154

Earlier quoted context omitted.

In practice micro services mean that you turn a function or method call into a network request. This doesn't really limit communication bottlenecks. It is often more difficult to argee on a network interface than on a simple function or object interface. It's also more difficult to change. You introduce a whole new set of failure modes due to going over the network. Debugging is more difficult since you now can no lo…

> You introduce a whole new set of failure modes due to going over the network. A thousand times yes. Distributed systems are hard . > Debugging is more difficult since you now can no longer step through your program in a debugger but rather have an opaque network request that you can't step into. Yes . Folks underestimate how difficult this can be. In theory it should be possible to have tooling to fix this, but I'v…

> No organisation should have more than one regular-use repo (special-use repos, of course, are special). Multiple repos are a smell.

I would modify this slightly. Larger organizations with independent teams may want to run on per-team repos. Conway's law is an observation about code structure but it sometimes also makes good practice for code organization. And of course, sometimes the smell is "this company is organized pathologically".

Another problem is that large monolithic repositories can be difficult to manage with currently available software. Git is no panacea and Perforce isn't either.

Re: “It's The Future”

#285

Post by vonmoltke »

Maro wrote: post #209
rajeshp1986 wrote: post #109

The article perfectly summarizes my frustration and sentiment. These days I hear these buzzwords all time. I work as a consultant for an enterprise product and most people whom I meet they somehow catch these buzzwords and blurt it out in front of everyone during meetings and discussions to either showoff that they know technology and things that are in the market these days(also latest iphone, apple news, tesla, spa…

Honest advice: Stop working for/with stupid companies/people and start working for smart ones.

The smart companies already have more qualified applicants than slots, and often arbitrary hiring processes to boot. Not everyone has the luxury of working for one.

Re: “It's The Future”

#286

Post by bbcbasic »

LoSboccacc wrote: post #33
nbevans wrote: post #10

Earlier quoted context omitted.

But all you've done is shift the problem to, er, you. If someone is uncomfortable taking out a dependency on say Azure or AWS - the two leading Docker hosting platforms, then they sure as hell aren't going to take out a dependency on "baasil.io" are they?

xkctext: we saw 15 competing standard, so we decided to invent our standard that encompass all the previous one!

Then there are 16 competing standards.

Re: “It's The Future”

#287

Post by phamilton »

jalfresi wrote: post #240
IshKebab wrote: post #186

Earlier quoted context omitted.

Doesn't statically compiling programs solve the deployment issue better? I mean, as far as I can tell Docker only exists because it's impossible to link to glibc statically, so it's virtually impossible to make Linux binaries that are even vaguely portable. Except now Go and Rust make it very easy to compile static Linux binaries that don't depend on glibc, and even cross-compile them easily. Hell I think it's actual…

Have to admit, as a fellow Go dev, with single binary static compiles, I don't really GET why I need docker... all it seems to offer is an increased workload and complicated build proc

Isolation is a strong argument. You don't want one process to starve another. You can get isolation via one-host-per-service or you can get it using cgroups. Docker sort of gives you both, without the waste of one-per-host and with a manageable set of tooling around cgroups.

Re: “It's The Future”

#288

Post by pc86 »

wtbob wrote: post #249
jules wrote: post #154

Earlier quoted context omitted.

In practice micro services mean that you turn a function or method call into a network request. This doesn't really limit communication bottlenecks. It is often more difficult to argee on a network interface than on a simple function or object interface. It's also more difficult to change. You introduce a whole new set of failure modes due to going over the network. Debugging is more difficult since you now can no lo…

> You introduce a whole new set of failure modes due to going over the network. A thousand times yes. Distributed systems are hard . > Debugging is more difficult since you now can no longer step through your program in a debugger but rather have an opaque network request that you can't step into. Yes . Folks underestimate how difficult this can be. In theory it should be possible to have tooling to fix this, but I'v…

> No organisation should have more than one regular-use repo

Flat out wrong for any organization with multiple products. Which, let's be honest, is most of them.

Re: “It's The Future”

#289

Post by mseebach »

chewbacha wrote: post #271
collyw wrote: post #191

Earlier quoted context omitted.

As long as the database isn't relational, I guess.

10 million rows in a relational database doesn't need to be bad nor is it big data. Rows is a bad measure of "big" when it comes to data. A measurement of bytes and probably more specifically bytes per field and how many fields the records have, as this gives a better indication into the way this will be written and potentially searched. 10 million rows of 5 integer values is pittance for any relational database wort…

Someone once suggested to me that 'big data' begins when it doesn't fit in RAM in a single rack any more.

Re: “It's The Future”

#290

Post by SonicSoul »

shados wrote: post #202
mrhektor wrote: post #31

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

Yeah, we do micro services, the "real" kind. Not the "SOA with a new name kind", but the "some services are literally a few douzan lines of code and we have 100x the amount of services as we do devs" kind. The thing is, you need a massive investment in infrastructure to make it happen. But once you do, its great. You can create and deploy a new service in a few seconds. You can rewrite any individual service to be la…

what are the big infrastructure costs?
Post reply on HN