Services vs. containers
Naming things is hard. Describing things succinctly and consistently is equally hard. Often we try to pick a name that is self-describing and then assumes it describes itself when introducing the term to newcomers. For some the distinction between services and containers may be clear, but for others (and as a reminder for myself) I will describe them below.
The first thing to know is that these terms apply on two different levels of abstraction.
A service is a concept independent of the size, architecture, and implementation. Whether it is a microservice or monolith they are both are providing providing a service to clients actively (request-reply) or passively (push-based).
A container is a deployable and executable unit. How those containers are produced, where or how they are deployed or executed is an implementation detail. The promise of containers are size, isolation, and repeatability, among other things.
How are these terms related? A container may run a service in its entirety. Likewise a service could be made up of multiple containers that with some dependency between them.
However a container can also just run a program without exposing an interface whether it is HTTP or a CLI. So containers are not tied nor designed for deploying and running services. The corollary is that services can be designed, deployed, and served without containers!
Services and containers are often used interchangeably and although there is a significant usage of containers in service design and deployment, they are not the same thing.
