Goodbye Microservices: From 100s of problem children to 1 superstar • Hacker News Board

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

#611

Post by loliboli » Wed, Jul 11, 2018, 7:31 AM UTC

eropple wrote: post #534

kapv89 wrote: post #515

Earlier quoted context omitted.

"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm ( http://typeorm.io/ )?

I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understand…

I’d recommend you to have a look at Objection.js: https://github.com/Vincit/objection.js/

Objection.js is an ORM for Node.js that aims to stay out of your way and make it as easy as possible to use the full power of SQL and the underlying database engine while keeping magic to a minimum.

^^ copy+pasted from github

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

#612

Post by eksemplar » Wed, Jul 11, 2018, 7:34 AM UTC

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.

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

#613

Post by dotdi » Wed, Jul 11, 2018, 7:39 AM UTC

Another article with the TL;DR similar to "we jumped blindly on the bandwagon, did obvious mistakes along the way, and microservices are the root of all evil".

Thanks, but no thanks.

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

#614

Post by lolive » Wed, Jul 11, 2018, 7:45 AM UTC

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…

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

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

#615

Post by smadge » Wed, Jul 11, 2018, 7:45 AM UTC

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.

>> 33 years of software development. > Wait till you get older.

Presumably someone with 33 years of software development experience is around 50 years old. How old do you think someone needs to be before they are qualified to comment on trends in software development practices? 70 years old?

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

#616

Post by ako » Wed, Jul 11, 2018, 7:53 AM UTC

lolive wrote: post #614

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…

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

Reality is that the IT solution of any company consists of multiple separate applications which need to be coordinated into one working solution.

From this reality it's good to design everything as if it's a (micro|macro)service part of a larger landscape of apps.

Reality is also that you can never have transactions for everything across all your systems, so transaction alternatives like compensations are always something to deal with.

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

#617

Post by Cthulhu_ » Wed, Jul 11, 2018, 7:54 AM UTC

kohlerm wrote: post #601

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…

It looks to me that the shared library issue got solved by the monorepo approach. They could have gone the monorepo way and still have microservices. Managing a lot of repos and keeping them consistent with regards do dependencies is not easy. In reality you do not want everyone to use a different version of a dependency. You might allow deviations but ultimately you wand to minimize them. They also just might have h…

Next to a monorepo they would also need a deployment strategy allowing them to deploy multiple services (e.g. every service that was affected by the library change) simultaneously, so that after deploying they can still talk to one another. For a single service this is doable enough (start up, wait for green health, route requests to new service instance), but it increases in complexity when there's >1 service. I'm sure the process can be repeated and automated etc, but it will be more complex. Doing zero-downtime deployments for a single service is hard enough.

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

#618

Post by some_account » Wed, Jul 11, 2018, 7:59 AM UTC

smadge wrote: post #615

eksemplar wrote: post #612

Earlier quoted context omitted.

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.

>> 33 years of software development. > Wait till you get older. Presumably someone with 33 years of software development experience is around 50 years old. How old do you think someone needs to be before they are qualified to comment on trends in software development practices? 70 years old?

He is correct though. Not only software, but lots of things are cyclical and come back in different forms. And you do have to have a few decades of life experience to be part of that.

I also would totally agree that companies should never just adapt "best practices" because those leads to super complex enterprise systems which are not necessary for most companies.

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

#619

Post by Cthulhu_ » Wed, Jul 11, 2018, 7:59 AM UTC

nikon wrote: post #436

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 Changing one "shared library" shouldn't mean deploying 140 services immediately. They had one service to begin with forked for each destination. Of course that was a nightmare to maintain!

I can see their reasoning though; most of those services are pretty straightforward I think (common data model in -> transform -> specific outbound API data out -> convert result back to common data model). The challenge they had is that a lot of the logic in each of those services could be reused (http, data transformation, probably logging / monitoring / etc), so shared libraries and such.

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

#620

Post by MickerNews » Wed, Jul 11, 2018, 7:59 AM UTC

smadge wrote: post #615

eksemplar wrote: post #612

Earlier quoted context omitted.

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.

>> 33 years of software development. > Wait till you get older. Presumably someone with 33 years of software development experience is around 50 years old. How old do you think someone needs to be before they are qualified to comment on trends in software development practices? 70 years old?

He saw OP's argumentum ad verecundiam and raised it.