[deleted]
Service-Disoriented Architecture
31–40 of 46 posts
Re: Service-Disoriented Architecture
#32Indeed. 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?
[deleted]
Re: Service-Disoriented Architecture
#33Ah, it seems we have moved to the deprecation phase of the buzzword lifecycle. Consultants and pundits would be well-advised to begin seeking the next thing. Meanwhile, those of us who actually build systems will probably continue to make all our services as small as possible, and to compose systems from discrete processes that may or may not require more than one computer.
[deleted]
Re: Service-Disoriented Architecture
#34It seems to be a common fault of youth to assume that you can solve every problem with just another level of abstraction. I call myself happy that I have used a lot of Java in my university days. The nice thing about Java is that you have so many tools and frameworks that do a lot of great things but always try to be as flexible as possible, ending with you having the power to do the same stuff in the library that you could have also done with pure Java: everything. I'm lucky because I never head to spend years writing such a tool that can do everything but nothing really well. Thanks to many tools who already made that mistake I could learn it by using it just a few weeks.
Re: Service-Disoriented Architecture
#35re 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,…
While you're technically correct, bear in mind that the central difficulty with microservices is managing dependencies.
The worst-case for dependencies across service boundaries in a system with n services is (n - 1)*n. If n is 3, you have a theoretical maximum of 6 direct dependencies. If n is 10, that number is 90.
Which is quite a big difference.
Re: Service-Disoriented Architecture
#36I think the biggest issue is to realize whether we are designing for humans or machines.
In all my work building big systems, microservices have never really made sense. The vast amount of developer time is spent in code where things are already nicely separated with solutions, projects, namespaces, IoC, etc.
When it's all deployed and running, who cares if it all goes out as one big monolith? The machine doesn't, it's all just code. It's way easier to deploy everything with a master version on the package and it guarantees everything works together. Easier to monitor, configure and scale. It'll probably run faster too. You can still use queues/message bus/whatever to talk to other systems but outside of that, I feel a lot of the reasons for SOA are over stated and often unnecessary. As the overall business gets bigger, maybe certain large systems can get isolated but a lot of this microservice/tiered stuff is way too granular and ultimately unproductive.
Re: Service-Disoriented Architecture
#37Agree with many of the points expressed here.
One area where microservices are very useful is in constrained environments, where being able to swap out idle services at runtime makes a lot of sense. This was actually the original driver for OSGi.
Re: Service-Disoriented Architecture
#38This 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?
Keep it simple and YAGNI aggressively - the easiest code to refactor is the code you didn't write yet. Follow ordinary good design practice (single responsibility in particular). Beyond that, don't worry about it yet - one hour's refactoring in the future when you know exactly what you're doing with the services is worth ten now while things are uncertain, so better to save the time.
Re: Service-Disoriented Architecture
#39re 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,…
That part's a sop. Start with a set of size 1 - aka a monolith.
Re: Service-Disoriented Architecture
#40Ah, it seems we have moved to the deprecation phase of the buzzword lifecycle. Consultants and pundits would be well-advised to begin seeking the next thing. Meanwhile, those of us who actually build systems will probably continue to make all our services as small as possible, and to compose systems from discrete processes that may or may not require more than one computer.
And someone might even thank you that you don't have to halt payment processing when you need to rollout a change to your Careers page.