# My Answers for Microservices Awkward Questions

DevFeed: [My Answers for Microservices Awkward Questions](<https://devfeed.tech/articles/my-answers-for-microservices-awkward-questions-31916.md>)

Original publisher: [Read original article](<http://blog.jayfields.com/2015/03/my-answers-for-microservices-awkward.html>)

Author: Jay (noreply@blogger.com)

Published: 2015-03-15T21:48:00Z

Content type: opinion

Language: en

Sources: [Jay Fields](<https://devfeed.tech/sources/jay-fields.md>)

Topics: [Microservices](<https://devfeed.tech/topics/microservices.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>)

Tags: [coupling](<https://devfeed.tech/tags/coupling.md>), [experience-report](<https://devfeed.tech/tags/experience-report.md>), [independent](<https://devfeed.tech/tags/independent.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [software-development](<https://devfeed.tech/tags/software-development.md>)

## AI overview

An experience report about developing several small, independently deployable codebases that collaborate to provide a single user experience. The author explains that reducing accidental coupling, rather than adopting microservices as a goal, motivated the approach, while noting that the choice involves tradeoffs and is not universally applicable.

## Source excerpt

Earlier this year, Ade published Awkward questions for those boarding the microservices bandwagon. I think the list is pretty solid, and (with a small push from Ade) I decided to write concise details on my experience. I think it's reasonable to start with a little context building. When I started working on the application I'm primarily responsible for microservices were very much fringe. Fred George was already giving (great) presentations on the topic, but the idea had gained neither momentum nor hype. I never set out to write "microsevices"; I set out to write a few small projects (codebases) that collaborated to provide a (single) solid user experience. I pushed to move the team to small codebases after becoming frustrated with a monolith I was a part of building and a monolith I ended up inheriting. I have no idea if several small codebases are the right choice for the majority, but I find they help me write more maintainable software. Practically everything is a tradeoff in software development; when people ask me what the best aspect of a small services approach is, I always respond: I find accidental coupling to be the largest productivity drain on projects with monolithic codebases. Independent codebases reduce what can be reasonably accidentally coupled. As I said, I never set out to create microservices; I set out to reduce accidental coupling. 3 years later, it seems I have around 3 years of experience working with Microservies (according to the wikipedia definition). I have nothing to do with microservices advocacy, and you shouldn't see this entry as confirmation or condemnation of a microservices approach. The entry is an experience report, nothing more, nothing less. On to Ade's questions (in bold). Why isn't this a library?: It is. Each of our services compile to a jar that can be run independently, but could just as easily be used as a library. What heuristics do you use to decide when to build (or extract) a service versus building (or extracting