Imagine taking an application, chopping it up into pieces, and running it as a collection of smaller parts instead of one monolithic whole. That's basically what a microservices architecture is. Each piece of the application is called a 'microservice,' and it performs one service only, runs independently of the other parts of the application, operates in its own environment, and stores its own data. Despite the name, microservices do not have to be small. What makes them 'micro' is that they only handle one service and are part of a larger application.
Think of an application constructed of microservices as being like an American football team, in which each player performs a distinct role, but the players together form a team (the whole application) that collectively accomplishes a goal. Or, think of microservices as the different systems in the human body (circulatory, respiratory, etc.), and the application as the entire body.
From the user's perspective, an application built with microservices has a single interface and should work just the same as an application designed as one stack. However, behind the scenes each microservice has its own database and runs separately from the rest of the application. In addition, microservices within the same application can be written in different languages and use different libraries.
Microservices are often contrasted against monolithic architecture. Monolithic architecture is the classic way of building an application. A monolithic application is a single stack, with the user interface on top, the business logic in the middle, and the database on the bottom. Usually a monolithic application is hosted on a specific server or set of servers. One of the downsides of constructing an application in this way is that any small change to the application means the entire stack has to be updated. Another downside is that if one part of the application breaks, the whole application might fail.
Microservices can be deployed in a variety of ways; they can be part of a serverless architecture, hosted in containers, developed using PaaS, or, theoretically, used to build a locally hosted application. However, the advantages of building an application out of microservices are perhaps most apparent when the application is hosted in the cloud, either using containers or in a serverless architecture.
Serverless microservices are deployed within a serverless vendor's infrastructure and only run when they are needed by the application. Depending on the size of a microservice, it may also be broken up into even smaller functions. To learn more about how serverless computing works, see What is Serverless Computing?
This distinction is still being defined by the tech community, but typically, a microservice is larger and can do more than a function. A function is a relatively small bit of code that performs only one action in response to an event. Depending on how developers have divided up an application, a microservice may be equivalent to a function (meaning it performs only one action), or it may be made up of multiple functions.
Extending the football metaphor, consider all the duties of a quarterback: throwing passes, handing the ball off to the running back, and so on. If the quarterback is like a microservice within the context of the team (providing the service of 'quarterbacking'), then each of these smaller activities is a function. However, the line between a microservice and a function can be blurred at times, just as there are certain players on a football team who perform one action only, like the kicker.