SOA is just Spaghetti Architecture. I haven't seen an implementation that convinces me otherwise.

What is your definition of Spaghetti Architecture? Netflix had a good SOA that enabled rapid development and had strong cut lines between services, with no way to access the data of a service without going through the service's API.

I think that's where most people go wrong. They put a bunch of services in front of a shared database, which means that they don't have to go through a service's API to get to it's data, and that's what breaks everything.

This is really important, and I've gotten a lot of quizzical looks when making this assertion over the years: data is owned by one and only one service. If two pieces of code assert ownership of it by mutating that data or looking past the public encapsulation of that data, then that code is the same service.

If you see a queue between two services, that is usually an indication that some ownership is being transferred (even briefly), and that is a critical point where you need introspection and observation.

> Data sovereignty per microservice

> An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice.

https://learn.microsoft.com/en-us/dotnet/architecture/micros...

The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.

Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures.

I don't recommend either, and it's still a code smell, but with clear definitions they can work.

The benefits of the microservice pattern are you can build separate teams responsible for different business logic, and they can have their own deployment schedule. You don't get either of those benefits when a b and c have to coordinate on their work-order creation business logic, and a, b, c and d all need to be deployed at the same time anytime the schema changes.

Btw some of the confusion might be what I mean by shared database. I didn't mean two services sharing a limited set of tables, using the database as a rabbitmq replacement. I meant sharing the backing database of the microservices. It sounds like we probably agree I just wasn't very clear about what I meant by sharing a database.

(Ironically I am literally using a database as a queue to share data between two services we are running in prod. I don't think of it as a microservice because it's not separate teams, it just because our monolith is hosted on a platform that doesn't support certain libraries so we had to role those libraries onto a separate platform that does support them.)

I think we're in violent agreement - A database can be a queue and that doesn't link things as the same, but it's easy to break those promises and you need to be clear in that promise to begin with. If two "microservices" have to move in strict lockstep, they're not microservices, they're components of a larger service.

That's completely untrue and glosses over the very real costs of transaction management in such an environment.

Using a shared database allows you to punt a lot of that complexity to a system that's been specifically designed for it, and working well for probably 20+ years.

Too many people think microservices don't have their own, severe, downsides. The likes of netflix, google, et al, can afford to pay people whose entire job is to manage the complexities of these approaches that flat don't exist in other scenarios.

But it's a hell of a lot simpler to use a single database if you can get away with it.

Yeah, services should be formed around the needs of data, and you shouldn't run multiple services in the same image/container just to split the code up. It shouldn't ever be about the code.

Amazon's SOA architecture at least all started out about pulling bits of data spread over hundreds of servers into services that could take advantage of caching.

This is it exactly!

I have seen the "data service" design pattern that tries to work around this, by having a CRUD microservice to front a database, providing hundreds of APIs to read/write the data for 50 other microservices. If one of these CRUD microservices goes down, everything breaks.

I feel like it has its place in large organization. But being a large organization means the odds of spaghetti are approaching 100% no matter what you do.

Any general purpose architecture allows spaghetti, there's no way around it.

Has there been an architecture movement that formally embraces the spaghetti, aiming for peaceful coexistence? Detractors will certainly point at SOA and shout "that one!", but I mean one that openly admits..

I’m not sure if this architecture has a name other than “Event Sourcing” but I think giant org wide shared message bus with all services freely pushing and pulling data from it is the closest to embracing spaghetti.

Microservices should be resource-oriented, not service-oriented. NetKernel takes it to the extreme, it’s a shame it hasn’t seen broader adoption.

http://resources.1060research.com/docs/IntroductionToResourc...

this devops is also a dumping ground for anything else not happening on a developers computer which they should control but wont because "That is devops job" mostly this happens alot with node projects for some reason..

Humans are kinda terrible when they can just "not my problem" things.

"anything else not happening on a developers computer which they should control but wont"

Ok, I've seen this, but IME (24y in industry, the last 6 as a consultant) in the vast majority of cases, it's more like "things devs should control but CAN'T [bc CICD etc are silo'd and owned jealously by an overburdened ops team unable or unwilling to facilitate self-service]".

Some of the 'jealousy' may also come from bad experiences.

It only takes a few instances of people royally messing stuff up in production for their deployment rights to be stripped away – and other groups catch the fallout too, as new "procedures" get implemented.

"Safety rules are written in blood" applies to parts of the organisation too.

Sure, there are some overbearing procedure monkeys who really want a process on everything, but a lot of "protection" rules are there because something really bad (and expensive, financially or reputationally) has happened before.

Also, some developers do not seem to know what kind of impact a production issue can have.

Having something not work during the development cycle is annoying for one person or a team. Having something break in production usually means people get paged and (depending on what you do) the resulting issues can have major societal aswell as economic impact.

In the ops world, this is especially visible if you go further down the stack. (from applications down the the network).

Network architecture moves at a toad's pace compared to webdevelopment, which is a good thing considering breaking the network will usually break every other system inside a IT department/landscape.

"Hey, did the front-end new-hire upgrade the Linux distro yet?"

Side rant:

There was an angry Ask HN post a while back about how terrible the "new guys" are that are out there.

It then complained that the new hire wrote a horrible authentication service.

I thought it was an intentionally absurd post about the expectations put on new some rando new guy to write something important / they shouldn't be working alone on ... but they were serious.

>microservices

I never miss an opportunity to share my favorite piece of comedy this decade:

https://youtu.be/y8OnoxKotPQ

it's too close to reality.

There is a good talk that is also comedic as it comes from the perspective of someone who wants to fail at doing microservices.

https://www.youtube.com/watch?v=GWgRw5jiYy0

Thank was pretty funny, thanks.