There was a time when software were small, just a few MBs and also the resources, but we were anyway able to accomplish desired outcome on a single system running the application.
With time, everything grew, so did the data but it grew exponentially and our systems still coded as monolithic are finding hard to cope-up with this ever growing data. We try, all type of up-scaling horizontal and vertical both but still with time it becomes hard to support data.
Now we have plenty of resources, heavy software but most importantly, enormous amount of data, terabyte/petabyte of data. To support this data, we need to think dynamically, we need to change the way we expect our product to work and the way we code it. With microservice architecture, we need to think of service discovery and other stuff to manage but result can be promising. In this architecture we deploy small services, each supporting one independent function, having its own backend and SDLC.
This kind of applications do support different kind of responses, for example if you develop an application where one service is serving subscriber's basic data while other is serving his monthly bill and one service is serving his requests/pending issues. You can't simply join them and provide a search feature where you can search for subcriber with postpaid plans and living in one area while requesting plan changes in some duration. Reason is there is no single datastore where you make a simple join query.
Here we need to change business expectation and provide them offline reports with some submitted criteria. This is a change at business level however this also helps in improving performance and effective use of hardware by doing report generation in its free time and in backend as separate process without impacting main application.
This architecture also helps performance by each service providing data for specific need and not the data that is fetched in advance without being need or not. For example, if a user is searching something, he gets most of the data for its primary targeted data and other auxiliary services will just provide data that is on the page not the entire result.
This also is very efficient system to support for development teams however there is a little cost of managing lots of processes. But scope of any change is limited, its impact can be clearly identified, deliveries can be swift, zero downtime of the system because system consists of lot of services, while one is down for maintenance others are up and most of the system is still working.
I would suggest there are more of pros than cons.
For other areas and benefits of microservices, read my other blogs.
With time, everything grew, so did the data but it grew exponentially and our systems still coded as monolithic are finding hard to cope-up with this ever growing data. We try, all type of up-scaling horizontal and vertical both but still with time it becomes hard to support data.
Now we have plenty of resources, heavy software but most importantly, enormous amount of data, terabyte/petabyte of data. To support this data, we need to think dynamically, we need to change the way we expect our product to work and the way we code it. With microservice architecture, we need to think of service discovery and other stuff to manage but result can be promising. In this architecture we deploy small services, each supporting one independent function, having its own backend and SDLC.
This kind of applications do support different kind of responses, for example if you develop an application where one service is serving subscriber's basic data while other is serving his monthly bill and one service is serving his requests/pending issues. You can't simply join them and provide a search feature where you can search for subcriber with postpaid plans and living in one area while requesting plan changes in some duration. Reason is there is no single datastore where you make a simple join query.
Here we need to change business expectation and provide them offline reports with some submitted criteria. This is a change at business level however this also helps in improving performance and effective use of hardware by doing report generation in its free time and in backend as separate process without impacting main application.
This architecture also helps performance by each service providing data for specific need and not the data that is fetched in advance without being need or not. For example, if a user is searching something, he gets most of the data for its primary targeted data and other auxiliary services will just provide data that is on the page not the entire result.
This also is very efficient system to support for development teams however there is a little cost of managing lots of processes. But scope of any change is limited, its impact can be clearly identified, deliveries can be swift, zero downtime of the system because system consists of lot of services, while one is down for maintenance others are up and most of the system is still working.
I would suggest there are more of pros than cons.
For other areas and benefits of microservices, read my other blogs.
Comments
Post a Comment