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

Goodbye Microservices: From 100s of problem children to 1 superstar

segment.com

Post reply on HN
Print view View original

721–730 of 782 posts

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#721

Post by ChicagoDave »

eksemplar wrote: post #612
ChicagoDave wrote: post #605

I’ve been tracking the comments and my sense is that almost no one here believes the business domain drives the technical solution. Microservices, when constructed from a well-designed model, provides a level of agility I’ve never seen in 33 years of software development. It also walls off change control between domains. My take from the Segment article is that they never modeled their business and just put services…

Wait till you get older. I’ve seen the hype swing from micro services to soa and back to micro services a few times already. I think the key is doing something that works, for you, and care a little less about what other people are doing. Most paradigms have their advantages and disadvantages and it’s really just about working around that to best utilize the stuff you have.

First of all, I'm 54 and started coding at 15 on punch cards, so I've seen pretty much every paradigm in the last 40 years.

It's certainly a truism that technology can be cyclical, but that's not relevant in this case.

The OP's statement and article "Goodbye Microservices" is anecdotal and incorrect.

I have been on teams developing microservice architectures for about six years and this particular paradigm shift has proven to be a dramatic leap forward in efficiency, especially between the business, technical architecture, and change control management.

When you develop a domain model, the business can ask questions about the model. The architects can answer them by modifying the model. The developers can improve services by adopting model changes in code. This is the fundamental benefit of domain driven design and works fluidly with a microservice architecture.

There's still a pervasive belief in technology circles that software should be developed from a purely technical perspective. This is like saying the plumber, electrician, and drywaller should design a house while they're building it. They certainly have the expertise to build a house, and they may actually succeed for a time, but eventually the homeowner will want to change something and the ad hoc design of the house just won't allow for it. This is why we have architects. They plan for change within the structure of a house. They enable modification and addition.

Software development is no different. The Segment developers have good intentions, but they needed to work with the business to properly model everything, then build it. Granted, it sounds like they're a fast moving and successful business, so there are trade-offs. But once the business "settles", they really should go back to the drawing board, model the business, then build Segment 3.0.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#722

Post by danielravina »

acroback wrote: post #123

This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…

why js/ didn't get a cool nickname?

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#723

Post by crimsonalucard »

mrep wrote: post #607
crimsonalucard wrote: post #500

Earlier quoted context omitted.

Those are rhetorical questions. I ask them because these are questions you need to know in order to work well with SQL. I cannot become a master of SQL by only learning SQL. I have to learn the specific implementations, I have to run EXPLAIN... etc... A good abstraction only requires you to know the abstraction not what lies underneath. What we have with SQL is a leaky abstraction. My argument that a high level leaky…

Lol, of course you need a general understanding of how your database works on the inside. There are a million different ways you can store your data and I would argue that choosing your data storage is the most important and tricky decision we have to make as software engineers. Back at my first big tech company, I remember reading the best document I have ever read related to software engineering. It was entirely de…

>Lol, of course you need a general understanding of how your database works on the inside. There are a million different ways you can store your data and I would argue that choosing your data storage is the most important and tricky decision we have to make as software engineers.

You aren't responding to my argument, everything you said is something I already know. So lol to you. You're making a remark and extending the conversation without addressing my main point. I'm saying that the fact that you need "a general understanding of how a database works on the inside" is a design flaw. It's a leaky abstraction.

A C++ for loop has virtually the same performance across all systems/implementations; if I learn C++ I generally don't need to understand implementation details to know about performance metrics. Complexity theory applies here.

For "SELECT * FROM TABLE", I have to understand implementation. This is a highly different design decision from C++. My argument is that this high level language is a bad design choice to be placed over the most critical bottleneck of the web: the database.

The entire reason why we can use slow ass languages like php or python on the web is because the database is 10x slower. Database is the bottleneck. It would be smart to have a language api for the database to be highly optimize-able. The problem with SQL is that it is a high level leaky abstraction so optimizing SQL doesn't involve using complexity theory to write a tighter algorithm. It involves memorizing SQL hacks and gotchas and understanding implementation details. This is why SQL is a bad design choice. Please address this reasoning directly rather than regurgitating common database knowledge.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#724

Post by thermodynthrway »

davewritescode wrote: post #671
stickfigure wrote: post #576

Earlier quoted context omitted.

A little birdie who worked at Grab once told me that they pretty much don't use transactions anywhere. So... maybe there are problem domains where you can get away without transactions, but I'm quite sure that a marketplace that arranges transportation for fee is not one of them. The next time you're standing in a monsoon waiting for the "coming" car that never comes, remember this post :-) Aside from that, I've foun…

