Understanding Microservices: a guide for the monolithic developer - Layla Porter - NDC Porto 2023

This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #microservices #architecture #softwaredeveloper

Attend the next NDC conference near you:

Subscribe to our YouTube channel and learn every day:

Follow our Social Media!

Microservice Architecture and the reasons why you should move to it, and the reasons you shouldn't, have been well discussed.

If you have already decided to move over to microservices from monolithic development, then you may be finding the whole process a bit daunting.
What aspects should you, a developer be concerned with?
What does all the terminology mean?
How do the services talk to each other?
In this session, I will show you how to get started with microservices architecture, answering these questions and many more.
We'll look at The Tacky Tacos project, built with ASP.NET 6, and explore how the whole process fits together from a development point of view.
Hopefully, you'll leave the session with the confidence to start your own microservices application development straight away!

[simonk]

Nice presentation, thanks. I've been there and done this, and agree with most of the points made here.

I like the point that the path from ball-of-mud should pass through the modular-monolith and never via the distributed-ball-of-mud. As noted, distributed balls of mud are sadly very common and easy to create - but very dangerous. It's also a good point that modularizing a monolith first is a good path for figuring out which bits can effectively be split out into separate services.

I also agree with the bit about asking "are you really really sure". Splitting a large codebase into distributed parts should be done only when the pain of not doing so is higher than the pain of managing the distributed parts - and the pain of distributed systems should not be underestimated. The two categories that can drive the split of a monolith into services are: development-time issues and run-time issues. The primary development-time issue is when there are just too many devs working on one codebase, and getting in each other's way; secondary issues may include wanting different frameworks or languages for different parts, and long unit-test times. Runtime issues may be processes too large to fit into standard virtual machines, excessive startup times, etc. Microservices should be used *only* if you have such problems, and IMO the services should be large - only small enough that these problems don't occur. Managing services is a real nuisance, and having as few of them as possible is a good idea.

Splitting logic needs to be done with great care. As Layla says, synchronous communication is dangerous. Every synchronous interaction between separate processes should be labelled with a big red exclamation mark, flashing lights, and sirens. And each piece of data must have only one owner (one process allowed to modify it). Starting with a modular monolith allows experimentation to get the module boundaries with their responsibilities and data ownership correct _before_ splitting (ie introducing network delays and failure modes into the module interactions). The obvious module boundaries (eg orders, delivery, payment) are often *not* the right split, ie can lead to the need for lots of synchronous dependencies or data replication. Look carefully at the _use cases_, not at your organisation's departmental divisions.

Just a point about multiple services sharing a database. It is indeed dangerous, but there are a range of options. As an example, consider a single relational database with a separate user for each service, where a user (ie service) schema may occasionally include "views" onto tables in other schemas. This gives poor performance-isolation (one service hammers the database, all suffer) but reasonable data isolation: a service can only read data for which such a view exists, it can never modify that data, and the owner of the table(s) the view references can modify their schema as long as it is possible to update views of that table to provide the same columns. Separate databases are of course far better isolated, but come at a far higher cost both in development time and runtime. Even a single schema with prefixes on tables that indicate the "owning service" might work with a disciplined team or appropriate checks implemented. The point is to enable _reasonable isolation_ of per-service data to allow services to evolve - where reasonable is context-specific.

And as mentioned at the end of the presentation, there is a whole lot of other infrastructure and tooling needed for a distributed system. So yes, be really really sure you have a problem that only a distributed system will solve (dev or runtime bottlenecks) before going down that path..

[philadams]

Microservices are so 2017! Most of my projects seem to be in a "Modular monolith" sweet spot shown at 10:16 where it's not a monolith and the extra hassle of microservices is avoided. This is where you can be the most productive and getting actual work done. The other extremes just have too much extra drama that slows things down.