Comment by txutxu | Hacker News Reader

Comment by txutxu | Hacker News Reader

Parent Full thread

I see microservices as responsibility deduplication in a organization-traversal-wide.

De-duplication is a very old concept (differentiates good "sysadmins" from bad ones, since the 90's, and good programmers from bad ones).

Thinking organization-traversal-wide is what is hard for some persons.

Currently working at consulting in a big corp... you get to this problem:

Resource: name FooBar, type int (organization view point)

    app1 name: FooBar  type: int
    app2 name: foo_bar type: int32
    app3 name: Foobar  type: Meta::Foo::Bar
    app4 name: foobar  type: string
    app5 name: fooBar  type: int64

... etc until app 35 and script 192679

Microservices, thinking transversely, solve that. See AWS, GoogleCloud, Azure, etc "resource names" (ARNs, etc), for an example of a simple and great microservice.

Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.

> Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.

This is a pithy encapsulation of something I've been thinking a lot about recently: bud off a microservice from your transactional core if it is higher leverage to do so. Any good readings you've found on this perspective?

An example that comes to mind is: I might write my core application in Ruby on Rails, but need to perform a specialized, CPU-intensive function (PDF generation). I can delegate that to a microservice, invert a CPU-bound problem into an I/O bound one (from the perspective of the Rails core), and get the job done with less hardware.

> I see microservices as responsibility deduplication in a organization-traversal-wide.

AKA SOA. Why call it microservice ?

The Newman book is worth a read - I'm going through it at the moment and a lot is applicable to SOA as well. Microservices is partially a re-branding exercise to take the massive space SOA covers and talk about a more specific definition.

The main thing is the size of the services, the clue being in the name. Also there's a clearer emphasis on the services being more business related concepts, SOA can often described in more techy service splits rather than business concepts.

Reply on news.ycombinator.com