Skip to content
Back to Blog

Service discovery in a microservices architecture

Taylor Veino

Jan 9, 2019 12:45:00 PM

5 Reasons You Should Care about Service Discovery in a Microservices Architecture

Travis Scheponik is a Master Software Engineer, currently with Capital One. His areas of expertise include legacy system conversion, cybersecurity, and application performance, as well as recent projects in service discovery, a topic we delve into in detail in this episode.

1. How Service Discovery Impacts Microservice Architecture

TRAVIS:  Service discovery, very briefly, is just a way that developers and product owners, for example, can find new and exciting code implementations so they can build that new functionality.

What that will do is say, “Hey, Service X, I can now capture this piece of customer data and anybody else who wants to use this piece of customer data, just go right here to our registry and, from there, you can start stitching things together.”

That's kind of at a very high level and very broadly touching on service discovery and the whole registry concept.

2. Human And Organizational Problems To Deal With

In those situations, it may actually be a case where the way the governance is rolled out has rough edges that could be smoothed over. And if those edges were smoothed over, maybe more teams would be willing to engage in this kind of “Let's share everything. Let's all take the shared experience of managing enterprise level systems and enable our partners whether they're internal partners or external partners to be successful.”

3. Project-Owner Burnout

LEDGE:  You actually see project-owner burnout because they can't distribute the ownership burden. It really isn't about the code in all those cases. It's actually about the ancillary support that is really the human problems around the code.

TRAVIS:  Yes, I absolutely agree. The code is so beautiful all by itself. Then, the users get a hold of it or the other teams get a hold of it. And then, it just falls apart.

It's all about trying to show that you'd want to be a part of the community. You'd want to try to make it as easy on the “maintainer” or the “product owner” because you are right. Eventually, those people will leave. They'll find new projects. Nobody is going to want to pick those things up and keep running with them.

4. Planning Ahead

TRAVIS:  Ultimately, you will hit that point of either team scale or code-based scale or service scale where you need this kind of centralized location where other teammates can pull information.

But it reminds me of whenever in school I would have to write a paper. It's like if you write the paper first and then do the outline later, of course, it's easy to say, “Of course, this is what we needed. Look how my outline matches my end result.”

5. Advice To Freelancers

TRAVIS: The one thing I can offer in the whole umbrella that we've been chatting under is that it's all about speed to market. If you can be fast and stable, you're going to have super value add. It will be rough at times but, eventually, you'll make it through the journey.

Written By:

Taylor Veino

Want to get our totally not sh*tty weekly newsletter?

Sometimes The Wayfarer is funny, sometimes insightful, but always the least spammy newsletter this side of Tatooine.