Microservices are great and powerful. Microservices always need not be business scenario specific. When building scalable, large platforms, it is important to build several infrastructure level microservices which can be used in building solution/business specific microservices.
what Is an Infra Microservice?
A microservice which may not directly handle the business use case but helps in rapid development of other functional microservices by handling generic things like user profiles management, Clickstream data pipeline, role-based access control, etc. Compare this with functional microservices that will handle business-specific use cases for example – Product rating microservice, Order delivery microservice.
This article discusses three key aspects which will have an impact on the adoption of microservices especially when those services are infrastructural in nature and also when developed as open-source for public good.
1. Infra Microservice Has to Be Architected to Be Independent Not Just Logical but Physical as Well.
Defining boundaries and making a microservice independent in terms of data and deployment is very important. Functional microservices can be made independent by defining boundaries along the business use case or functionality. However, making an infra microservice independent is more complex because it must integrate with functional microservice and when it integrates, the key question arises is - does it need to have its own data and deployment, or should it co-exist with data and deployment sharing?
Let’s take an example. Assume that an infra microservice is designed with its own keyspaces in Cassandra NoSQL database as its storage. Now, where should these keyspaces should reside?
Infra microservices are used by multiple functional microservices. Now, imagine a scenario if any of the functional microservices does DB heavy operations with unexpected load then the server utilization will go up which will in turn make the server unresponsive cascading the impact to other microservices. Isn’t this monolith behavior that defeats the purpose of the microservices architecture?
Note that the data may be separate in different keyspaces but the microservices sharing the same physical infra will create problems and cascading impact is multifold in case of functional microservices sharing data and deployment servers of infrastructure microservices.
2. The architect for Easier Setup by Considering End State and Usage
Several infra and functional microservices have to be integrated to build a business capability. Infra microservices will sit at the bottom-most layer of the deployment architecture hence they need to be setup first and then deployment process moves to outer layers. This is not as easy as I described even with tools like Kubernetes unless infra microservice architect makes a conscious effort to keep in mind the end state and usage of the infra microservice.
Microservices enable distributed computing by communicating over the internet through APIs. This model brings in additional complexity in terms of inbound and outbound ports setup, identifying dependencies, avoiding circular dependencies.
Many architects conveniently delegate this deployment complexity to DevOps teams but in my opinion that is not correct because architects must design infra microservices without ignoring the end state usage and easier deployment.
3. Build User Interfaces for Infra Microservices Wherever Applicable and Possible
These days the buzzword among architect’s community is an "API first approach." There is absolutely no question of this approach given many advanced experiences that are possible to be built when APIs are available. An API first approach is even more important when building infrastructure microservices. However, from the adoption and usability point of view, infra microservices architects must plan to build admin interface which will enable to use the service quickly after the setup is done.
Absence of such admin user interface will result in lot of work for adopters of the microservice to create input JSON formats, token preparations and firing multiple APIs using tools like Postman which is quite cumbersome.
Commenti