Service-Disoriented Architecture
bravenewgeek.com
Service-Disoriented Architecture
1–10 of 46 posts
Re: Service-Disoriented Architecture
#2While the overhead of SOA is pretty well documented and understood, I feel like this is the crux of it: "Adopting a microservice architecture does not automatically buy you anti-fragility."
Not only do you have new, hard problems -- but you didn't just innately get a solution to your previous problems. I've seen this in practice, and it is pain, all around. There's immense organizational overhead to having your core product distributed across 4x as many projects/repos/components as you have developers. And if you haven't actually solved all the fragility and failover problems, you are very fucked.
Re: Service-Disoriented Architecture
#3Surprised security wasn't mentioned as a reason to decouple services (IMO security is a top reason to split out a service).
Otherwise I tend to agree with the author.
Re: Service-Disoriented Architecture
#4Indeed.
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 made separate user and OAuth services, with separate databases.
What resulted was an unnecessary amount of complexity in coordinating user deactivation, listing OAuth tokens for users, delegation, and doing all that while authenticating requests between microservices. Our API could not safely expose a method to deactivate a user and all of their OAuth tokens in a single DELETE. A single instance that handled both would have been easier to build and wasted less time up front dealing with complexity that we didn't need or make good use of for our scale at the time.
To solve this, we eventually merged all the data back into a single database, so we could expose sane invariants at the API level without needing to build an eventually-consistent message queue.
Re: Service-Disoriented Architecture
#5Surprised security wasn't mentioned as a reason to decouple services (IMO security is a top reason to split out a service). Otherwise I tend to agree with the author.
Can you explain that a bit more? What added security benefits do micro services provide that couldn't be accomplished using role- or claim-based authorisation?
Re: Service-Disoriented Architecture
#6This 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?
Re: Service-Disoriented Architecture
#7Surprised security wasn't mentioned as a reason to decouple services (IMO security is a top reason to split out a service). Otherwise I tend to agree with the author.
Can you explain that a bit more? What added security benefits do micro services provide that couldn't be accomplished using role- or claim-based authorisation?
I'd guess that what he means is that an attacker who compromises one micro service may not end up compromising all of them, whereas if they compromise a monolith, they have access to everything.
Re: Service-Disoriented Architecture
#8Surprised security wasn't mentioned as a reason to decouple services (IMO security is a top reason to split out a service). Otherwise I tend to agree with the author.
Can you explain that a bit more? What added security benefits do micro services provide that couldn't be accomplished using role- or claim-based authorisation?
Machine separation for one (OS level exploits, escalation of privileges in one component compromising another). Network partitioning with strong protocol filters between security tiers can be invaluable.
Re: Service-Disoriented Architecture
#9It 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 manageable code bases that are responsible for one domain makes things so much easier to develop and maintain. But, that is my opinion not something I think is a universal truth. Architecture/Design/Implementation of any complex system is not an exact science with perfect formulas for creation. It would be nice to have more articles about new and exciting ways of doing things, instead of the same old tearing down of others for being stupid/wrong/etc because they think functional/OO/SOA/microservices/containers/etc is the wrong way to do things.
Re: Service-Disoriented Architecture
#10It 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…
> In my experience, having small manageable code bases that are responsible for one domain makes things so much easier to develop and maintain.
I think everybody agrees with that.
The issue is that architecting your system like that on a code / repo level means that you gain the complexity of having to manage dependencies between your components, and it complicates the deployment story.
microservices then further complicates things by requiring you to be able to independently deploy each service. this is a lot of complexity to manage for something that doesn't directly solve any problems in your business domain.
This reaction you are seeing is because people have now had enough time to actually work on and hear about projects that were built using microservices. Many of them have found that they don't deliver on their promises, because of the reasons mentioned in the article.