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

Why Segment Went Back to a Monolith

infoq.com

Post reply on HN
Print view View original

271–280 of 328 posts

Re: Why Segment Went Back to a Monolith

#271

Post by mbrameld »

FpUser wrote: post #179
mbrameld wrote: post #116

Earlier quoted context omitted.

A distinction without a difference.

There is a difference. OOP is just one of many tools to help accomplish a task. Many other tools as well. It is up to the people how to use tools for a job and what tools for what job. You equating OOP with the dangerous things that should be kept away has no basis in programming.

The way people use OOP causes them to move the complexity in a particular way. That's why the distinction doesn't make a difference in this context. You're right, technically it wasn't OOP that was writing the code, it was the person. We would have never figured that out without your guidance, we all just though OOP was banging away on the keyboard.

Re: Why Segment Went Back to a Monolith

#272

Post by SeeTheTruth »

gilbetron wrote: post #97
lifeisstillgood wrote: post #10

I have this thing about micro-services/complexity in that it follows Conway's Law - the architecture follows the organisational structure. If you push authority and decision making and responsibility for a service to a (2 pizza) team then guess what, microservices work really well. If you have vast monolithic centralised production operations teams, and no way in hell is their C-Exec going to assign two of them to lo…

Conway's Laws isn't a law, it's just an interesting thought experiment. Organization and architecture bidirectionally effect each other, but not directly, and not completely. I hate how current discourse invokes these different "Laws" as if they are physical properties of the universe. I've worked at places with a strong, hierarchical organization that created a wonderful set of "micro" services, and I've worked at p…

Thank you for everything you said. The reality is more nuanced and depends on the specifics. The "law" being zealously cited here isn't a rule. Nor is the thought an approach is wrong if a big organization failed at it.

Re: Why Segment Went Back to a Monolith

#274

Post by danenania »

dpix wrote: post #269
danenania wrote: post #261

Earlier quoted context omitted.

"Sharing databases across services (micro or not) is generally a pretty bad idea" I don't think such a blanket statement is justified. There are plenty of situations where it may make sense to pull out some functionality into its own service--so it can be written in a different language, scaled independently, isolated from failures, or whatever--but where giving that service its own separate database would be serious…

I didn't mean it as a completely blanket statement, hence why I said "generally". In my experience it's a lot harder to manage a contract between a db schema and multiple codebases over managing versioned contracts between APIs. "It's better to just solve whatever problem you're facing in the simplest possible way." I completely agree with this, but I dont beleive that syncronizing deployments across multiple service…

Fair enough, but I think even "generally" is too strong. There's a huge cost to splitting into multiple dbs, and I'd say it should be avoided by default unless the benefits clearly outweigh the complexity costs. Just to give one example, authentication gets way more difficult with separate dbs, and you get a whole new class of potential security bugs.

Your concerns about versioning and deployments are certainly valid, but I don't think they outweigh the costs of turning your data layer into a distributed system until a project gets very large or those issues are actively causing you headaches.

Re: Why Segment Went Back to a Monolith

#275

Post by bradrobertson »

hedora wrote: post #105

Are there any case studies where microservices went well? From an end user perspective, Netflix runs in “constantly degraded” mod. From an engineering perspective, they track “number of successful stream starts”, instead of percentage of the time 100% of their services are working. That’s a huge red flag. As a researcher, the monitoring and fault-propagation / modeling work they’ve done to get it to stay up at all is…

Like others have mentioned here, simply pointing out examples where microservices have failed doesn't imply that microservices can't succeed. I've attempted to bake bread twice and they both failed. I didn't conclude that baking bread can't be done, but that my skills to do it were insufficient.

There are lots of examples of successful companies using microservices, but I believe the real problem is in defining what constitutes a microservice. Most people call things "microservices" that are nothing of the sort. I can unequivocally say if you built a "service" that depends on other things being 100% available (like another "service") than you haven't built a microservice (ie: those things you built shouldn't be called services).