Having spent a good amount of time fixing bugs related to code that fetches data with a consistency level of READ_UNCOMMITTED for "performance" reasons I can appreciate what transactions give you as an application developer. However, I would argue that transactions are overkill. What's the worst case scenario if I book a ride for Grab and my request gets corrupted? I'm guessing I'll see an error message and I'll have…

I just set everything to level SERIAL and have never seen data corruption because of it. I guess that makes me old school, lol.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#725

Post by crimsonalucard »

shub wrote: post #590
crimsonalucard wrote: post #502

Earlier quoted context omitted.

I'm saying there could be another high level language that took the place of SQL. An imperative language with explicit algorithmic declarations. I'm not talking about custom solutions, I'm talking about how the web has evolved away from ideas that could have been better, because SQL to me is clearly not what I imagine to be the best we could possibly do for database queries. Same story with javascript and CSS. which…

If deciding join order and what indexes to use sounds like your idea of a good time. It certainly isn't mine.

parameters could have default values or default heuristically chosen values if a default value isn't specified explicitly. Joins can be done imperatively as well. This leads to a language that is more clear and optimize-able by hand.

x = binary_search(column_name=id, value=56, show_all_columns=True)

y = dictionary_search(column_name=id, value=56, show_all_columns=True)

z = join(x, y, joinFunc=func(a,b)(a==b))

The example above could be a join. With the search function name itself specifying the index. If no such index is placed over the table it can throw an exception: "No Dictionary Index found on Table"

This is better api design. However, years of optimization and development on SQL implementations makes it so that most no-sql api's will have a hard time catching up to the performance of SQL. It's like googles V8. V8 is a highly optimized implementation of a terrible language (javascript) which is still faster than wasm.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#727

Post by crimsonalucard »

xg15 wrote: post #394
crimsonalucard wrote: post #276

Earlier quoted context omitted.

The test of time isn't always a good metric. html, css and javascript is a huge hack, yet it has withstood the test of time. SQL to me is a huge design flaw despite it's ubiquity. On the web bottlenecks happen at IO and algorithmic searches. Databases are essentially the bottlenecks of the web and how do we handle such bottlenecks? SQL; A high level almost functional language that is further away from the metal than…

> A select search over an index is an abstraction that is too high level to be placed over a bottleneck. The high-level was the point because, in the original idea, there was a separation of concerns assumed: The dev writes, in SQL, what the DB should do and the DBA decides how the DB does it. Of course that assumes there is a competent DBA...

High level is a mistake because the slowest part of a web project is the database. It's the bottleneck of the web. The reason why we can use slow languages like python, php or ruby on the web rather than C++ is because the database is 10x slower.

Putting a high level leaky abstraction over the bottleneck of the web is a mistake. A language that is a zero cost abstraction is a better design choice.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#728

Post by rhizome »

maerF0x0 wrote: post #132
rhizome wrote: post #130

Earlier quoted context omitted.

You push data consistency concerns out of the database and between service boundaries. Gotta put that CS Masters to work somehow. Can't just sit here doing plumbing all day every day. Maybe there could be a software development corollary to the Politician's Syllogism[1], or even just a webdev one. 1. https://en.wikipedia.org/wiki/Politician%27s_syllogism

there's also this: https://www.karllhughes.com/posts/plumbing

Why I used the word "plumbing."

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#729

Post by marcosdumay »

vajrabum wrote: post #485
marcosdumay wrote: post #439

Earlier quoted context omitted.

> proving nested blocks were objectively better than go-to's Dijkstra spent many, many pages on that. And it's still not a clear cut "this one is always better" case, as there are some obvious exceptions.

If you'd ever had to support some old Fortran or Cobol littered with gotos you'd probably sing a different tune. I'd guess you've never seen that sort of mess though. It's gotten pretty rare.

Well "some excceptions" of course is not the same as the entirely unstructured languages out there.

I've written a lot on the fortran-inspired MS Basic when a child. I know quite well how bad they can become.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#730

Post by crimsonalucard »

wsy wrote: post #681
crimsonalucard wrote: post #514

Earlier quoted context omitted.

The practices of Doctors are based off of science and theory. Design patterns and microservices while technical are not based off of science. They are ideas without quantitiative basis or science.

I agree that we need more empirical investigations of software 'diseases' and 'cures'. That being said, practical medicine is much less scientific than many think. There is a lot of master/apprentice learning going on, just as in software engineering.

I don't even think we need empirical investigations. A formal logic system from axiomatic rules for architecture is really enough. I use the term science here incorrectly. I don't mean experimentation. I mean formalized logic. Like graph theory, complexity theory, number theory.... Architecture Theory.

In the world of math you don't need empirical data to verify a point. It's all logic derived from a small set of axioms.

Post reply on HN