In the last few years, a trendy new term has come up: “microservice” and a microservice architecture. I have been building software for a long time, and have used a service-oriented-architecture (SOA) and component-oriented-architecture (COA) for many of the applications / systems my teams have built. Sometimes an industry is missing a shared term for things people have done for decades. The microservice term was new to me, so after having some discussions with people from ThoughtWorks and other companies, I wanted to get a more definitive definition.

So far, this article seems a good intro: Microservices by Lewis and Fowler

If you read through the core issues that a microservice architecture is trying to address, they seem to distill to this:

• Have an architecture where you produce working ‘product’ continuously
• Your ‘product’ will be deployed and you need to be responsible for that being successful
• Don’t make the architectural components too big for a team to understand and successfully build and maintain

These seem very practical and straightforward architectural guidelines. In both startups and enterprises, you are delivering products that the company needs or sells, so you should always have your focus be on achieving that.
I agree that some teams seem to lose this, so keeping them reminded is a good idea.

Good Idea, Horrible Name

Given the above reasonableness of the concept, this would be a good thing to have a good name for. Maybe something like:

• Service-Component Architecture
• Business-Service Architecture
• Right-Sized Service Architecture
• Deployed Service Architecture
• Composed-Service Architecture

All of the above pull at least some interesting aspect of the solution or problem into the term.

Unfortunately using ‘micro’ with service doesn’t do anything other than imply ‘small’ or ‘very-small’. A ‘microscopic’ entity is too small to see. A ‘microprocessor’ is a processor that is powerful in abilities but physically small.
I am not sure what word containing ‘micro’ that in any way implies what the ‘micro’ of ‘microservice’ is trying to imply.

Bad names lead to bad architecture

You might think this pedantic, but words are powerful. And the first uses of microservice in the wild I heard were for services so tiny in functionality that if you scaled to build a system out of them, you would have a nightmare of managing components. It is fine to do something small as a test run, but services need to be cohesive and as comprehensive as possible to avoid spiralling out of control with dozens of service components wired together haphazardly.

Trendy/Transitional vs. Foundational

My guess is microservice is somewhat trendy and will die because it is a poor term. A more appropriate word is again ‘service’ or ‘service component’ or ‘right-sized’. You want an architecture that has a reasonable number of services organized/composed in a reasonably understandable way. One way you might organize things is by business function, another is by core infrastructure capability (e.g. caching), another is by ‘rate-of-change’, and another is by ‘risk-of-change’.

Monoliths are incredibly easy to understand, so they are actually a good starting point. Your goal is to deliver a valuable product, so “start with” doing that.

As long as you are good at splitting monoliths (dealing with inter-service calls vs. in-memory calls, providing a facade that hides the change, etc.), and leverage third-party service-components when suitable, you should have a pretty effective architecture. You can split early (before production) or later, but keep you eye on delivering valuable product to your company.

Basically review ‘Design Patterns’ and think at the service-component level.