Am I Being Misled About Microservices?
In the fast-paced world of software development, it’s not uncommon to encounter buzzwords and technical jargon that can leave team members scratching their heads. Recently, I’ve found myself questioning the authenticity of our microservices approach at work. This is my exploration of what happens when industry terminology is used without a concrete understanding.
Take, for example, our unit testing practices. It seems we’re calling what should be simple unit tests a comprehensive integration test, replete with a staggering 2,800 assertions, and an impressive coverage of 80% of a single file. This raises a couple of eyebrows, don’t you think?
Then there’s the peculiar practice of computing CSS classes on the backend—an approach that seems unnecessary at best. But what really has me puzzled is our definition of microservices. In theory, these should be modular, independent units of software, each with its own API for communication. However, in our case, we’re left without an API, simply because implementing bearer tokens or establishing any form of authentication was deemed “too challenging.”
So, how do these so-called microservices communicate, you might wonder? The rather unsettling answer is that they don’t! During deployment, a script copy-pastes the code from a select few “Core microservices” into all the others, allowing for code reusability but defeating the purpose of true microservice architecture.
And the confusion doesn’t stop there. When the logging microservice encounters an error, it’s almost predictable that other modules—some of which have no dependency on logging—also go down as a result. It’s a peculiar chain reaction that leaves much to be desired.
As a developer with five years of experience, one year of which has been spent working in environments touted as “microservices,” I cannot help but question this approach. Having devoted time to learning about Kubernetes and microservice principles, I find myself grappling with the effectiveness of our current practices.
Is it possible that we’re mishandling the concept of microservices, inadvertently losing sight of their true purpose? It’s a question worth reflecting on as we navigate the complex landscape of modern software development.
2 responses to “Have I been led to believe mistakenly that I work with microservices?”
It sounds like you’re navigating a challenging environment that blends misconceptions about microservices with questionable practices. Let’s unpack what you’re experiencing and offer some insights and practical advice.
Understanding Microservices
Microservices architecture is fundamentally about building applications as a suite of independently deployable, small services. Each service serves a specific business purpose and communicates over a network, typically through APIs. Here are some key principles of microservices that seem to be lacking in your current setup:
Analyzing Your Situation
Based on your descriptions:
Unit Tests vs. Integration Tests: It sounds like tests are being conflated. A unit test should focus on small pieces of functionality in isolation, while an integration test involves a combination of services working together. Having 2800 assertions in a single test indicates a lack of clarity in defining what a unit is.
Backend CSS Processing: Computing CSS classes in the backend might be an architecturally questionable choice, depending on your app’s requirements. It could be indicative of an effort to centralize logic that might be more appropriately handled in the frontend or through a design system.
Lack of APIs and Credentials: The absence of proper APIs suggests that the microservices might not be set up for genuine decoupled operation. Functions that should be independent are instead reliant on manual processes, undermining the benefits of microservices.
Copy-Pasting Code: Manually copying code from a core service into others is a violation of the microservices principle of maintaining independent codebases. This can lead to significant difficulties in maintenance and debugging, as well as bugs propagating across services.
Practical Advice
Here are some steps you can take to address the issues you’ve identified:
Educate on Microservices: Initiate discussions within your team about the fundamentals of microservices. Offer resources (such as articles, videos, or workshops) that explain proper microservices architecture.
Propose an Architecture Review: Suggest a review of the current architecture involving an external consultant or expert if possible. This can help identify where the current setup is failing to meet the intended goals of microservices.
Establish Clear Guidelines for Testing: Drive the development of a testing strategy that distinguishes between unit tests and integration tests. Educate your team on what constitutes proper testing practices.
Encourage Documentation: Stress the importance of documentation. Services should have clear API documentation to facilitate understanding among team members and new developers.
Implementation of Service Mesh: If your project is large enough, consider adopting a service mesh (like Istio or Linkerd). This can help manage service-to-service communications and provide features like API management, traffic, and security policies.
Proposal for Incremental Changes: Lead discussions about incrementally transitioning to a more robust microservices architecture. Begin with refactoring the most critical components into independently deployable services.
Reflecting on Your Experience
Your experience as a developer with five years in the field is valuable. Sometimes, organizations may cling to outdated or incorrect interpretations of programming paradigms. It’s not uncommon for a junior or even mid-level developer to feel overwhelmed or out of place in such environments. Engage in constructive dialogue with your team and continue developing your skills. Over time, your insights and experiences will contribute to evolving the organization’s practices for the better.
Remember, empowering teams with the right architecture fosters not only better code quality but also boosts morale and productivity.
Thank you for sharing this insightful exploration of your experience with microservices! Your concerns highlight a critical issue in many organizations—misunderstanding or misapplying the principles of microservices can lead to inefficiencies and a bloated architecture that ultimately detracts from the intended benefits.
Your observations about the enormous integration tests masquerading as unit tests resonate deeply. This practice often arises from a lack of clarity about what constitutes unit versus integration testing. True modularity in microservices not only simplifies testing but also enhances maintainability. It would be beneficial for your team to revisit these testing strategies to align them more closely with microservice principles, ensuring that each microservice is self-contained and easily testable.
Additionally, your point regarding backend-generated CSS classes raises an important debate about the boundaries of service responsibilities. Microservices should indeed focus on discrete functionalities, while frontend-related concerns can ideally be handled within client-side frameworks. This separation can lead to cleaner, more efficient service interactions and a more responsive user experience.
Moreover, the copying of code from core services into others defeats the core tenet of microservices—encapsulation and autonomy. This tactic may save time in the short term, but it can lead to a tangled web of dependencies that ultimately stifles innovation and agility. Emphasizing API-led communication would not only remedy this but also align with best practices that enhance scalability and maintainability.
Lastly, your reflections on the cascading failures where unrelated modules go down due to issues in the logging service illustrate the challenges of