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

291–300 of 536 posts

Re: “It's The Future”

#291

Post by huherto »

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…

> Also, the team spent too much time debating standards etc.

IMHO. You need a lead with a clear vision that drives the effort. Too many leads will create chaos.

Re: “It's The Future”

#292

Post by nicolas_t »

crdoconnor wrote: post #115
vmateixeira wrote: post #77

Earlier quoted context omitted.

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.

Well, I consider that by definition tightly coupled microservices should never be done. If it's not possible to decouple that function then it should not be in a micro service.

Re: “It's The Future”

#293

Post by mirekrusin »

pmelendez wrote: post #59
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…

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 easy and it's fair to say it always yields better code (with or without splitting into microservices - it doesn't matter).

What I'd like to hear is something about companies doing active development in microservice world. How do they handle things like schema changes in postgres where 7 microservices are backed by the same db? What are the benefits compared to monolithic app in those cases?

It seems to me that microservices can easily violate DRY because they "materialise" communication interfaces and changes need to be propagated at every api "barrier", no?

Re: “It's The Future”

#294

Post by andrewprock »

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.

Not at all sarcastic. I've seen endless wheel warring over spaces/tabs, level of indents. Mostly I ignore it.

Re: “It's The Future”

#295

Post by joryhatton »

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

reader implements and gets massive bill for personal blog hosting

"Am I doing this right?"

Re: “It's The Future”

#296

Post by vonmoltke »

wtbob wrote: post #259
totally wrote: post #193

Earlier quoted context omitted.

Yes, but there's another dimension here. If another team breaks your build in a monolithic repo, you may or may not be able to resolve this quickly. You're in a contract with them about the state of the repo and thus your service. With microservices, the production version of their service would conceivably be stable. It moves the contract from the repo to the state of production services.

> If another team breaks your build in a monolithic repo, you may or may not be able to resolve this quickly. With a monolithic repo done right, the other teams broke their build of their branch, and it's up to them to resolve it. You, meanwhile, are perfectly happy working on your branch. When their changes are mergeable into trunk, then they may merge them, not before — and likewise for you. With multiple repos, th…

> With multiple repos, they break your build, but don't know it. You don't know it either, until you update your copies of their repos — and now you have to figure out what they did, and why, and how to update your logic to handle their new control flow, and then you update again and get to do it again, until finally you ragequit and go live in a log cabin with neither electricity nor running water.

I don't see how this is a problem if you are pushing frequently and have a CI system. You know within minutes if the build is broken. If it broke, don't pull the project with the breaking changes.

My point is, I don't think one approach is inherently better than the other. Both require effort on the part of the teams to manage changes (or a CM team), and both require defined processes.

Re: “It's The Future”

#297

Post by oelmekki »

collyw wrote: post #230
oelmekki wrote: post #78

"Hi, my name is dokku, and I have no idea what you're talking about" :) This rant sounds just like any rant from old dev mocking a new tech. "This is less efficient, this is too complicated, this can't be taken seriously, this won't last". Creating a character obsessed with "this is dead" hardly dissimulate the obsession with "this won't work". Do whatever you please, we don't care. But don't mock others about what t…

>This rant sounds just like any rant from old dev mocking a new tech. Probably because we have seen it all before, and there isn't much "new" most of the time.

I've been a professional developer for ten years myself, I've seen my part of hype. But I've seen way more people not even trying new things (and trying does not mean sticking with it on your main project), probably because they could not stand the idea that the experience they are so proud of could be invalidated in any way.

Re: “It's The Future”

#298

Post by nicolas_t »

miend wrote: post #192
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…

I'd also add that microservices have increased value if you begin with such an architecture in the first place. It's much more difficult to "gracefully" rip an existing monolith into modular pieces than to build modularly from the start.

This has not been my experience. I've seen a few projects where microservices had been added from the start because it's the thing to do and, in all cases, it didn't work well. It's extremely difficult to split in microservices if you do not have a clear big picture of your projects functions and coupling. And, in most cases, in new projects, you don't have that big picture.

Microservices also make it much harder to refactor the code which you often need to do in the early stage of a project.

Re: “It's The Future”

#299

Post by BenfromOz »

brightball wrote: post #246

As the author of that "Docker is the Heroku Killer" post that was popular a couple of years ago I have to say that I agree with this. When I wrote that article it was largely focused on the potential for Docker to create a bunch of Heroku competitors as well as a simplified development experience across multiple languages. The businesses aren't there yet although a ton are trying. The local dev experience has not mat…

I'm working on one of those Docker powered Heroku "competitors". This post and your post both rung true for me.

It's a constant balancing act. Too flexible, it becomes overwhelming. Too constrained and you sacrifice a bunch of the perks of using Docker.

The conclusion I've come to is the only way to do it is to be unashamedly opinionated about keeping things simple for the average user. Otherwise you end up having that exact conversation

Re: “It's The Future”

#300

Post by collyw »

6DM wrote: post #247
huuu wrote: post #160

Earlier quoted context omitted.

"I am frustrated by the industry as a whole" Unfortunately I have to agree as a developer. My job is to make a fast, reliable, stable product but at the same time I'm questioned the tools I use by people who don't have any knowledge but heard the latest trend. But sometimes it's also very easy to please people. Big data: just insert 10M records in a database and suddenly everyone is happy because they now have big da…

On a positive note, it sounds like proprosals to use newer technology are welcome. I keep seeing the opposite, "No this is too different, could break stuff."

If it ain't broken, why fix it?
Post reply on HN