In many ways, individual microservices can be considered "mini-monoliths" with respect to their specific functionality domain. Essentially, microservices architectures are SOA at a lower level of granularity regarding the responsibility of each component. They follow similar design principles as monolithic applications, just with a narrower scope.
You can think of it this way: A traditional monolith is like a big department store where everything happens under one roof. A microservice architecture breaks this down into a shopping mall with specialised shops. Each shop (microservice) still has its own staff, inventory system, and checkout counter (the 3 layers) - just focused on one type of product. The key difference is in how they connect and operate:
Independence: Each microservice runs and deploys on its own schedule
Focus: Each handles just one business capability
Technology freedom: Each can use whatever tech stack works best for its purpose
Data ownership: Each typically manages its own data
You should bear in mind that software architecture concepts are abstractions to facilitate design and understanding. When you implement an architecture pattern, depending on the system at hand, this same implementation may be identical to another architecture pattern, but conceptually different.
Don't fret too much about names, most of the time they are marketing strategies (from companies and academia professors) trying to make their solution be recognised as the industry staple.
Here's some references on the subject:
https://www.ibm.com/think/topics/three-tier-architecture
https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith
https://www.springfuse.com/microservice-vs-layered-architecture-comparison/
https://xbsoftware.com/blog/monolith-vs-microservices-vs-distributed-monolith/