Software consultant. Bestselling Author. Loves rum, alt culture, games & metal.
Formerly Head of engineering, chief technical architect, head principal engineer, lead dev, etc.
Location
London, UK
Work
Independent Software Consultant at Electric Head Software
Microservices are part of an architectural style ( en.wikipedia.org/wiki/List_of_soft... ) derived from Service Oriented Architecture. So no, it's not misleading :)
"Layers" also implies a specific architectural style (n-tier, literally, the cake analogy).
There are plenty of valid critiques of microservice architectures, but "it's not an architecture!" isn't one of them. 🖤
Sorry, but I disagree. It's definitely not an architecture and not an architectural style either. And it's easy to prove - it's enough to make another packaging option and put all services into one application. With more or less decent design, which allows abstracting out communication method, it should not be a problem to replace communication via HTTP/REST with direct calls. And now you have monolith, but there are no changes in the architecture. Another direction: most modern recommend microservices best practice is to start as monolith and later split system as necessary into microservices. If architecture of the system remains the same, monolith or microservices have nothing to do with architecture. They are just packaging options.
Microservices are part of an architectural style ( en.wikipedia.org/wiki/List_of_soft... ) derived from Service Oriented Architecture. So no, it's not misleading :)
"Layers" also implies a specific architectural style (n-tier, literally, the cake analogy).
There are plenty of valid critiques of microservice architectures, but "it's not an architecture!" isn't one of them. 🖤
Sorry, but I disagree. It's definitely not an architecture and not an architectural style either. And it's easy to prove - it's enough to make another packaging option and put all services into one application. With more or less decent design, which allows abstracting out communication method, it should not be a problem to replace communication via HTTP/REST with direct calls. And now you have monolith, but there are no changes in the architecture. Another direction: most modern recommend microservices best practice is to start as monolith and later split system as necessary into microservices. If architecture of the system remains the same, monolith or microservices have nothing to do with architecture. They are just packaging options.
Then only monolithic is an option?
Or there is something more than that?
Of course there are other options: