Modules vs. Monoliths vs. Microservices
Are microservices always desirable? Are monoliths always a bad thing? Read on for some insight on keeping your options open.
Join the DZone community and get the full member experience.Join For Free
|Dan Bader (@dbader_org)|
|4/21/17, 7:35 PM Worth a read: "Modules vs. Microservices" (and how to find a middle ground) oreilly.com/ideas/modules-…|
"don't trick yourself into a microservices-only mindset"
Thanks for sharing.
The referenced post gives you the freedom to have a "big-ish" microservice. My current example has four very closely related resources. There's agony in decomposing these into separate services. So we have several distinct Python modules bound into a single Flask container.
Yes. We lack the advertised static type checking for module boundaries. The kind of static type checking that doesn't actually solve any actual problems, since the issues are always semantic and can only be found with unit tests and integration tests and Gherkin-based acceptance testing (see Python BDD: https://pypi.python.org/pypi/pytest-bdd and https://pypi.python.org/pypi/behave/1.2.5).
We walk a fine line. How tightly coupled are these resources? Can they actually be used in isolation? What do the possible future changes look like? Where is the swagger.json going to change?
It's helpful to have both options on the table.
Published at DZone with permission of Steven Lott, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.