Microservices dependence management - Governance or Domain Driven Design? -
background: international company federation model transforming microservices due chronic monolithic pain. autonomous teams quick deployment highly desirable. in spite of theory, services indeed dependent on each other higher functionality, autonomous (independently developed , deployed). since federation model , decentralized control, cannot impose strict rules - un. without governance platform manage dependencies else due multiple versions in production in different countries, foresee uncontrollable chaos.
let's call set of microservices needs collaborate "compatibility set". service can deployed may not satisfy higher functionality in compatibility set. example microservice a-4.3 autonomous, deployed , working perfectly. satisfy businessfunctionality 8.6 must work microservice b-5.4 , microservice c-2.9. (a-4.3 , b-5.4 , c-2.9) form "compatibility set"
there 2 approaches dilemma. microservice in real life rubber hits road , learning experience begins...
approach 1) governance platform
rationale: federal model in international company in 100+ countries. means central can lay down model individual countries can choose own destiny - , do. devolves chaos , central team on hook. ddd solution ideal world version inconsistencies not derail functionality releasing services not fit compatibility set, individually blameless fall apart or result in flawed or inconsistent functionality.
- there no homogeneity, there isn't standardization of terminology
- developers mixed skill, many junior, , many learning reactive programming , cloud native technologies
- bounded context heavily depends on shared vocabulary , can subtle, impossible enforce , naive assume in international, mixed skill, fragmented scenario multiple versions running
- standardization on single business model not realistic in such heterogeneous system (but ideal)
how central when they're held responsible chaos?
enforce governance platform create microservices governance system or framework enforce dependency management. verifies , enforces @ design , run time dependencies on particular microservice through manifest , performs checks , balances verify service implementations being offered - "compatibility set".
approach 2) domain driven design (ddd) ddd modelling domains evolving, domain experts (typically business stakeholder, or perhaps analyst) work alongside developers design system. within each domain, ubiquitous language formed, such within context, same word means same thing. important thing realise in 1 part of system, “order” might mean 1 thing, might mean example list of products. in part of system, “order” might mean else, might mean financial transaction happened. model describe can fall down, if service needs list of orders, perhaps there capability out there supplies list of orders, orders they? list of products or financial transaction? trying coordinate many developers have use same language here impossible task doomed fail.
in ddd, rather trying manage @ system level , force every service use same definition of order, ddd embraces inherent complexity in coordinating large deployments huge numbers of developers involved, , allows each team work independently, coordinating other teams needed, not through centralised dependency management system. term used in ddd bounded contexts, in 1 context, order means 1 thing, , in bounded context, order can mean thing. these contexts can function autonomously – describe services being autonomous, if have match definition of order entire system registering , supplied dependencies central registry, tightly coupled rest of system , considers order – end painful coupling of monolith, pain of building distributed system, , won’t realise many of benefits of microservices if try take approach.
so ddd based approach doesn’t ever try take heavy handed approach of enforcing dependencies or capabilities @ system level, rather, allows individual teams work without needing central coordination, if service needs interact service b, team manages service work team manages service b, can build interface between bounded contexts, , come agreement on language interface. these teams manage dependencies each other, @ system level things can remain quite opaque / unenforced.
too see people implement “microservices” end system as, if not more inflexible, , more fragile, monolith. called "minilith" or "monolith 2.0" microservices require complete rethink of architecture , software development processes, , require not allowing services autonomous , independently managed, teams independent, not centrally managed. centralising management of dependencies , capabilities in system inhibitor building microservice based system.
intelligent , pragmatic comments invited...
approach 1 (governance) pragmatic , tactical , intended solve real challenges. question - undermine long term strategic ddd model of enterprise?
approach 2 (ddd) ideal , aspirational doesn't address real challenges have deal right now.
opinions? thought? comments?
i've seen multi-national companies try cooperate on project (or controlled central team) , it's nightmare. response highly subjective i've read , seen, it's opinion, it's not everyone's opinion. broad questions aren't encouraged on stack overflow attract highly opinionated answers.
i'd ddd isn't answer. you'd need large number of developers buy ddd idea. if don't have buy-in (unless have team of exceptionally self-motivated people) you'll see developers try build new system on-top of existing database.
i'd argue microservices aren't answer. companies have used microservices advantage using them compartmentalise code small, stacks of individually running services/apps each single job. these microservices (from success stories i've seen) tend loosely coupled. imagine if have large number of services highly coupled, you've still got spaghetti aspects of monolith, 1 that's spread out on network.
it sounds need architected system, designed specific needs. agree using ddd great, realistic goal across multi-national project?
Comments
Post a Comment