Microservices: when to choose it, how to migrate painlessly, & make it resilient

TL;DR style notes from articles I read today.

Musings on software architecture: monoliths to microservices


• Microservices architecture adds huge complexity overheads on your infrastructure & may not be suitable for a new project from the start.
• As a developer, you take on a lot of communication and coordination in addition to coding.
• Even successful companies using microservices today started as monoliths.
• When you start with a single team and a single product, it is logical to continue with a monolithic application.
• Later, teams can split to be responsible for single services. Microservices may make better sense after that growth and when necessary experience and expertise is gained.


Full post here, 4 mins read

---

9 tips for a painless microservices migration

• Draw domain lines to define and document your business entities early on. Be mindful of how you cross the boundaries between these entities.
• Document your URL route domains and ensure everyone follows the one convention.
• Be explicit about routes and methods. Avoid wildcard routes and wildcard verbs or HTTP methods.
• Assign URL endpoint ownership for clean formation of teams in the future.
• Monitor URL usage by instrumenting the endpoints - at least graph the request rate, if not the error rate and performance of every HTTP endpoint you expose.
• Kill dead code - delete it, not just comment on it. Have source code control for history, if needed.
• Document the environment variables a service, class or module uses. 

Full post here, 8 mins read

---

3 easy things to do to make your microservices more resilient

• Test your system using chaos strategies.
• Have a plan to at least partially fulfill your service promise in case of a fault, whether it is a canned message or calling a different service as a backup.
• Be conservative in what you send to a service and liberal in what you accept. Your unmarshalling logic should do just enough validation of responses and pull out just the data you need rather than executing a full validation.
• When services fail, multiple iterations of the same message should not add inconsistencies to your users’ systems.
• Use infrastructure that filters out duplicates. Or, track unique identifiers in the messages and discard those that are already processed successfully. 


Full post here, 7 mins read

---

Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

Comments

[James Eastham]

Interested to discuss, but I disagree slightly with your point of single project/single person teams still using monoliths.

I work for a small company and am the only full-time dev. We implement a lot of different software solutions for our clients, and since finding microservices it's become my de-facto way of developing.

Two reasons

• The capability to be able to change a single service without worrying about everything else is completely invaluable with such a small team. Committing a change and it auto testing and rolling out to production saves valuable man hours
• It gives us re-usable components that multiple clients can use

Agree with every other point wholeheartedly though :) I love your style of articles as well Arpit!

[Arpit Mohan]

Thanks James! Glad you enjoy the articles.

While microservices are a useful construct, architecture patterns follow Conway's Law. Microservices pattern is no different. My sense is that, in your case, if you are the only full-time dev and are working with other folks (remotely, part-time, or on contract basis), microservices work better for you because of Conway's Law :D

It's useful to break down any application into smaller services that communicate with each other. But the management & communication overhead of each microservice starts to take over at an exponential rate. That's why, personally, I've always felt that monoliths with a good structuring of packages, libraries etc work better. Then, I'm only working on a single code-base which is easier to run & test locally without other dependencies involved.

Re-usable components for multiple clients could be published as libraries/npm packages. That way, you don't have to run it as a separate service communicating over TCP.

[James Eastham]

Agree on the fact that the management & communication overhead. There is a lot more to think about in terms of interactions between things, but I find it makes you much more conscious of the changes that are made to any service.

I also find it forces me into being more TDD. If I know a data model in API A is relied on by a Worker B then I'll write a test to ensure the correct properties are always returned.

Interesting point on the monolith with good package structuring though. Never really thought about that. It's almost strongly typed 'microservices' all running in the same executable.