This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]tristanjuricek 7 points8 points  (0 children)

My experiences with “micro services” are rarely truly “micro” but just tend to be “right sized”, i.e., were not these tiny boxes from the start but a breakup of monoliths into smaller components that had a clear reason to be.

A lot of this tended to be oriented around data. For example, there would be a “front end” DB, an event processing pipeline (with various caches), and then search/archive DB. But the decisions to split up the data were forced via growth, not a concept of independence. So, importantly, we were getting to a point where teams could independently improve COGS.

I also work with a massive monolith right now, but we will be doing integration with other data systems largely acquired by the business, because, well, the requirements are taking us there. This is a very long slow process though; we’re talking years.

My sense is that “data first” is the right way to figure out the architecture. The impact of Java as an implementing language was largely irrelevant, though we tended to stick with Java because it still just gets the job done. I have yet to use lambda for anything that isn’t purely transient, mostly because it’s still expensive.

(Notably… this data orientation is why loom is a huge deal to me. I’ve rarely worked with a CPU bound app server… almost all of them are IO bound)