Source: www.torocloud.com
When and When Not to Use MicroservicesCategory: Database, Security, Data, Kubernetes, Docker, RabbitMQ, android
But, as these organizations grew, they began to realize that using monoliths would no longer be viable for their operational needs. Thus, they turned to microservices, taking advantage of how this modern architecture can scale with rapid growth, constantly changing consumer demands, and unpredictable business environments.
For example, if the code is developed using .NET code in the form of a web API and the state is stored in an external in Azure SQL database, say, then the configuration that you write or the scripts for that matter for upgrading and scaling these services will have to handle, compute storage and network capabilities on both of these platforms simultaneously.This is not so much of a big problem to solve now because modern microservices platforms such as Kubernetes offer a possible solution by co-locating state and code together for the ease of management, which simplifies this problem to a great extent, also with the help of Kubernetes operators, for example, AWS service operator and Azure also has a counterpart, which is for Azure service operator, you can deploy the state to a past service.
If you form guilds like these, then what would happen is that in any requests that needs to be satisfied, for example, if you need to add a new front end to your application, and it requires some middleware processing and then some data to be solved through the database, and you need to go through all of these three teams. And the communication is generally very slow.And in such organizations where teams are structured like this, it is very hard to realize the concept of microservices because microservices and domain-driven design actually go hand in hand when you need to structure your teams that have each of the capability that you require.So, some members who specialize in user interface, some who specialize in building the middleware, for example, where VPIs or any of the processing system that you require in between, and then the database and you put them together so that whenever you have requirements, there is no gap in communication between these team members.
For example, if the code is developed using .NET code in the form of a web API and the state is stored in an external in Azure SQL database, say, then the configuration that you write or the scripts for that matter for upgrading and scaling these services will have to handle, compute storage and network capabilities on both of these platforms simultaneously.This is not so much of a big problem to solve now because modern microservices platforms such as Kubernetes offer a possible solution by co-locating state and code together for the ease of management, which simplifies this problem to a great extent, also with the help of Kubernetes operators, for example, AWS service operator and Azure also has a counterpart, which is for Azure service operator, you can deploy the state to a past service.
If you form guilds like these, then what would happen is that in any requests that needs to be satisfied, for example, if you need to add a new front end to your application, and it requires some middleware processing and then some data to be solved through the database, and you need to go through all of these three teams. And the communication is generally very slow.And in such organizations where teams are structured like this, it is very hard to realize the concept of microservices because microservices and domain-driven design actually go hand in hand when you need to structure your teams that have each of the capability that you require.So, some members who specialize in user interface, some who specialize in building the middleware, for example, where VPIs or any of the processing system that you require in between, and then the database and you put them together so that whenever you have requirements, there is no gap in communication between these team members.
Related Articles
Community Partners
DevOps Careers