Not a Service

This article includes my opinionated view on a topic where there clearly is no "correct" answer. Some of the statements are influenced by others, in particular Udi Dahan and Adam Ralph. The perspective of "what a service is not" is inspired by Adam Ralph's talk Finding your service boundaries.

We talk about microservices as the one architectural style every organization should strive toward in 2020. When talking about code and technology with different practitioners, you will hear the term service thrown around at numerous occasions. Every code repository I have seen has tenth of classes post-fixed with -service and every project has applications named something-service. Applications are also mentioned as being "microservices" in spoken language.  This overload of the term seems to be an under-communicated problem when talking about fine-grained autonomous systems. This, together with the lack of an agreed upon definition, is why I suggest limiting the use of these terms or at least be very deliberate about it.

The closest we can get to a precise definition of a service (by Udi Dahan):

A service is the technical authority for a specific business capability

This is fairly accurate, but still hard to grasp - defining a business capability leads to the same problem of interpretation again. People have strong opinions about what a service is, so instead we will try to define what a service definitely is not.

Class

Service is probably the most used name for a class in any project, everything that has no logical name is a service. These classes often exists for no good reason, they usually only serve to fulfill some concept of layering. If there is no better possible name than something-service, I will do my best to remove it, or at least never use the name service.

Function

"Calculation service" is probably the most common, some kind of rule set exposed trough an API is suddenly a service. A function is only a function, no matter what interface is placed in front. Accessing a function over HTTP is not very efficient and should only be done if the function requires some context specific data or configuration that cannot be packaged in a library.

A service can provide a library for calculations to be used in a externally available API or directly in a website. There is no inherent need to deploy it separately behind a HTTP endpoint.

Database

The same argument is appropriate for databases - exposing it over HTTP does not make it more than a database. This is normally done to avoid database integrations, which makes sense in case of classic relational database with a  schema. NoSQL databases often provides proper APIs out-of-the-box, in which adding another layer does not solve anything. In any case, a database is still just a database.

User Interfaces

An app or web site is not a service on its own, but is always part of - or an aggregate of interfaces from - a service. There is no such thing as a mobile service or frond-end service (in context of architecture strictly speaking). The same goes for APIs - gateways or back-end-for-frontends are not services.

Wrap up

This might seem like a unnecessary rant about a non-existing problem. To some agree that is correct. The point of the post is to highlight trend of using terms carelessly, which is a natural part of a young science. IT is not a well defined craftsmanship, even if we would like it to be, thus the need for caution when introducing new terms and vocabulary.