Jump to content

Service granularity principle

From Wikipedia, the free encyclopedia

In software engineering and software architecture, service granularity is a design concern in service-based systems, including service-oriented architecture (SOA) and microservices architectures. It refers to the scope and cohesion of functionality encapsulated by a service and the boundaries of its responsibilities. Service granularity affects how services are defined, how they communicate, and how functionality is distributed across a system. In SOA, it is often addressed during service-oriented modeling to balance reuse and abstraction. In microservices architectures, granularity is a primary factor in determining independent deployability, operational overhead, and the complexity of inter-service communication.[1][2]

Definition

[edit]

Service granularity is both an application domain concern (business granularity), as well as a software interface design issue (technical granularity); it is a property of the service contract exposed by a service provider. It pertains to the semantics and syntax of the in (request) and out (response) message content, which can be viewed as instances of two general Enterprise Integration Patterns, Command Message and Document Message. By definition a coarse-grained service operation has broader scope than a fine-grained service, although the terms are relative. The former typically requires increased design complexity but can reduce the number of calls required to complete a task.[3]

Criteria

[edit]

Due to the fallacies of distributed computing, finding an adequate granularity is hard.[4] There is no single simple answer but a number of criteria exist (see below). A primary goal of service modeling and granularity design is to achieve loose coupling and modularity, which are two of the essential SOA principles,[5] and to address other architecturally significant requirements.

Many forces influence the service granularity;[6] four particularly relevant factors to consider when designing for an adequate granularity are performance, message size, transactionality and business function:

Business function

[edit]

Ideally, each service operation maps to a single business function, although if a single operation can provide multiple functions without adding design complexity or increasing message sizes, this generality can reduce implementation and usage costs.

Performance

[edit]

Web services are accessed remotely and calls to web service operation create more network overhead. Reducing the number of service requests reduces that overhead.

Message size

[edit]

Coarse-grained services may pass more data than fine-grained services, including data that is not specifically required for the task. This complicates message processing in the endpoint and might in turn harm performance. Reducing message size may require adding a more fine-grained operation.

Quality-of-service characteristics including transactionality

[edit]

For conceptual clarity each service operation should perform a single system-level transaction and leave data integrity across service boundaries to the business logic in the service consumer. This also simplifies error recovery, and typically eases design.

Many more decision criteria for finding an appropriate granularity exist; there is no global optimum. Sixteen such coupling criteria are compiled from the literature in.[7]

Patterns

[edit]

As one size does not fit all, the design of service granularities can benefit from many existing pattern works on various kinds of distributed systems, especially those related to services, as well as pattern works related to API design (e.g., API design in object-oriented programming) and enterprise integration. An overview of such languages is given here.

Service granularity in microservices architecture

[edit]

In microservices architectures, service granularity influences testing, deployment, performance, and reliability. Very fine-grained microservices are typically easier to test and deploy independently, but they often experience lower performance and reduced overall reliability due to increased interservice communication and more complex service choreography.[2] Coarse-grained services exhibit contrasting characteristics. They generally provide higher robustness and reliability by minimizing communication overhead and coordination complexity, but they are more challenging to test and deploy because modifications affect a broader functional scope.[2] The appropriate level of service granularity is determined by business drivers. Architectural decisions commonly begin with identifying these drivers and then aligning architectural characteristics such as performance, scalability, reliability, or deployment flexibility to support them.[2]

References

[edit]
  1. ^ Erl, Thomas. SOA Principles of Service Design. ISBN 9780132715836.
  2. ^ a b c d Richards, Mark. Microservices AntiPatterns and Pitfalls. O'Reilly.
  3. ^ Josuttis, N. (2007). SOA in Practice. Sebastopol, CA, USA: O'Reilly. ISBN 978-0-596-52955-0.
  4. ^ F. Leymann Loose Coupling and Architectural Implications, ESOCC 2016 keynote
  5. ^ Krafzig, D., Banke, K., Slama, D. (2004). Enterprise SOA: Service-Oriented Architecture Best Practices 1st Edition. Prentics Hall. ISBN 978-0131465756.
  6. ^ Page 21 in Zimmermann, O., Guidance Models and Decision-Making Tooling for SOA, Cloud, and Outsourcing Solution Design, http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf
  7. ^ Service Cutter: A Systematic Approach to Service Decomposition, M Gysel, L Kölbener, et al.. European Conference on Service-Oriented and Cloud Computing, 185-200, (PDF)
[edit]