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

521–530 of 536 posts

Re: “It's The Future”

#521

Post by coldtea »

pyre wrote: post #476
coldtea wrote: post #442

Earlier quoted context omitted.

From 20+ years of experience and having seen tons of trends just die, most are just that, hype.

But calling everything that's new "hype" and pointing to the past as the only things that are "real" or "solid" is also a form of groupthink.

Yeah, but I think it's the inverse kind of groupthink than what the industry suffers from.

So it's healthy to embrace it as counter-balance to the constant hype.

(Besides, whether something is "real" or "solid" I think can mostly be answered in hindsight -- when it's mature enough and tested enough. In which case calling only things in the past solid is prudent).

Re: “It's The Future”

#522

Post by chiefalchemist »

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…

Some things never change. It's been this way for as long as I can remember. The sad irony is, satisfaction remains the same (i.e., low) as well. We keep chasing our tails and products remain sub-par and users still frustrated. It's a shame SOS isn't a loved buzzword.

Re: “It's The Future”

#523

Post by danellis »

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…

I wonder what language I would pick for that. I usually use Scala, but it seems a bit silly when the footprint of the platform would massively outweigh the actual service. I don't like Go. I like Python, but I prefer static typing. Rust seems a bit too low level (although I'd like to try it for embedded). I don't see any point in learning Ruby when i already know Python well.

Maybe Swift? Scala Native in a year or two? I've done a little Erlang before, so maybe Elixir?

Re: “It's The Future”

#524

Post by danellis »

humanrebar wrote: post #51
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…

> Any positive experiences with micro-services here? Yep. We already had a feature flag system, a minimal monitoring system, and a robust alerting system in place. Microservices make our deployments much more granular. No longer do we have to roll back perfectly good changes because of bugs in unrelated parts of the codebase. Before, we had to have involved conversations about deployments, and there were many things…

How many instances do you deploy of services that are essential but low usage?

Re: “It's The Future”

#525

Post by kafkaesq »

amelius wrote: post #505
kafkaesq wrote: post #460

Earlier quoted context omitted.

The problem with microservices is that your state is spread over multiple systems. Then again, sometimes it's advantageous to identify parts of your system where aspects of state can be safely decoupled. And in which having them reside in disparate systems (and yes, sometimes be inconsistent or differently available) might actually be a better overall fit. You completely lose the concept of transactional integrity, s…

> Then again, sometimes your state changes not only don't need to be transactional; it can be disadvantageous to think of them that way. I'm curious; in what kinds of situation would this apply? > Depends, depends, depends. Flexibility is usually an important requirement. Often you cannot freeze your architecture and be done with it. I think a transactional approach could better fit with this.

I'm curious; in what kinds of situation would this apply?

Any situation where the business value of having your state be 100% consistent does not outweigh the performance or implementation cost of making it so.

Re: “It's The Future”

#526

Post by nickbauman »

karrotwaltz wrote: post #159
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…

My manager and CEO are going wild with "blockchains", and how we should use it for everything. "We could store gigabytes of data on the clients without having to pay for servers"

This is hysterically funny! Can you tell us who this CEO is?

Re: “It's The Future”

#527

Post by nickbauman »

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…

You split off specific parts of your app into microservices because you want to scale those parts independently from the rest. It's not just a blind decomposition of a monolith for the sake of decomposition.

Re: “It's The Future”

#529

Post by goldenkey »

nickjj wrote: post #454
goldenkey wrote: post #448

Earlier quoted context omitted.

I love the comparison to chinese food for 2. As if everyone lives in the US with the same economic situation. Your posts are truly despicable.

I'm sorry you feel that way. Unfortunately time is something we all share, and it brings me a lot of joy to have students say that my courses have saved them a ton of time and helped them meet their goals. I see that you recently left Amazon after making 200k/year there (a comment you made 5 days ago). I can see why you don't like people promoting Amazon products, I fully understand.

Condescension abounds! :-)

Re: “It's The Future”

#530

Post by emn13 »

driusan wrote: post #514
flukus wrote: post #501

Earlier quoted context omitted.

Is the development open though (serious question, I don't know how they do it with go)? Look at android, it's a closed project that the occasionally release some source code for. If google decided to drop android then it's a critical blow because there isn't much of a community around it.

It depends what you mean by "open." Anyone can subscribe to the go-codereview mailing list. Anyone can submit a patch, but you need to a) use gerrit and b) sign a (digital) contribitors license agreement with Google. It's "open", but it would almost certainly collapse entirely if Google decided to drop support for it. (There's no sign that they'll do that, but it's not a risk you take with a language like C.)

Even by the most lax standard you couldn't call the app store open; and that's kind of what's being shuttered here. The technology wasn't ever particularly interesting (not a bad thing), but the distribution model was. And that's entirely closed - they're not about to give anyone else permission to run even parts of the app store to anyone else, and that's that.
Post reply on HN