Common Microservice Design Challenges

This section continues by covering the following set of common impacts and challenges that need to be understood in advance of an exploration of microservice technology architecture:

-distributed system complexity.

-increased operational overhead increased communication and network traffic requirements.

-increased synchronization requirements.

-disparate APIs and non-standardization.

the extent to which these challenges can negatively impact a project or solution depends on the extent to which microservices are utilized and the extent of their functional granularity,  if coarser grained microservices are peripherally used as a part of a greater solution the impacts will likely be minimal if a solution is compromised of fine-grained microservice entirely the impacts will likely be front and center.

let’s take a look at distributed systems complexity an application architecture based on a collection of fine-grained microservices can introduce a series of complexities that come naturally with the fact that the architecture is based on a large quantity of independent moving parts, for example:

-communication latency between different components and microservices. increased dependency on fault tolerance.

-increased failures due to unreliable networks.

-increased complexity of asynchronous communication.

-complex version control and versioning.

-load balancing across the environment and multiple instances of the same microservices without having a clustered deployment.

performance, and reliability issues can be addressed by improving the underlying infrastructure, however, the underlying infrastructure itself can be subjected to increase complexity the figure illustrates this by providing a glimpse of a microservices-based automation solution we can see a solution comprised of a series of fine-grained microservices each with It’s underlying implementation environment let’s take a look at: increased operational overhead, in a landscape where microservices are used the amount of services in an enterprise, when using microservices may increase significantly each microservice needs to be managed and operated independently more importantly, each microservice may have its own lifecycle and change, and release management requirements. along with specific testing requirements prior to deployment and subsequent updates traditionally applications are designed to access shared underlying resources namely databases. However, it’s common for each microservice to have its service state database and database state the autonomy and consistency of this data is important which is why the databases are commonly not shared between microservices note the dashed borders around the microservices here these represent the isolation layers that we design for microservice implementations much of these courses explore the architecture behind this isolation layers the illustration shown here revisits the diagram from the previous subsection and shows the respective microservice implementations with defined isolation layers we can see how each microservice is physically isolated from the others one topic covered throughout this course and module number 10 is containers and containerization as we will discover containers play a significant role in improving the deployment and management in relation to isolation boundaries. However, the introduction of an increased number of containers can end up actually contributing to the overall operational complexity as containers and container engines need to be managed as additional individual i.t resources we’ll now review increased communication and network traffic requirements the functional scope of a given microservice is typically small this narrow focus is deliberately to enable the microservices’ performance, and reliability requirements within its isolated boundary however, the decomposition of processing logic into fine-grained microservices can elevate the need for cross-service communication and associated network traffic the next topic is increased synchronization requirements it is common for each microservice to establish its own isolation boundary in which it keeps implementations of one or more databases anyone such database may be a replicated copy of a shared database used by other parts of it enterprise, and other microservices furthermore microservices-based solutions are more likely to use asynchronous communication for messaging event notifications and parallelism to deliver runtime functionality when an automated task is carried out it must often be ensured that all microservice instances are in sync this means that although, microservice instances can process their respective logic independently of each other the datasets may need to remain constantly synchronized this can lead to the requirement to employ sophisticated synchronization technology or models such as eventual consistency an established data consistency model that guarantees that data will remain consistent across nodes within a distributed system that has a copy of the same data here we see the microservice architecture highlighting the existing state database instances that need to be kept synchronized during the runtime processing of the solution business logic let’s take a look at disparate apis and non-standardization the fact that microservices are commonly delivered rapidly following agile and devops practices can increase the risk of non-standard apis making their way into a given environment this is especially the case when the microservices are delivered by different project teams at different times and without any overarching standards or governance framework in place this subsequently can lead to an integration-centric architecture reliant on transformation technologies to overcome api disparity this can further lead to negative forms of coupling if microservice developers choose to bypass service apis to access external underlying resources directly here we see a variation of the previously shown architecture whereby a series of non-standardized microservices interact in a manner resembling traditional integration architectures.

Add Comment