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

Service-Disoriented Architecture

bravenewgeek.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Service-Disoriented Architecture

#11

Post by AdrianRossouw »

andreasklinger wrote: post #6

This discussions tend to focus on the two extremes. What are best practices for making monoliths ready for future SOA design - Workers listening on event bus - Database queries abstracted in RepositoryObjects - ServiceObjects isolating domain logic - Specs isolated around concepts - Extracting to plugins (eg vendored gems) if not part of domain logic What are your recommendations?

I've seen a couple of codebases now that have coded themselves into corners and made it nearly impossible to go microservices without a major rewrite.

- avoid code sharing wherever possible. It creates an implicit dependency. (If you have a common library or util file, you've done it wrong. try again.)

- don't merge your trees: (ie: each component in the code should have it's own readme and tests folder.)

- write far more unit tests than functional/integration tests.

  (if you separate out components later, those tests can't move with them)
- if you use an ORM or similar, you are probably going to have a very bad time about it

  (breaks the no-shared code rule)

Re: Service-Disoriented Architecture

#12

Post by andyidsinga »

re this:

  > The better strategy is a bottom-up approach. Start with
  > a monolith or small set of coarse-grained services and
  > work your way up. Make sure you have the data model
  > right.
the part about "or a small set of coarse-grained services"

I like this advice, but this is effectively starting with SOA! - just coarse grained. So the drive of this post should be so start with a simpler SOA, don't pre-optimize etc, not build a monolith.

Re: Service-Disoriented Architecture

#13

Post by aboodman »

AdrianRossouw wrote: post #11
andreasklinger wrote: post #6

This discussions tend to focus on the two extremes. What are best practices for making monoliths ready for future SOA design - Workers listening on event bus - Database queries abstracted in RepositoryObjects - ServiceObjects isolating domain logic - Specs isolated around concepts - Extracting to plugins (eg vendored gems) if not part of domain logic What are your recommendations?

I've seen a couple of codebases now that have coded themselves into corners and made it nearly impossible to go microservices without a major rewrite. - avoid code sharing wherever possible. It creates an implicit dependency. (If you have a common library or util file, you've done it wrong. try again.) - don't merge your trees: (ie: each component in the code should have it's own readme and tests folder.) - write far…

> avoid code sharing wherever possible

Err, wut? It sounds like you are saying that pretty much the one reliable guideline in the history of software has become a bad idea.

(I have come across places in my career where code sharing was not worthwhile, but they have been rare. And I frequently regretted the decision later.)

Re: Service-Disoriented Architecture

#14

Post by Xixi »

I will be the guy bringing Erlang (or more precisely BEAM -the Erlang VM- and the various languages that run on top of it) into this thread... But it's amazing how much Erlang got right so long ago. Erlang applications are effectively fine-grained, Service Oriented, with a very low overhead.

There is, of course, one drawback: you loose the low overhead advantage as soon as you step outside of the Erlang world. That's a major drawback given that a non-negligible part of the Service Oriented Architectures appeal is the possibility to use the best possible tool for a given job, no matter what language/VM/hardware that tool is built with...

Re: Service-Disoriented Architecture

#15

Post by chris_wot »

zarvox wrote: post #4

