A common pattern I've seen with companies sprinting head-first into a microservices architecture is something I call "femtoservices" -- when your system is new and doesn't do much, it's easy to split things up into components that are way too small. I've seen systems that essentially have a microservice per database table, effectively destroying any reasonable way to perform non-trivial queries. Fixing this is far harder than splitting out a monolith that has been designed well.
Service-Disoriented Architecture
21–30 of 46 posts
Re: Service-Disoriented Architecture
#22Earlier quoted context omitted.
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…
Code sharing is not the same as using the same library in different places. That is managed by a proper dependencies manager and not as issue. The problem is when people take code from the codebase and spread it all over. In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself.
Re: Service-Disoriented Architecture
#23Ah, 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.
Re: Service-Disoriented Architecture
#24I 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…
Good point.
There is also a funny tangent on it. Garrett Smith (the person responsible for such movies as "MongoDB is Webscale" and "Erlang II: The Movie" http://www.gar1t.com/blog/tags/videos.html) made a comment that Erlang has already been doing nanoservices before microservices were cool.
In a certain way he is right. Each gen_server lightweight process is a small independent service that starts up with only a few KB of memory, has an isolated heap and can be called from another Erlang node from half-way across the world like a you'd call a local process.
Re: Service-Disoriented Architecture
#25Earlier 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.…
Why should oauth be separate from user service?
Re: Service-Disoriented Architecture
#26This 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.
Oh dear Lord. Are you really serious?
>write far more unit tests than functional/integration tests.
This is a terrible idea. Integration tests are by their very nature loosely coupled, whereas unit tests are tightly coupled.
>(if you separate out components later, those tests can't move with them)
If you refactor code under the hood you will inevitably end up throwing away unit tests unless your code is already very loosely coupled.
>if you use an ORM or similar, you are probably going to have a very bad time about it
Using (good) ORMs helps you to significantly reduce boilerplate code. Reducing boilerplate code is always a good thing.
Re: Service-Disoriented Architecture
#27This 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…
[deleted]
Re: Service-Disoriented Architecture
#28Earlier quoted context omitted.
- 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…
Code sharing is not the same as using the same library in different places. That is managed by a proper dependencies manager and not as issue. The problem is when people take code from the codebase and spread it all over. In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of erro…
> Code sharing is not the same as using the same library in different places.
Sounds like you're using a different definition than AdrianRossouw.
> In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself.
That sounds like an issue with the wrapper, not so much the code sharing per se.
That said, I've seen issues with... "overly shared" code. The example that comes to mind was some UI code on a game - we had various menus, and they all tried to share a huge chunk of programmatic UI layout & control flow logic.
However, as so many menus were unique and special snowflakes with their own unique designs and layouts (even justifiably!), this meant the shared code ended up with a lot of special cases. Worse, trying to "fix" the layout to work right in one place usually broke it in another. QA eventually caught almost everything, but it was hell to fix and debug.
I would've very gladly eaten a 5x total size increase to the relevant code, full of copy & paste duplication, rife with bugs that were fixed in 7 places but missed in 3 others, just to detangle those menus from each other.
Re: Service-Disoriented Architecture
#29Earlier quoted context omitted.
Code sharing is not the same as using the same library in different places. That is managed by a proper dependencies manager and not as issue. The problem is when people take code from the codebase and spread it all over. In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of erro…
> Code sharing is not the same as using the same library in different places. Sounds like you're using a different definition than AdrianRossouw. > In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself. That sounds like an issue with the wrapper, not so much the cod…
I've seen what you described too. It's crazy. The wrapper I mentioned was about making code sharing easier. Never taking into account that Django already provided a fairly clean interface to work with. These guys were wrapping Django ORM query code with funciones that took an infinite amount of parameters through Python's kwargs parameter. Nuts.
Re: Service-Disoriented Architecture
#30Earlier quoted context omitted.
Code sharing is not the same as using the same library in different places. That is managed by a proper dependencies manager and not as issue. The problem is when people take code from the codebase and spread it all over. In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of erro…
> Code sharing is not the same as using the same library in different places. Sounds like you're using a different definition than AdrianRossouw. > In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself. That sounds like an issue with the wrapper, not so much the cod…
I've had to deal with this exact same problem of unrelated UIs sharing UI layout & control flow logic, messily packaged deep in 8 layers of inheritance... A nightmare. It was a GWT + GXT codebase. The worst is that I did partake into creating the mess in the first place.
Now when it comes to UIs I favor decoupling at the expense of a little code duplication. Because two otherwise unrelated menus happen to share the same layout/structure/flow at a given time, doesn't mean this structure needs to be abstracted away: the code is likely to diverge later anyway as the unrelated views evolve.
Abstracting away composable patterns for GUIs is hard. Especially for me given that I mostly write backend code...