Micro-services Architecture Issues -[Design, Communication, Data Management, Development, Deployment, HR]

Most of the software products start off with monolithic architectures, yet upon success and with more additions to the same architecture, transforms into a Monolithic Hell (a term coined by Chris Richardson).

Once you are in monolithic hell, the initial advantages of monolithic architecture - where you get to swiftly develop, test, deploy, and scale your application — are gone now. Also, in the beginning, where your processes were agile, and you had small autonomous teams and were utilizing continuous delivery and testing, are also gone now. This is where the concept of functional decomposition and rebuilding your app using microservices architecture pops up.

Why Microservices?

Microservices architecture does offer the benefits of the process and organizational improvements. With this architecture, you can deliver continuously, be agile, and support small autonomous teams. It enables continuous delivery. Services are small and easily maintained and can scale independently.

Is this architecture the silver bullet? Not as such, there are drawbacks and issues that need to be addressed to make such an architecture work.

Let’s look into those issues.

Design

The design of service boundaries is an issue. How do you slice your application? Is it going to be a functional division or business domain driven? Are all the services really decoupled from the rest?

With this architecture, you are in essence moving towards a distributed system. Developing, deploying and maintaining such an architecture is fairly complex. From processes to organizational capability, all need to be changed and made ready for the new culture of development.

Also, the decision of when to transition to this architecture isn’t easy. Working with distributed architecture will definitely slow down your development. And this could be tricky for the startups who are experiencing growth and change. But if you let your application grow bigger and bigger and then the change would involve a lot of complexity.

Communication

Interprocess communication becomes an important issue with distributed architecture. You need to decide and design as to how the services will talk to one another or to the external world.

So, you need to look into an issue like the kind of IPC mechanism to use; ways to handle service discovery; reliability of communication once a service is unavailable; and ways to talk to 3rd party services.

Data Management

Since each service in this architecture has its own database, data consistency across the application becomes a huge issue. Data management patterns need to be completely revised. So, handling transactions become a pain.

With this architecture, you are moving away from a shared database to a “Database per Service” architecture. You are implementing a system where transitions are distributed across multiple databases. That requires a complete overhaul of communication structures and handling failures.

With a shared database, you had the benefits of enjoying the ACID as you using a tightly coupled architecture. With microservices, you will be working with Event Sourcing. This will require application rewriting and a style of programming that is unfamiliar.

Development and Deployment

From the organisational point of view, you are managing teams that are developing and deploying features that span multiple features. This results in the complexity of testing, deploying, and operating such a distributed system. Coordination and communication within a team can also hinder the process.

For developers, implementing a use case that spans across multiple services, becomes a challenge. Similarly for the deployment team, deploying features across multiple services require coordination and roll-out plans that are much different from what they are used to.

Also, services are written in multiple languages and frameworks and will also require multiple services instances for throughput and availability. This makes development and deployment a major challenge to tackle.

HR

One cannot ignore the human side of the transition. Letting go of known and working patterns and does involve emotional upheaval and resistance. You effectively need to transition your team from old practices to a stage where there is acceptance of the new ways of operating. Your final destination should be at a stage of embracing the new culture and reaping the benefits of all the hard work.

You might need consultants who can help you with such phases and transition teams to new development and deployment culture.

Summing Up

With the above issues, still, microservices architecture offers benefits that outweigh the drawbacks. This is especially true for large and complex applications.

But remember microservices is a complex system to build, test, and run. Such architectures need to be done well, to offer simplicity for further development and operations of a complex system.

Thank you for reading! If you find this helpful go ahead and give it a few👏 so that others can find it.

Part of App2Dev.com Publication