SOA Service Anatomy

Working as a consultant many times i raise the bar of the role architecture in great software. As solution engineers we often talk about software architecture. When we are working with SOA / MSA (Microservices architecture) we need realize that there is more than one architecture.

You could and most likely will have a middleware or container or bus or platform you do your business work but each *thing* needs to have its own architecture.

For SOA/MSA the citizen of first class are Services, so basically you work with Services and you just "see" services, in the end of the day what matters is raise the level of abstraction and leverage from that in business perspective.

Service Oriented Enterprise - SOE

SOA/MSA is not meant for a single system. The idea is that you will have your whole IT around services but not everything should be a service and thats is a design decision. I like to think about 2 metaphors todo this, 1 is a city map, 2 is a classification game.

So for the city map - you have all sorts of things into a city, hospitals, fireman, police department, marketplaces, tubes, cabs, roads, parks, etc... each of this things is a thing. So could be that every building is a service but you might have more than just buildings then you might have more than just services.

When we do SOA we should have a MAP and we should know what are the services and what they do and what they dont do.

We also should have SLA around the services, today we have plenty of tools to archive monitoring and control this SLAs.

This is important because is part of the service design, if you dont see the big picture you might make wrong decisions like put a Prison close to a primary school, very bad idea, this is the same as exposing a internal service directly to the web or coupling UI with a service database. All very bad ideas but often could happen - so a Map is very important part of your design.

Classification - What is a service what is not?

For me makes sense do a consumer driven SOA/MSA, so you need understand what are you consumer, what they need - so you can reuse by design - not by accident.  A very simple approach is move code to a service based on multiple consumers but be careful sometimes this could be wrong.

There is no standard classification schema but you can create your own, so what could be the options:
  - External Service - API
  - Internal Service
  - Internal API
  - DataService
  - UI APP
  - Mobile App
  - Legacy Application
  - Grammar / DSL
  - Integration Connector
  - Driver
And so on and on. The reason you might do that is because something does not fit when the notion of a service and it principles like mobile/ui app. Other times you make differentiation between service like internal vs external because than you can have different rules in sense of governance.

What is the Service Anatomy?

This is the service internal Architecture. Yes, every single service will have they own architecture and they could be very different. Some could be Request Driven most of times they are like that, other could be Batch or Analytic(Map reduce, etc...) and so on and on.  This pretty much breaks the idea that every service is the same thing often they are not.

Going deep on the microservice thing you might break you functionality per domain or per groups of users, this is awesome for operations and maintenance.  Microservices does not mean you need have less then 200 lines of code per service :-)

How to start things right?

Unfortunately everybody starts SOA wrong - by buying tools. You should first learn about software architecture, Service Orientation paradigm and them start doing proper SOE, how? Go do a map of your IT then you can start defining some rules per services.