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

771–780 of 782 posts

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

#771

Post by timr »

chrisco255 wrote: post #754
timr wrote: post #573

Earlier quoted context omitted.

React makes it easier for bad developers to do complicated things. They still end up writing spaghetti code.

You literally can't write spaghetti code in React due to one-way data flow. That's what prevents the spaghetti. UI is a function of state and props. JQuery is an imperative DOM altering library that isn't even necessary with modern browsers.

If I had a dollar for every person who told me that X prevents people from writing bad code, I wouldn't need to write code.

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

#772

Post by tabtab »

shub wrote: post #593
codedokode wrote: post #510

Earlier quoted context omitted.

PHP might be not the best designed or nice looking language out there, but you cannot even compare it to JS. It has real classes, doesn't require you to put underscore before private methods and type checking. And it issues a warning if you divide by zero or try to access array index that doesn't exist

Is `empty("0")` still true in PHP?

"blank" and "empty" are not the same thing in PHP. If you expect them to be, then you read the manual wrong. I generally include a set of common utilities where I define my own "isBlank()" function, which trims before comparing. There are different definitions of "blank" such that one size may not fit all. (Consider tabs and line-feed characters, for example.)

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

#773

Post by tabtab »

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.

I wish to make it clear I am NOT defending goto's as an actual practice. I'm only saying that objective proof that they are "bad" is lacking. Goto's served as a test case of objective evidence of code design.

Do note that some actual coders have claimed that if you establish goto conventions within a shop, people handle them just fine.

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

#774

Post by tabtab »

techinformed56 wrote: post #53
alexrbarlow wrote: post #2

I'm not sure what they've been left with is a monolith after all. I would say they just have a new service, which is the size of what they should have originally attempted before splitting. In particular, as to their original problem, the shared library seems to be the main source of pain and that isn't technically solved by a monolith, along with not following the basic rule of services "put together first, split la…

+1 I felt this article is more about how to use microservices right way vs butchering the idea. It is not right to characterize this as microservices vs monolith service. Initial version of their attempt went too far by spinning up a service for each destination. This is taking microservices to extreme which caused organizational and maintenance issue once number of destinations increased. I am surprised they did not…

Age-old truth: "Use the right tool for the right job".

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

#775

Post by tabtab »

thermodynthrway wrote: post #460
stickfigure wrote: post #40

Earlier quoted context omitted.

It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. I've never quite understood why people think that taking software modules and separating them by a slow, unreliable network connection with tedious hand-wired REST processing should somehow make an architecture better. I think…

I've heard of even Unicorns throwing consistency out the window. Apparently Netflix has a bunch of "cleanup jobs" that comb the database for various inconsistencies that inevitably show up. You can't have consistent microservices without distributed transactions. If a service gets called, and inside that call, it calls 3 others, you need to have a roll back mechanism that handles any of them failing in any order. If…

Re: I've heard of even Unicorns throwing consistency out the window. Apparently Netflix has a bunch of "cleanup jobs" [to fix "bad" transactions]

If your business model is to be cheap with high volume sales, then corrupting say 1 out of 10,000 customer transactions may be worth it. If you give customers a good price and/or they have no viable alternative, you can live with such hiccups, and the shortcuts/sacrifices may even make the total system cheaper. You are like a veterinarian instead of a doctor: you can take shortcuts and bork up an occasional spleen without getting your pants sued off. But most domains are NOT like that.

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

#776

Post by tabtab »

crimsonalucard wrote: post #759
xg15 wrote: post #733

Earlier quoted context omitted.

