Architects compare a coarser shared-integration design to independently deployable, narrowly scoped units with decentralized data. In official DEVCOR terms, what distinction are they drawing?
Select an answer to reveal the explanation.
Short Explanation
Think apartment building versus tiny houses: SOA is fewer, larger units with shared utilities; microservices are small, independently owned places. The exam distinction is grain, deploy independence, and data ownership—not a vendor bus brand quiz.
Full Explanation
In official DEVCOR terms they are distinguishing services-oriented architecture’s coarser grain and shared integration from microservices’ fine grain, deploy independence, and data ownership. SOA typically groups broader business capabilities behind shared buses or integration layers; microservices push toward small independently deployable units that own their data. The exam distinction is grain, deploy independence, and data ownership—not a vendor bus brand quiz.
Framing the comparison as monolith versus event-driven only ignores service grain and data ownership, which are central to the SOA-versus-microservices contrast. Comparing columnar versus time-series storage engines answers a database-layout question, not an application-architecture grain question. Comparing Webex API versus Meraki Dashboard API authentication models is an API security topic unrelated to SOA versus microservices structure.
Exam caveat: real estates often mix patterns—coarse SOA-like boundaries with a few fine-grained services—so pick based on independence needs, not buzzwords on a slide. Operational check: for each candidate service boundary, ask whether it can deploy, scale, and own its data without a lockstep release; if not, you still have shared-integration SOA (or a distributed monolith), not true microservices independence.