Microservice Architecture according to me
Microservice is a buzzword in the current software engineering world. Everyone wants to say that they are building microservices or eagerly want to adopt it.
Reasons for Microservices
Microservice – Bring Agile to Architecture
As per the definition, it is an architectural style, where system is divided to small autonomous processes which are coupled with programming language/platform independent API. However, there is a similar kind of architecture in SOA (Service Oriented Architecture) which were also communicating kind of stable independent APIs. But what is the main difference or advantage?
Frequent releases
Yes the ability to release more frequently is the key. We cannot deny other advantages that system is clean with small services which knows how to do its duty well, system can easily be built with different programming languages, scale only required components/services instead of whole system.
When agile was introduced, lots of corresponding advantages were also advertised. Working code over documentation, customer collaboration, responding to change were some of the advantages that were bandied about to mention a few. But what is the real key? The key was 2-3 weeks based sprints which delivers something concrete. Most service companies adopt agile only because there will be a release in 2-3 weeks and developers will have to work through nights and sacrifice their weekendssecond week. In the waterfall model through the grunt work would be maybe once in six months.
At most work place, besides the the concept of sprint, the rest such as maintaining backlogs, avoiding documentation over code were not implemented. There are no release that is not accompanied by documentation attesting that that code is working.
What is present in Microservice? Independent teams who take ownership of small services. The size of the service relates to the size of the team who delivers it daily, once or twice a day or hourly.
At most places, there is an emphasis on TDD when adopting Microservice but this might be discarded in the rush to release.
Bottom line? The architecture will be agile. A Microservice could be introduced at any time in the development phase. Servers are going to be flooded with services. The complexity of the system is going to be part of orchestration of Microservices.
Design Microservice
As the software engineering is still evolving, only fittest will survive. Currently, Microservice seems to be the fittest one. This means Microservices architecture could become an everyday reality and most of our apps might be Microservice-based.
Characteristics of Microservices
Here lets see what the characteristics of Microservices are.
Independent release
If a service can be released independently of the other parts of the system, it can be considered as Microservice. Sometimes the new API methods we released in the Microservice might not have any consumer components as the consumers part can release only after the service release.
The concept of independence is really important, if we want to release too often. If it depend on other components then we would not be able to release fast and often.
Independent data store
If we want to have independent release of a service, then its data store should be independent. If there is a database table and a component release upgrade the schema causing other components to fail, we cannot consider that component as a Microservice. In short, Microservice should be the only one to own its data store. If other components in the system want to write something to the store they should call service.
Independent development team
If we want independence, probably it should be done by independent team. This has nothing to do with technology. An organization structure may need refactoring and it is tough.
The speed of delivery is prone to errors as well and it is advised to have development team supporting the service. If the team is shuffled after each release or members change often, they will not support service with ownership and the micro service architecture might be a potential failure.
Independent framework/platform/language
Although not mandatory, there is a pressing need to adopt a particular technology which is different from regular technology stack. Microservice is recommended provided it meets above 3 criterias. Even if we can have Microservice based systems with one language and technology, do not jump into Microservice without proper assessment and planning. Know following before jumping into Microservice world.
Defined integration guidelines between components. http(s)
If you don’t have defined integration strategy of Microservices, it will fail. The recommended integration if it is through http(s) protocol and has synchronous interaction. In case of asynchronous integration, adopt message queuing, service bus, etc. There should be enough design sessions and agreements before adoption.
Upfront design on the API
The real world systems/business problems are always complex. In monolithic system, we were handling the complexity in big components. But in Microservice era, the individual components are simple, but the interaction of services is complex.
This requires carefully designed APIs for each Microservice. API is like Mumbai underworld. Once we enter it, there is no coming back. Once we publish an API, we don’t know who all will be calling it. Correcting the API and communicating the same to all consumers to redirect to new API is a costly affair.
Deployment is easy and automated.
One major advantage of Microservice is its frequent releases. If installation is done manually every time, then Microservice is a bad idea.
Deployment should always be automated. A continuous integration and delivery pipeline is essential.
Strong automation testing. Prefer 100% test coverage
A 100% test coverage is preferable then no human is required for day to day deployment. They just setup the CI & CD in the beginning and system will do deployment automatically.
What about testing? Are we expecting a manual tester to test all the changes before we release daily? That again should be automated. Developers should write proper test cases for the API. Most companies employa separate team/person dedicated for testing, on the assumption that a developer doesn’t want to break his own code or psychologically they cannot find out errors in the system that they build. When a developer test, they test only positive or usual scenarios because he knows how the system works. But here in the Microservice world, there wont be separate manual testing team. So, how to tackle it?
Some of the developers need to write the tests. If the existing testing team knows how to code API tests, and integration tests. Please note we are against manual click QA and want to stick to Automation QA.
Service monitoring & management
With explosion of services, there are chances that each class/component in your existing system such as logging, caching could become a service. Some services will be versioned services, some will be cumulative/in place update. We need to add more service instances and load balance when services show load. Some might not be even used. A machine which hosted a service might go down and we need to relocate the service with zero or minimal downtime. How do we deal with all these scenarios?
The answer is a strong service monitoring and management infrastructure. Easy way is to host in cloud, where this is free with cloud provider. We don’t need to develop infra management application for increasing number of machine and deploying the service to it. Or to move service from one machine to another machine, etc.
Versioning, dependency management, retirement strategy
Version 2 of Service A may require Version 4 of Service B to be present in the system where Version 1 of Service C require Version 3 of Service B. This means Version 3 of Service B cannot be retired until Service C is retired.
Why we need to retire a service. Over time, some services will be legacy and there will be nobody calling it. But it just stays in the production environment. It is the decision of the stakeholders to retire such service. If we plan to retire such services, then users should be notified so no new service call the retired ones.
Another interesting scenario is whether the service, say service X, should know the location of another service Y? Though the location has many things to consider, here let’s take the url of service. If we decide to keep the location of Y in X, we cannot move Service Y to other machine or environment. Hard coded location will cause trouble. Suppose we started with all the on premise services and due to load, we decide to move Service Y to cloud Service X, it will fail to call Y.
This is because we need a service registry which keeps track of all the services and their dependency. This can be another service but in a fixed location.
If you have access to production
If the development is for a product your company owns and is server based, Micro services works great. If the product is delivered as an installer to your clients, it would be really difficult to manage, as they may be still installing the morning release when you give evening release.
So choose, if the CI & CD pipeline can reach till production. We can refactor the other systems to Microservice based but will never get the advantage of frequent release.
Disclaimer: I work in a project which have 100+ services, though we have officially not adopted the Microservices architecture. It came along with this architecture and many services share same data store. We don’t independently release services due to data coupling. So, the above view is based on theory and watching the pain points of service management.
This article has been re-published from author’s personal blog. For reference, click here.