This is still a declarative language, just with the algorithms spelled out explicitly. (or some algorithms, as you didn't specify it for the join). However, I think specifying the algorithms in the queries is really not a good idea. Your performance characteristics can change over time (or you might now know them at all yet when you start the project). With your solution, if you, e.g. realize later that it makes sens…

>This is still a declarative language, just with the algorithms spelled out explicitly. (or some algorithms, as you didn't specify it for the join). Declarative yes, but unlike SQL my example is imperative. An imperative language is easier to optimize then a functional or even a expression based language (SQL) because computers are basically machines that execute imperative assembly instructions. This means the abstr…

One is going to need a way to debug and study ANY complex query for performance and bugs. EXPLAIN is a tool, not a crutch. "Dot-Chained" API's don't solve this by themselves. In bigger shops one typically has skilled DBA's who are good and quick at optimizing SQL anyhow because of their experience with it. An app-side programmer won't (or shouldn't) do this often enough to become a guru with query API optimization. Modern economies rely on specialization.

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

#777

Post by crimsonalucard »

tabtab wrote: post #776
crimsonalucard wrote: post #759

Earlier quoted context omitted.

>This is still a declarative language, just with the algorithms spelled out explicitly. (or some algorithms, as you didn't specify it for the join). Declarative yes, but unlike SQL my example is imperative. An imperative language is easier to optimize then a functional or even a expression based language (SQL) because computers are basically machines that execute imperative assembly instructions. This means the abstr…

One is going to need a way to debug and study ANY complex query for performance and bugs. EXPLAIN is a tool, not a crutch. "Dot-Chained" API's don't solve this by themselves. In bigger shops one typically has skilled DBA's who are good and quick at optimizing SQL anyhow because of their experience with it. An app-side programmer won't (or shouldn't) do this often enough to become a guru with query API optimization. M…

Read what I am writing. The fact that EXPLAIN is a tool means SQL is a crutch. No other language other than SQL needs this.

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

#778

Post by grzm »

crimsonalucard wrote: post #777
tabtab wrote: post #776

Earlier quoted context omitted.

One is going to need a way to debug and study ANY complex query for performance and bugs. EXPLAIN is a tool, not a crutch. "Dot-Chained" API's don't solve this by themselves. In bigger shops one typically has skilled DBA's who are good and quick at optimizing SQL anyhow because of their experience with it. An app-side programmer won't (or shouldn't) do this often enough to become a guru with query API optimization. M…

Read what I am writing. The fact that EXPLAIN is a tool means SQL is a crutch. No other language other than SQL needs this.

Ever profile an application? That's what EXPLAIN helps you with. SQL is different from a lot of languages in that it runs through query planner/executor, often based on properties of the actual data which change over time. Not a lot of other programs do this, and certainly not your typical imperative or procedural code. The JVM is one that comes to mind. Do you know of others?

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

#779

Post by crimsonalucard »

grzm wrote: post #778
crimsonalucard wrote: post #777

Earlier quoted context omitted.

Read what I am writing. The fact that EXPLAIN is a tool means SQL is a crutch. No other language other than SQL needs this.

Ever profile an application? That's what EXPLAIN helps you with. SQL is different from a lot of languages in that it runs through query planner/executor, often based on properties of the actual data which change over time . Not a lot of other programs do this, and certainly not your typical imperative or procedural code. The JVM is one that comes to mind. Do you know of others?

I KNOW what it helps you with. No programming language has a keyword that decompiles expressions to their base components. Also profiling is only done when optimization is needed.

SQL on the otherhand... EXPLAIN is used on a regular basis, it's built in to the programming language and rather then just mark lines of code with execution time deltas it literally functions as a decompiler to deconstruct the query into another imperative language. This is the problem with SQL.

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

#780

Post by zerd »

jcelerier wrote: post #241
boramalper wrote: post #101

Earlier quoted context omitted.

Same with BSD; the userspace programs are not part of the kernel, and developed separately by the same entity. Busybox is a slightly better example (even though it’s also a userspace program).

> Same with BSD; the userspace programs are not part of the kernel, and developed separately by the same entity. they're part of the same repo and built at the same time than the kernel. Run a big "make universe" here : https://github.com/freebsd/freebsd and see for yourself. That they are different binaries does not matter a lot, it's just a question of user interface. See for instance busybox where all the userspac…

I would argue that the fact that they're in the same repo does not make it a monolith at all. All of google and facebook is in a single repo and built at the same time, but it doesn't make them monoliths.
Post reply on HN