4 ms·
I guess I am in what the author termed the "naysayers" camp, in that I cannot think of the "monolithic" variation they depicted as a "service-oriented architect
by markbnj 11y ago
I guess I am in what the author termed the "naysayers" camp, in that I cannot think of the "monolithic" variation they depicted as a "service-oriented architecture" of any kind. A single chunk of stuff sporting a lot of different APIs and interfaces can't be thought of as implementing services, imo, unless "services" is synonymous with "API" and for my part that is too general a definition to be of much use. If you agree with my view then services already required a separately designed, implemented, and managed piece of code that implements a single cohesive set of functions, and all that's left for microservices to add is minimality, which, imo, should already be in the mix.
- deathanatos 11y agoI feel that I'm a proponent of microservices that has only ever worked on monolithic apps. > I cannot think of the "monolithic" variation they depicted as a "service-oriented architecture" of any kind. I think you're on the right track here. Note that the article uses "monolithic application", not "monolithic services"; it really is the lack of services. > unless "services" is synonymous with "API" and for my part that is too general a definition to be of much use I agree that that is too general. To me, a microservice would of course expose an API, but whereas a monolithic application exposes the entire application (or, perhaps, the entire API for everything your company does…), a microservice is exposing a small facet of the overall application, and is only responsible for that facet. I probably agree with you that "services" is probably what most of us are after; I think the "micro" may just be an attempt to re-emphasize that it shouldn't be one huge thing, and that perhaps you should split services off sooner, rather than later, as it only ever gets harder. Then again, I've never worked with in a microservices-oriented architecture.