By that token, autonomy is a pretty important factor. The Udi Dahan teachings (https://particular.net/adsd) (currently available for free) promote this style of architecture. A concrete example of a toolkit for building true microservices can be found in Message DB (https://github.com/message-db/message-db) and/or Eventide (http://docs.eventide-project.org/)

I wouldn't suggest, however, that anyone can just watch the course, pick up these tools and succeed. Like baking a good loaf of bread, it takes a lot of skill, work and experience. Whether or not you succeed at building microservices is ultimately up to you and your team.

Re: Why Segment Went Back to a Monolith

#276

Post by cgrealy »

throwaway894345 wrote: post #259
cytzol wrote: post #242

Earlier quoted context omitted.

This, this, this! It's been said elsewhere in these comments, but the term "micro"-services really do them a disservice, like it's expected that you need to break your application up into little pieces, to eliminate complexity. But many applications are inherently complex, and splitting them up isn't going to get you anywhere. I've been trying to advocate for a "solar system model of services", where you have a big c…

Another aspect no one seems to talk about is whether your deployment is monolithic or fragmented. It seems like a lot of the pain of managing microservices comes from designing a coherent CI/CD pipeline, how to share libraries between various microservices, etc. If you have a monorepo, good build tooling, and a good infrastructure as code tool, I think much of that pain goes away, but none of those things are easy an…

>> If you have a monorepo, good build tooling, and a good infrastructure as code tool,

Yep, and so many organisations ignore these. Especially after a less successful transition to micro-services.

"you mean you want to spend more time doing non-customer visible development? You just did that micro services thing a while ago!"

"Yes, but to take proper advantage of that we need to invest in the right infrastructure and tooling"

"how can I sell that?"

Re: Why Segment Went Back to a Monolith

#277

Post by NomDePlum »

dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

That advice of starting with a Monolith has consistently been given by those involved in Microservices since the start. I remember a Fowler article in particular. Unfortunately the "if you only have a hammer everything is a nail" analogy holds true when people start looking at where microservices may fit into an overall system architecture. Their answer is invariably - everywhere!

Really small, reusable/shareable and stable domains are the sweet spot for microservices. As you say that is most likely to come from decomposing from a monolith. Microservices can really help with building rich domain components in an overall architecture and removing complexity from other components through delegation to the microservice is my experience. They just don't need to be everywhere.

The same problem of over-eagerness is becoming apparent with some of the movement to event-based architectures. People become obsessed acolytes and there is no other way. When in fact they may well be ideal for a portion of your overall system architecture but are unlikely to serve it all well.

Re: Why Segment Went Back to a Monolith

#279

Post by rhizome »

dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

The thing that jumps out to me: there are WAY more page-loading indicators now than there has ever been before. Lots more jumping content, lots more laggy content population, many more elements sliding around...I know "worse is better" is a truism of sorts in technology, but this is ridiculous.

What good do any of these architecture decisions make when the experience for the user, the customer, is measurably worse? I mean, aside from not being able to interact with elements of a page before a chain of JavaScript finally gives the all-clear, sites clearly look worse with grayed placeholders and whatnot. There should be a Conway's Corrollary for revenue-oriented choices.

Re: Why Segment Went Back to a Monolith

#280

Post by throwaway894345 »

cgrealy wrote: post #276
throwaway894345 wrote: post #259

Earlier quoted context omitted.

Another aspect no one seems to talk about is whether your deployment is monolithic or fragmented. It seems like a lot of the pain of managing microservices comes from designing a coherent CI/CD pipeline, how to share libraries between various microservices, etc. If you have a monorepo, good build tooling, and a good infrastructure as code tool, I think much of that pain goes away, but none of those things are easy an…

>> If you have a monorepo, good build tooling, and a good infrastructure as code tool, Yep, and so many organisations ignore these. Especially after a less successful transition to micro-services. "you mean you want to spend more time doing non-customer visible development? You just did that micro services thing a while ago!" "Yes, but to take proper advantage of that we need to invest in the right infrastructure and…

Honestly, that sounds like the devops team didn't communicate well with the business when they pitched them microservices. The business can't reasonably know that moving to microservices entails a change in infrastructure and tooling--you have to build that into your high level estimates.
Post reply on HN