Microservices are loosely coupled services that are organized around business capabilities. In an ideal microservices architecture, each service can be developed and deployed independently. To form a functional application, these separate services communicate with each other in the production environment (and even beforehand). In this article we will discuss some microservices challenges and blind spots for developers and how to best overcome them.
Due to their development and deployment structure, microservices architectures are supposed to enable engineering organizations to develop at a higher velocity. Independent deployment supports faster scaling, enables using multiple programming languages simultaneously and better supports cloud-native applications and containers. These characteristics enable agility and automation, which drives faster delivery and deployment.
However, despite the many engineering advantages of transitioning from monolith to microservices, some of the operational and maintenance benefits of monolith architectures did not transition, too. We asked our developers at Helios what their main pains were when coding with microservices. Based on their answers and additional research, here are the top 5 challenges and blind spots of microservices for developers:
1. Microservices Testing
Testing is one of the most prominent challenges of microservices. Because of the way microservices are designed – loosely coupled with optional boundaries and connection points that create dependencies – testing microservices is complex.
The intricate dependencies and separate deployment times mean that testing can only accurately grasp a developer’s own service. Anything beyond requires either testing in pre-production or production environments, relying on possibly outdated testing or staging environments, or on mocking – which is complex on its own. Therefore, developers often have to give up testing certain use cases or make assumptions that are not necessarily consistent with what is actually taking place in production.
This lack of developer visibility into the entire microservices architecture means tests might pass one day and fail the next. In other words, developers cannot be confident that testing will ensure code quality and application functionality and performance.
However, running end-to-end tests or integration tests is also no easy feat – due to lack of tools, time or proficiency. Many services communicate asynchronously so tests often miss exceptions that are thrown in the “deeper layer” of the system architecture, which is not easily testable.
As a result, testing microservices takes a very long time. This time is spent on defining test cases, writing tests and setting up multiple configurations and cloud provider requirements. These activities might even take more time than writing the original code itself. As a result, deployment process times increase, instead of decrease, which is the opposite of what microservices should enable.
2. Microservices Development
It might seem surprising to include a section that discusses “development” as a microservices challenge. After all, developing new features is, by definition, the main role of developers (“You had one job”, etc.). But the fact of the matter is that microservices might be hindering development.
When developers are scared to make changes in the complex microservices system because they don’t know what might break (see the “Testing” section above), they’re not sure how to incorporate legacy code into new development practices, or they don’t know how to create and run environments and requests, this is not a developer problem, it’s an organizational problem. As a result, code is not properly developed in the SDLC and is not production-ready.
3. Microservices Troubleshooting & Debugging
Identifying issues, reproducing scenarios, and fixing bugs and errors is a time-consuming and difficult task (and according to some developers – it’s also no fun). In microservices, it is even more complex and annoying, because the lack of visibility into the microservices architectural big picture prevents developers from seeing which services and components could have caused an error and how services depend on each other. They just don’t know what happened to their code after pushing to prod.
In addition, they also lack more granular data that could enable proper investigation and help them get to the root cause of the issue – like HTTP request body, Kafka messages, and Lambda events, which is required for troubleshooting and debugging, and for retriggering issues.
Troubleshooting today means developers have to manually comb through log data or attempt to recreate issues. But this is insufficient since they lack payload data and visibility.
4. Services Communication
By microservices design, application functionality requires services to communicate with each other. This requires proper configuration of APIs, while taking into account response handling, error handling, requests, security, and more. Otherwise, the architecture will create high latency and insecure communication.
While many developers leave this to DevOps, developer ownership of communication actually increases code quality and velocity. But how many developers actually take on this complicated responsibility?
5. Operational Complexity
As each microservice is developed and deployed independently, each team can choose which technology stacks and frameworks to use and implement. This creates operational challenges for services communication, monitoring, scalability, and consistency. To overcome this challenge, close and continuous communication is required between teams. If this isn’t handled properly, it can create constant tension.
Leveraging Distributed Tracing Data to Overcome Microservices Challenges
Distributed tracing data can be leveraged to overcome the challenges of developing microservices and to provide successful solutions. Tracing data can be used to visualize the entire microservices architecture in a way that provides a broad understanding of the architecture and data flows. Then, tracing data granularity provides actionable insights that are sufficient for investigating issues and resolving them.
Let’s drill down and understand what this means, by looking at each challenge and seeing how distributed tracing data can help:
- Testing – Distributed tracing data can be used to automatically generate comprehensive tests that validate behaviors from deep within the system, including the use of complex assertions that otherwise would be very difficult to implement. In addition, trace-based tests can even be generated straight from production, ensuring reliability and consistency.
- Developer Observability – Distributed tracing data provides visibility into the architecture and data insights across all environments – from local to testing and staging to production. The visibility into data flows, payloads, dependencies and errors, while providing information that enables reproduction of issues, provides developers with the information they need to develop and deploy production-ready code.
- Troubleshooting and Debugging – Distributed tracing enables gathering payloads and error data for pinpointing bottlenecks, identifying broken flows and reproducing them, to support troubleshooting and debugging.
- Services Communication – Distributed tracing helps developers make sense of sync and async flows and dependencies, so they can ensure services interact with each other – as part of their SDLC.
- Operations – Distributed tracing enables sharing and reusing requests, queries, and payloads, which improves developer communication and collaboration.
