Developer Roundtable: Navigating Microservices

If you have never seen or read the Grug Brained Developer, then you are welcome because here it is for you to enjoy. Cody, one of the developers at Flagrant, shared this with folks on the team and it was a good re-exposure for some and a nice first time reading for others.

TL;DR: This is a funny website that takes the perspective of a “grug brain,” or someone who is not super smart but definitely has experience and tries to keep things as simple and understandable as possible. Here is a small part as an example:

“grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

Seem very confusing to grug”

This specific quote is talking about: Microservices. A buzzword we hear often in software development, and for good reason: done right, microservices can offer improved flexibility, scalability, and autonomy in development teams. However, as Cody nicely put it in our discussion, “I feel like it’s one of these things that everyone continually tells me is a bad idea. Don’t do this.” This roundtable explored when microservices are advantageous, as well as the traps that can make them a bigger problem than the benefits that you might be rewarded with. So when are microservices the right choice? As usual in software, it depends. Cue eye roll.

What Are Microservices, Anyway?

At their core, microservices are a way to organize software by creating distinct, loosely-coupled services that handle specific tasks. Each service operates independently, often using its own database and infrastructure, and communicates with others via APIs. But there’s more to the story, as Casey highlighted: “I think we as programmers deal in abstractions so much that we fall for the trap of treating two things as equivalent if they can occupy the same box on a whiteboard.”

In real-world applications, treating microservices as distinct entities without clear boundaries can lead to pitfalls, especially in systems requiring a high volume of inter-service communication.

The Case for Microservices: An Example in Security Analysis

One example of effective microservice use emerged when Casey shared his experience working on a security analysis app. Here, each job, whether it’s analyzing URLs, checking email attachments, or scanning for malware, is assigned a specific “microservice.” Each service is tailored to handle its unique task effectively, yet they function independently and only report results to a centralized system once complete.

This approach exemplifies fan-out microservices, where each task is delegated and handled independently. It’s a fitting solution when the primary concern is resource allocation (e.g., heavy virtual machines versus lightweight APIs), allowing each task to be scaled up or down as demand requires. In such cases, microservices can help manage resource-intensive operations without overwhelming the system, which aligns well with the core benefits of this type of architecture.

Microservices: The Pros and the Traps

While the structure Casey described shows microservices at their best, it’s easy to slip into a complex mess when these services become overly interdependent. Yossef summarized the issue well, mentioning that a fully interconnected network of microservices is a recipe for disaster: “Draw your graph and then see how sad it makes you.”

The potential pitfalls include:

• Over-complication: Dividing a system into microservices without clear boundaries creates excessive inter-service calls, leading to degraded performance and communication bottlenecks.
• Orchestration Challenges: Coordinating multiple services and managing their dependencies can increase the risk of errors. One missing or delayed service can disrupt the entire workflow.
• Hidden Network Costs: Unlike single-process calls, inter-service network calls introduce latency and require fail-safes, which add complexity.

In short, the real strength of microservices lies in their ability to operate as largely independent units, reducing dependencies while handling distinct responsibilities.

When Does It Make Sense?

Microservices shine when:

1. Scalability Needs Vary: Different parts of your system need to scale independently (e.g., handling different workloads and response times).
2. Autonomy: A team or function needs the freedom to iterate independently.
3. Interdependence Can Be Managed: The architecture allows for task delegation and loose coupling, making microservices ideal for fan-out tasks that only need to report results without constant back-and-forth.

Ultimately, as mentioned earlier, “it depends.” Microservices can be invaluable in the right situation, but the trade-offs are something that should be seriously considered. As developers, we need to weigh both the technical and organizational factors carefully before deciding. It’s all about finding the balance that allows your system to thrive, without adding unnecessary complexity.

Whether it’s a monolith or microservices, the right architecture will always depend on your unique needs, your team, and a clear understanding of the why behind your choice. The key takeaway is that no solution is one-size-fits-all, and the answer is almost always “it depends.”

---

Enjoyed this content? Join our developer roundtable, we meet every other Friday from 10:30 - 11:30 am CT. Hope to see you there!

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.