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

By Taylor Veino

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

  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

TRAVIS:

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.

 

The Frontier, a really cool podcast created for software engineers by us.

Check Out Our Previous Episodes