There are many definitions out there, since there is no official standard for microservices. People often mention Service-Oriented Architecture (SOA) when they are trying to explain what microservices are.
SOA predates microservices, and its core principle is the idea that you organize applications into a discrete unit of functionality that can be accessed remotely and acted upon and updated independently.
- Wikipedia
Each unit in this preceding definition is a self-contained service, which implements one facet of a business, and provides its feature through some interface.
While SOA clearly states that services should be standalone processes, it does not enforce what protocols should be used for those processes to interact with each other, and stays quite vague about how you deploy and organize your application.
If you read the SOA Manifesto (http://www.soa-manifesto.org) that a handful of experts published on the web circa 2009, they don't even mention if the services interact via the network.
SOA services could communicate via Inter-Process Communication (IPC) using sockets on the same machine, through shared memory, through indirect message queues, or even with Remote Procedure Calls (RPC). The options are extensive, and at the end of the day, SOA can be everything and anything as long as you are not running all your application code into a single process.
However, it is common to say that microservices are one specialization of SOA, which have started to emerge over the last few years, because they fulfill some of the SOA goals which are to build apps with standalone components that interact with each other.
Now if we want to give a complete definition of what are microservices, the best way to do it is to first look at how most software are architectured.