Making Microservices Work: Why the Developer Experience Matters

WHAT IS THE DEVELOPER EXPERIENCE?

The developer experience is exactly what it sounds like: it’s the everyday experience your developers have inside your organization. It encompasses everything from the technologies and frameworks they’re allowed to use, available communication channels, the level of documentation they have to handle, whether they’re working with monoliths or microservices, and whether they’re on board with the software development strategy that governs the lifecycle of each project.

Studies show that having a good DX directly correlates with good UX. That is to say, if your developers are feeling frustrated or limited during the development of your software product, then it is very likely that the platform’s UX will be below par.

A strong DX helps create a working environment where your developers want to strive for the betterment of your product or service. It can improve productivity, speed up time-to-market, help solve bugs more quickly and, fundamentally, impact your bottom line in a positive way. 

WITH MICROSERVICES, THE DEVELOPER EXPERIENCE MATTERS MORE THAN EVER

Microservices can potentially make it easier for developers to develop and manage large systems through smaller, autonomous services rather than one large monolith.

We’ve previously written how microservices can aide agile development, but having a microservice architecture on its own is not enough to improve your DX.

Adopting microservices brings about a holistic shift in the way developers work and communicate. Or at least, it should. To ensure each service is well looked after, paying attention to your developer experience both during and after that transition is vital.

Here’s an example of how adopting microservices can pose a threat to the health of your developer experience.

Generally speaking, since each microservice is autonomous, isolated, and independently scalable (despite being able to communicate and work in tandem with other services through API calls), it’s common for each microservice to be assigned to one dedicated team of developers.

Because of that relative isolation, some companies give each team of developers free reign to develop their assigned microservice however they like, using whichever language they prefer. They adopt that approach in order to make each team as comfortable as possible when it comes to developing and maintaining their service.

However, such a great level of flexibility comes with drawbacks. If you have multiple services coded in various languages, you may gain micro-flexibility, but you’ll often lose macro-flexibility. It will be harder, for example, to draft in a developer from another team when somebody is on vacation. Hiring also becomes restricted for each service, as specialized knowledge of the language in question will be needed. Moreover, creating and managing documentation for all those different languages can easily become a nightmare.

This is just one way that problems manifest inside a microservice architecture. But don’t fret, because we’ve compiled five microservice management strategies to help you maintain a healthy developer experience.

5 WAYS TO IMPROVE YOUR MICROSERVICE DEVELOPER EXPERIENCE 

To get the most out of a microservice architecture, you must adhere to some solid development principles. Below, we outline 5 ways you can improve your DX when incorporating a microservice architecture. 

1. FOCUS ON COMMUNICATION & INCLUSION

While we’re huge advocates of microservices, every organization should remember that splitting up teams can create silos, leading to communication issues and instances where teams or individuals feel sidelined. 

When it comes to communication, weekly meetings, Slack channels, and a team outing every so often can help keep your broader team happy and informed.

As for inclusion, you’ll need to consider each team’s preferences when taking on new projects or setting up new services. For example, sticking to one language or framework each time might exclude certain members of your team who aren’t experienced with it. You won’t be able to please everybody with every decision, but be sure to divvy up projects equally between teams to help every team member feel needed and motivated.

2. PROVIDE EXTENSIVE DOCUMENTATION

Ensure you have well-written and detailed documentation for each microservice. The documentation should be set out as if the reader is a newbie to the language or framework being used for that service. This will help make life easier when team members go on vacation, leave the organization, or move internally.

If your documentation is poor, you could end up with a small team having a total monopoly over their service, leading to all sorts of problems when they aren’t around.

3. GIVE FREEDOM (KIND OF) 

Give your developers the freedom to choose the tools and technologies they would like to work with. It’s a great way to boost the motivation of each team.

Yet, as mentioned previously, this approach can bring about major issues. The solution is to give freedom but within limits. For example, you could instruct team leaders to only work with a particular language or framework if:

• Two additional team members outside their immediate team have experience with that language/framework
• They can commit to producing and maintaining documentation for that language/framework

4. IMPOSE RESPONSIBILITY

Another way to keep each team in check is to impose higher levels of responsibility on them beyond simply maintaining documentation.

According to Lewis and Fowler, Netflix pushes higher levels of responsibility onto their development team. Both Lewis and Fowler have hypothesized that by giving developers more responsibility, they acknowledge the fact that they will be called upon if anything were to go wrong later down the line. Therefore, they will be more inclined to rigorously test each microservice to ensure it delivers what it is set out to do.

5. EMBRACE DEVOPS

DevOps is a set of agile software development practices that aims to unify both development (dev) and operations (ops).

DevOps helps to break down the traditional silo between development and operations, where the developer writes the code and sends it to the operations engineer who deploys and maintains it. That silo creates problems when bugs arise, as the operations engineer — the one who didn’t write the code in the first place — won’t understand the problem when it occurs. To get the bug fixed, they have to get in touch with the development team. That sounds relatively straightforward, but that delay between bug detection and bug reporting is sometimes critical. Not to mention, for smaller teams spread around the world, time zone differences cause even greater delays.

By combining both teams, you break down the silo, unify two separate entities, and open up the opportunity for continuous delivery, development, and testing — making it perfect for microservice management.

With the DevOps mindset, engineers are involved in all parts of the software development process, including writing code, development, deployment, and testing as well as operating and monitoring it. 

HAPPY DEVELOPERS, HAPPY MICROSERVICES, HAPPY CUSTOMERS

Adopting a microservice architecture alone will not improve your developer experience. On the contrary, if you aren’t careful about how to manage each service, and how you manage all your services as a group, adopting microservices could harm your developer experience.

The tips we’ve laid out above will help you keep the developer experience on track when adopting microservices, so your business, your developers, and your customers can get the most out of each service.  

For further reading, see our article on the benefits of using containers to structure your microservices.

Got any tips on how to manage microservices while keeping the developer experience in check? We’d love to hear your thoughts in the comments section below!