A hot topic these days is how distributed services architectures like Microservices are better than old fashioned Monolithic architectures. In parallel, there’s another dilemma in architecture and design world that puts us in an illusion of being in an environment of Distributed Services despite carrying the same legacy of Monolithic principles (also termed as Service-enabled architecture).
Most of the systems attempt to divert from monolithic to Service Oriented Architecture but suffer the same syndrome where hundreds of bulky services are developed in a wrong way, which brings the whole system to a level where it reaches at the edge and everything ahead becomes empty space and a river to drown in. In today’s article I would like to discuss the impacts of such bad decisions and one of the possible solutions that’s gaining momentum these days – Microservices.
Made with Services
Generally when we try to solve a problem by dividing pieces of the problem into services, the division criteria is very critical. With lots of experiences in monolithic architectures we tend to make the same mistake and start creating fat services. Such services take a set of inputs and does plenty of heavy operations through databases or other services, perform heavy calculations, parses documents, executes complex algorithms and then return the output. This tendency creates a bunch of problems that are pretty hard to be rectified at later stages. Some of these are mentioned below.
Lack of re-usability and duplication of code
When your services are bulky, it means they are doing several operations in them. Say your services does several operations and one of these operations is ‘addition of two numbers’. Now suppose another service wants to have this functionality of ‘addition of two numbers’ what options do we have on table? no options, so we duplicate the code everywhere, which creates a bunch of critical issues that are so obvious that I’m not going to touch upon them.
Technology coupling
Its not a difficult thing to convince that one type of things are good in one technology and another type of things are better in the other ones. If you want a very optimized algorithm with best performance C++ might be your first choice but if you want an elegant solution having complex communication needs you might adopt .NET’s WCF. Bad services model marries you with a technology and its hard for you to break up with it and move onto the other, I have seen scenarios where we did ugly fixes to do things because we are married to it.
Scalability restrictions
Such services are not scalable. Not as a whole and not partly. The only way to scale them is having multiple instances, which has inherent issues, especially deployment and resource drainage like WMI high CPU, Excessive paging, I/O etc. The other way is fixing and tweaking minor changes which has a lemon squeezing effect – You can squeeze a lemon to get more juice but after a few attempts you can’t squeeze it more.
Dilemma of Over-Engineering
When nothing works in such systems, we start thinking to redo, while staying in same paradigm. Then what we do is we Over-Engineer, we build a jet engine to move from one room to another. Such over-engineered systems never use more than 15-20% scenarios but increase the readability and troubleshooting hassles.
‘House of cards’ deployment paradigm
Since to scale such Fat services we start creating multiple instances, we end up with dozens of instances per such service, which increases the headache of deployments. You make a small change and then deploy and then test at a dozen places which makes its maintenance a nightmare.
Microservices
Microservices paradigm promises to help in this area by suggesting to have tiny services doing a unit of work while having certain traits. This area is getting huge traction mostly because technology giants like AWSand Microsoft are putting a lot of effort in this area.
Here are some of the major characteristics that I explored, that can help resolve above issues.
- Has a unique name to be identified and to be located
- Can be developed in any technology, framework or language without hampering any of the system’s ability to stay functional.
- Allows the code to be independently versioned, deployed and scaled up or down.
- Interacts with other Microservices through a well defined protocol
- Highly available and self healing
- Low cost and effective monitoring and reporting of health and diagnostics
- They do single unit of task, thus increasing the usability of the system
While Microservices offer huge promises, its management becomes difficult on a bigger scale. Such a diverse system of systems can easily go out of hands if not managed in a proper way. Proper protocols and standards need to be defined within the organization to shift to Microservices and here’s where Microsoft’s Service Fabric comes in handy. In my next article I will discuss a little bit more about setting up Microsoft’s Service Fabric in a step by step approach.
I’m not shy of tasty food and valuable comments. Feel free to bring any of these, anytime!
Article Board 