I think the biggest pain point for me is the almost constantly-changing definition of "microservices" - at work, whenever someone says "microservices" they really mean a services architecture. I can largely get behind that. Because when you say services architecture, to me anyway, that doesn't mean everything has to be a "service". Some stuff can be on the same machine if you do not have a firm point of separation between the services. Maybe they will share some code eventually... ok... put them together, who cares?
Last time I asked our ops guy to define microservices for me, he couldn't - instead he told me to read a 400 page book by some popular microservices preacher (who of course makes a lot of money by consulting for companies looking to use or currently using microservices ;))
If you cannot explain the general concepts to me, maybe you do not know what it is, and I think that is a big part of the problem.
Yeah, I think the most palatable definition of microservices is just SOA with no arbitrary lower bound on how much code a service needs to justify itself.
SOA usually involves a bunch of separate services, but all connecting back to the same shared RDBMS. That's the biggest shift in microservices - no shared data stores.
It's SOA with specific patterns and disciplines, centered primarily around the concept of the 'bounded context'. But if you want to just start with SOA and learn those patterns as you go, or dig into the book/ blog posts on bounded contexts, go for it.
Last time I asked our ops guy to define microservices for me, he couldn't - instead he told me to read a 400 page book by some popular microservices preacher (who of course makes a lot of money by consulting for companies looking to use or currently using microservices ;))
If you cannot explain the general concepts to me, maybe you do not know what it is, and I think that is a big part of the problem.