SOA, Micro services and Isolation Evolution
This is one of the most hot software architecture topics on the it industry right now. But how completely now new this is? I would say for maybe your surprise, not so much. Microservices are SOA. IF microservices are soa whats the difference in the end of the day, well i gonna try to explain it here in this post. Short Answer: Is all about isolation, is all about have independence. Hold ON: SOA was about that as well :-) Yes thats true, i`m not saying soa is invalid of something like that, SOA was more focused on some architecture principles and big architecture concerns but MSA(Microservices Architecture) focus more on operational capabilities.
Monolithic SOA
For SOA granularity was never a explicit matter, and thats fine actually. Services can have different sizes and responsibilities and thats 100% ok. Right, so whats is the real problem them? In the end of the day people end up doing BIG services, thats is a problem in operation point of view.
So what you might want todo is break some of your big components into small ones, this does not hurt the SOA definition of a service and does change much how you use things but it gives you more decoupling and decoupling is always great.
You are still doing soa and this sizes are not FIXED you could have smaller and buggers ones because it would really depends on your business needs. IF you go straight without thinking on the MSA thing you might have integration and data. latency issues not to mention federation so something could be bigger them other but the goal is to keep as small as possible.
In the way i see this SOA is bigger than micro services. You still have SO(Service Orientation - the main paradigm behind SOA) thats bigger than everything and micro services will focus on some granularity, isolation and operation capabilities. SO i see a perfect match between this two.
You might say i dont have this problems or I dont need this, right so tell me more about your release process, lets think about the following picture.
1. You dont have real independence - It means you are coupled
2. You dont understand what you are doing because you need threat everything as a single monolithic box - so it means you might have monolithic SOA.
On the second model, called (B) in my picture you can see different components with different schedules and different versions, this means you have independence and thats whats really what you want right? :-)
The Real Goal of SOA and MSA
Business Value. Thtas it. In other words FLEXIBILITY, it means have the ability to work with different teams, different components, different business goals at the same time and fast and as consistent as possible. So the SOA manifesto still valuable and you should still think about this.
People just started doing things and have different names but in the end of the day they are talking about SOA. Like APIS, the whole internet talk about APIs most of them are SOA just with a different names and different granularity and concerns but still SOA.
The service part of SOA, not the architecture: There is a huge gap into the it industry for REAL and RIGHT software design and leadership or SOA Governance if you prefer name this way. Thats one thing - the second thing is operations, IT has evolved after DevOps era and now things are starting to evolve on this side
Is hard to operate something is monolithic like twitter monorail. Micro service really try to fix this GAP.
The Magic around ISOLATION
Why? Because if isolate things they are easy to reuse, they are easy to restart,you can have explicit fallback mechanisms you have threads isolation and if something happens you have precision localized problem in this case is easier todo fail over, load balancing, fault tolerance and operations in the end of the day.
You might not realize but you might need have TEAM isolation. This is what would enable you todo Cross Functional Teams. Isolation. Isolation Otherwise you will fall into coordination nightmare of meetings, releases, noise, communication breakdown and etc...
So with Team isolation them you can threat services as black boxes and this makes way easier to pay technical debts and also improve things under the hood.
Lets say you can do that on the service side, but always you gonna have DATA, Legacy Systems, Applications and other components that you might not control so how you can archive this isolation? Lets think about this.
Remember you can replace database for legacy or 3rd system or app. It really does not matter - what matters here is say something like there an LAYER i can`t get rid of it NOW and might take sometime todo this - thats fine.
So what you need todo is isolate that changes into another layer, so this will give you flexibility to handle they with less coupling.
Thats could be archived with DataServices, they are simple system strangles or engineering bridges. They are wrappers that will protect you from the LAYER or legacy you need to deal with it.
This does not mean you gonna have to deal with the changes, you will have to, but them this changes will be isolated into the black boxes and this will avoid to deal with them outside of the micro service.
This is great because you move things to the application side - so most likely you have better tools to deal with changes and do refactoring, versioning , backward compatibility, them legacy systems and databases.
There are things you need improve to get this right
1. SOA Governance Leadership Design process
2. Operations: They will need to deal with will more vms
3. Tooling: Create. deploy, configure and manage all this services
4. Federation and Latency: So some services might not be the same size as others.
5. This really might bring DevOps as a way to archive some of this work.
Evolution not Revolution
Evolution takes time. So you might take some years to make this right, and thats totally fine as long as you dont stop the world and keep delivery. Thats a challenge i know but as more as you go into the right SOA and micro service path and have more isolation less painful it will be.
Cheers,
