Hacker News Reader

Comment by rglover | Hacker News Reader

Microservices and serverless were the "we've jumped the shark" point for me.

Both can be a great pattern applied properly (nasty scaling problems), but they became a religion or a replacement for entire stacks. I see so many devs these days who are clearly confused but have no idea what they're doing is overly complex—they just think it's normal.

AWS and the like are great, but the move to make everything cloud-based is going to lead to a lot of unmaintainable (or in extreme cases, unsalvageable) messes later. It will be a sad day when devs only understand how to build or deploy something if it's using a heavily-abstracted corpo stack, or even worse, "no code."

View on HN

Conversely, I've seen overly complex but "normal" monoliths. Thousands (millions?) of lines of dead code. Three copies of a file, all 80% the same, but only one in use.

We say one or the other is overly complex, but I think both are knife throwing just with slightly different details. If you can grok system design, microservices are easier to reason about. If you maintain your monolith well, it's easier to reason about.

> Three copies of a file, all 80% the same, but only one in use.

I too have seen this. The one benefit of monolith in this case is the three files are in the same repo so at least it's (theoretically) easier to standardise on just one.

If they're cross-repo duplicates, then it's a little trickier.

That complexity is due to developer laziness, lack of discipline, and inexperience—not the pattern. And again, it's not monolith vs. microservices. It's "when is each technique best applied and why?"

> Microservices and serverless were the "we've jumped the shark" point for me.

I'm not really familiar with micro-services.

Could you give me a concrete example of a system that people would built with a micro-services approach but would be simpler as a monolith?

> a system that people would built with a micro-services approach but would be simpler as a monolith

It's not a binary decision. Micro-services are a tool/technique best applied piecemeal for specific things. For example, "we started out with our API in the monolith but it's got more traffic than we expected so we should split it off to its own service."

The point I was making is that people take this wholesale approach and add unnecessary complexity (i.e., split the API, the payments system, the DB/ORM layer, etc. off into services from day one).

no code will increase alongside ai, developers won't have jobs in the future. it'll be interfaces where the system builds it's solution okay after you tell it what you want. basically jit on steroids

all of the no code creations I have seen posted on this site in the past month are incredibly slow and sluggish. Sometimes even straight up buggy, for instance that font compare picker thing, would sometimes load no font (null) on the left side. As a paradigm, it has a long road to go.

If people really think that no code is acceptable, then I am going to cry. It won't be an improvement.

Yes. It's not about improvement, it's about ease of use and reduction of work, or: convenience. That convenience is going to bite an incredible number of people from behind and send a lot of businesses spiraling.

Will there really be a no code, or is that just moving the level of abstraction one more level higher... While still needing occasional coding to solve those bits that aren't available...

I will have to see it to believe it. 4GL promised the same thing. I actually look forward to the day happening when I become a farrier in the car age. A lot of people smarter than me will turn from code hopefully to hard science and we can start advancing again.

Do you think science is stagnating because React jobs are sucking the firehose of smart hard-working people?

Fortran also promised the same thing.

The bad developers won't, the good ones will. It's going to be very lucrative to know your stuff when nobody understands what the no code approach is doing under the hood.

I have found that both Microservices and serverless work well for "batch-type" writing applications where data is processed asynchronously.

It does not work so well for interactive reading applications like a REST-api.

The future is SharePoint workflows!

As someone forced to use them on a daily basis, they are at least open to being used in an overly restrictive corporate environment and insultingly easy to use. But yes.

I had to fix someones workflow where they had it kicking off other workflows endlessly stuck in a loop until someone changed something. They could take a week to follow up.

So no, I think only trained teammembers should be allowed to touch them. Even simple coding with workflows is difficult for non-programming oriented people.

Reply on news.ycombinator.com