Indeed. CRUD apps (which I'll argue are the vast majority of applications) are easier to write, easier to understand, and easier to make have the behavior users expect when there's only one datastore and you never have to deal with eventual consistency or distributed or half-applied migrations. As an anecdote, at a previous employer, we provided user accounts and OAuth for connecting these accounts to our API. We mad…

Isn't that more an issue of multiple databases than an SOA issue?

Re: Service-Disoriented Architecture

#16

Post by zarvox »

chris_wot wrote: post #15
zarvox wrote: post #4

Indeed. CRUD apps (which I'll argue are the vast majority of applications) are easier to write, easier to understand, and easier to make have the behavior users expect when there's only one datastore and you never have to deal with eventual consistency or distributed or half-applied migrations. As an anecdote, at a previous employer, we provided user accounts and OAuth for connecting these accounts to our API. We mad…

Isn't that more an issue of multiple databases than an SOA issue?

Perhaps, but even a single database alone doesn't ensure atomicity.

For instance: suppose you're deactivating a user. You've got a user table, with an id column and a "deactivated" column. Then you've got an OAuth tokens table, with a foreign key column to userid.

If you had two microservices hitting the same database, then you make a DELETE to the user service, which now needs to send a DELETE to the OAuth service. Now, regardless of which transaction you logically have go first, you have a race: two services with separate transactions are modifying the same DB. Whichever transaction commits, the other could fail, leaving your external view inconsistent.

One way to solve this is to have the OAuth service check the user table to see if the user is disabled, and treat all of the tokens for that user as deactivated, but then your OAuth service is tightly coupled to your user service's schema, which means you can no longer modify the two services separately. My impression is that this isn't really what people mean when they say "microservices".

Another option is to have the OAuth service ask the user service if the user is still live, but now you have a circular dependency between services, and either one failing can effectively put the other out of commission.

Tradeoffs in all things.

Re: Service-Disoriented Architecture

#17

Post by andrewflnr »

pech0rin wrote: post #9

It seems like an endless cycle of some new trend coming out (microservices), then the reactionary comments which create even more new trendy buzzwords. Application design and development is not this black and white. SOA is not GOOD or BAD. It is a design structure that some people like, and some people seem to hate. There are good ways of doing things and bad ways of doing things. In my experience, having small manag…

You just rephrased the OP in a confrontational tone. It didn't say that SOA was bad, just overused in some places where it's not appropriate. It looks like the closest thing you have to a disagreement is that you can probably still get the some of the small code-base benefits while not getting into the distributed-systems stuff the article talked about (making sure your processes are all on the same machine or something, I don't know).

Re: Service-Disoriented Architecture

#18

Post by thefreeman »

AdrianRossouw wrote: post #11
andreasklinger wrote: post #6

This discussions tend to focus on the two extremes. What are best practices for making monoliths ready for future SOA design - Workers listening on event bus - Database queries abstracted in RepositoryObjects - ServiceObjects isolating domain logic - Specs isolated around concepts - Extracting to plugins (eg vendored gems) if not part of domain logic What are your recommendations?

I've seen a couple of codebases now that have coded themselves into corners and made it nearly impossible to go microservices without a major rewrite. - avoid code sharing wherever possible. It creates an implicit dependency. (If you have a common library or util file, you've done it wrong. try again.) - don't merge your trees: (ie: each component in the code should have it's own readme and tests folder.) - write far…

- avoid code sharing wherever possible. It creates an implicit dependency. (If you have a common library or util file, you've done it wrong. try again.)

Can you clarify on this a bit? Isn't part of the point of classes and libraries to encapsulate common functionality so that it doesn't need to be separately maintained in multiple places?

You listed an ORM as an example, what is a better solution to managing database interaction across an application?

Re: Service-Disoriented Architecture

#19

Post by PretzelFisch »

AdrianRossouw wrote: post #11
andreasklinger wrote: post #6

This discussions tend to focus on the two extremes. What are best practices for making monoliths ready for future SOA design - Workers listening on event bus - Database queries abstracted in RepositoryObjects - ServiceObjects isolating domain logic - Specs isolated around concepts - Extracting to plugins (eg vendored gems) if not part of domain logic What are your recommendations?

I've seen a couple of codebases now that have coded themselves into corners and made it nearly impossible to go microservices without a major rewrite. - avoid code sharing wherever possible. It creates an implicit dependency. (If you have a common library or util file, you've done it wrong. try again.) - don't merge your trees: (ie: each component in the code should have it's own readme and tests folder.) - write far…

How do you deal with business logic getting updated correctly across all modules that write to the database without some shared file or library?

Re: Service-Disoriented Architecture

#20

Post by dvanduzer »

zarvox wrote: post #16
chris_wot wrote: post #15

Earlier quoted context omitted.

Isn't that more an issue of multiple databases than an SOA issue?

Perhaps, but even a single database alone doesn't ensure atomicity. For instance: suppose you're deactivating a user. You've got a user table, with an id column and a "deactivated" column. Then you've got an OAuth tokens table, with a foreign key column to userid. If you had two microservices hitting the same database, then you make a DELETE to the user service, which now needs to send a DELETE to the OAuth service.…

OAuth is better considered a microservice that grew a little too big. Strong consistency in identity management is a well studied problem. This is why people pay money for Active Directory consultants.

edit: The trick to your particular dilemma is to design your operations more carefully. Don't allow sensitive operations for any service via long lasting authentication tokens.

Post reply on HN