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

311–320 of 536 posts

Re: “It's The Future”

#311

Post by neeleshs »

hobs wrote: post #210
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…

Yeah, add in things like MORE THAN ONE PRODUCTION ENVIRONMENT and LETTING YOUR CUSTOMER HOST AN INSTANCE OF YOUR MICROSERVICES and you have guaranteed your own suffering.

It is a matter of tooling. One data center or ten, it does not matter much with proper tooling. We deploy to seven data centers with a click of a button, with rollback, staggered deployment etc. Centralized logging using ELK gives us great visibility in to each DC, without worrying about individual microservice instances.

Re: “It's The Future”

#312

Post by mr_tristan »

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…

Oh yes. We're splitting up a large monolith into a bunch of different services. Completely amazing, though there's a ton of tools (like Netflix's Hysterix, etc) that make it much, much easier to do.

I wouldn't, however, just "do microservices" from day one on a young app. But usually that young app has no idea what the true business value is, i.e., you have no idea what down time of certain parts of your services really means to the business. That's the #1 pain point we're solving: having mission critical things up 100%, and then rapidly iterating on new, less stable feature designs in separate services.

You should, however, keep an eye on how "splittable" everything is, i.e., does everything need to be in the same DB schema? Most languages have package concepts, which typically align (somehow) with "service" concepts. Do you know their dependencies? That sort of thing. Then, the later process of "refactor -> split out service" is pretty straightforward and easy to plan.

Re: “It's The Future”

#313

Post by dietrichepp »

pc86 wrote: post #288
wtbob wrote: post #249

Earlier quoted context omitted.

> 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.

I guess Facebook, Twitter, and Google are doing things "flat out wrong", then. Yes, that's a weak argument (argument from authority) but it is true that monolithic repositories have major advantages even for organizations with multiple products. Common libraries and infrastructure are much easier to work with in monolithic repositories.

My personal take on it, at this point, is that much of our knowledge of how to manage projects (things like individual project repos, semantic versioning, et cetera) is centered on the open-source world of a million mostly-independent programmers. Things change when you work in larger organizations with multiple projects. You even start to revisit basic ideas like semantic versioning in favor of other techniques like using CI across your entire codebase.

Re: “It's The Future”

#315

Post by qwertyuiop924 »

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"

Well, maybe... if you had any clients left, or the infrastructure to support such a thing.

Re: “It's The Future”

#316

Post by raverbashing »

vertex-four wrote: post #161
moron4hire wrote: post #152

Earlier quoted context omitted.

That sounds more like your team doesn't know how to use git beyond nothing more than an SVN replacement.

"We rolled out this update with 220 changes. There's a breaking bug. Where is it? We need to find out in the next 5 minutes, revert, and deploy. Otherwise we have to revert the whole thing- we're losing money." Git doesn't really help with that. More granular deployments do, and if microservices help with more granular deployments, go for it.

> We rolled out this update with 220 changes.

That's your problem right here

Re: “It's The Future”

#317

Post by bosie »

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…

Can you expand on how you do logging/debugging/monitoring?

Re: “It's The Future”

#318

Post by SolarNet »

MichaelBurge wrote: post #19
TickleSteve wrote: post #12

Sometimes it seems the webdev world is unaware of the complexity its creating simply to execute instructions....

I think every developer goes through that phase at some point.

I think the problem is that it's an entire industry. And they don't even see to see the problem.

Re: “It's The Future”

#319

Post by marcosdumay »

jules wrote: post #154
nicolas_t wrote: post #43

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…

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…

That's true, but...

You don't debug distributed systems by tracing into remote calls and jumping into remote code. You debug it by comparing requests and responses (you use discrete operations, right) with the specified requests and responses, and then opening the code that has a problem¹.

It calls for completely different tooling, not for a "better debugger".

1 - Or the specs, because yes, now that your system is distributed you also have to debug the specs. Why somebody would decide on doing that for no reason at all? Yet lots of people do.

Re: “It's The Future”

#320

Post by alpeb »

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…

I remember Larry Ellison saying once that the only industry more driven by fashion than fashion itself was IT. That was when the «cloud» thing was starting to take off. He was refusing to have Oracle use those new buzzwords, but at the end he was forced to.
Post reply on HN