buchachon - Fotolia
5 big microservices pitfalls to avoid during migration
Too many development teams make these failure-inducing mistakes during a switch to microservices. Learn where things go wrong, and the best ways to avoid problems.
Microservices architecture has revolutionized application development. Developers have more control over their applications, simultaneously create and update services faster, and make targeted changes without worrying about the effect on application performance.
But while all these advantages are appealing, too many software teams make mistakes in the migration to microservices that lead to a nightmare of heavy costs, overloaded resources and complex management. Give thorough upfront thought into how you'll shift your monolithic applications to microservices.
These are five of the most common microservices pitfalls software teams face during their migration. Learn their telltale signs, and how you can prevent dangerous failures during the process.
1. Moving too quickly
Rushing into microservices adoption is one of the most common mistakes software teams make. Even though microservices provide a chance to deploy new applications and updates quickly, the distributed architecture's inherent complexity means it's not ideal for certain types of organizations or applications.
Teams should review the state of their existing development culture to see if management skills are in place. They should also examine existing applications to determine whether they are suitable and ready for a migration to microservices. Agile and DevOps principles should be in place, as microservices tend not to play well with a Waterfall development approach. Teams also need diligent training and access to documentation before they begin a migration of monolith-based workloads.
Performance issues soon arise when a microservices migration starts without a proper plan and appropriate infrastructure investments in place. Teams can mitigate these issues if they ensure services are strictly independent from each other but can still communicate normally, as is the target for a loosely coupled architecture.
2. Making services too small
Working with microservices requires considerable domain expertise, particularly regarding the right size for services, meaning the business functions a single service handles. If services are too small, teams end up with more services than they can manage, with each microservice deployed in a separate container. Despite the fact that containers are generally lighter on resource consumption than VMs, they can still generate considerable overhead. An overload of services isolated in containers can also hinder automation of key tasks, such as when teams roll out updates, scale the load and set up asynchronous communication.
There is no fixed standard on microservices sizing. As you migrate monolithic features to microservices, make decisions about what size the services should be to support their specific applications. A good practice is to start with larger services that developers gradually branch into smaller services once they have experience in real-world operations. Finding the right balance is often a matter of time and experimentation.
3. Coupling services too tightly
The idea of microservices is to develop independent services that don't need each other to operate. The services each can be modified without any downtime in other parts of the application. However, teams tend to make the mistake of keeping services tightly coupled as they were in the monolithic design. It's an easy error to make, as monolithic applications rely heavily on strong connections between their associated components.
If developers don't consciously avoid this dependency coupling when they break monolithic applications into services, they'll end up with what is called a distributed monolith. It is essentially an application that is still monolithic in nature, but requires the complex management efforts for microservices.
To avoid this microservices pitfall, learn to create services that are as loosely coupled as possible. Design each service so it can operate without any help from other services. Smaller services that require scaling or updates regularly should be completely independent.
4. Storing logs in containers
Monolithic applications store logs in a centralized location that can trace back any component within the architecture. But logging becomes complicated in microservices, especially when developers choose to place logs inside individual container instances. Instances quickly become hard to find, and any logs stored in a short-lived container get deleted once the container is terminated.
To avoid this problem, teams should store logs in a centralized database or log analytics platform that can connect to distributed containers. Developers can easily access logs and map errors back to their respective services and resolve them.
5. Failure to consider monitoring
The migration to microservices introduces an unfamiliar and complex monitoring scenario to IT teams accustomed to a monolithic app in production. Microservices components are frequently developed on completely different technology stacks. The distributed, communicating services with dissimilar stacks make it hard to detect where exactly an issue originated. And despite best efforts for independence, one service can have unpredictable consequences in some other one.
Investments in centralized monitoring systems that ensure applications don't go rogue and behave unpredictably will help you avoid this microservices pitfall. And if they do, the IT team will know which services to roll back and address.
