Lesson 114 - Microservices vs. Service Based Architecture

[@martapadillamontoliu4382]

Super comprehensive and useful; thanks Mark. I have seen often enough organisations trying to move to 'microservices' because of all the hype, underestimating the complexity and all the implications (including the organisational ones)

[@markrichards5014]

Glad you found the video helpful Marta!

[@matheussoaressilveira8408]

Great Mark! Both archictectures are very interesting. I think that service based with some miscroservices would fit good as well.

[@mouradhamoud1495]

Thank you for using the star rating table

[@KhoaNguyen-lk4py]

Thank you for giving a useful information. This can help me to rethinking the way that I apply microservices architecture in the existing systems in my company

[@markrichards5014]

Glad it was helpful!

[@conconmc]

@Mark Richards - What about the difficulty of tracing or debugging in microservice architectures? I have often found with the added "ping pong" of micro services it can often be difficult to debug

[@vadimbondarenko1135]

Great and clear explanation, thanks!

[@alexsharma]

Good one. Just a suggestion - record similar video for monolith, event based architecture etc. Vs Micro services.

[@stewarthull7535]

Fantastic explanation!

[@lampham7874]

it's all clear, thanks for your explaination

[@davideb4258]

Silly question about database separation. In a microservice architecture, we say we must use separate databases. Do you mean separate servers, separate databases within a server, or separate namespaces within the same DB?

[@markrichards5014]

That's not a silly question at all! Each service must own its own DATA, whether that data is in a separate schema in a domain or central database or a separate database. Could be either one depending on your scalability and availability requirements. The point is more about access to that data - only the service(s) in the physical bounded context should have access to the data, wherever it resides.

[@davideb4258]

@@markrichards5014 but having data in a single DB can impact scalability, right?

[@markrichards5014]

@@davideb4258 You bet it can! In many cases we try to create separate physical domain databases when possible to help scalability and keep domain data together.

[@silentsudo]

Thank you mark for clear differentiation, can we say that if we are refactoring monolith to microservices then service-based architecture is one of the stop we are bound to arrive at?

[@markrichards5014]

Not necessarily, however it is one I usually recommend as a halfway point when migrating to microservices. In most cases I have seen hybrid approaches, where part of the system uses domain services, other parts use microservices.

[@sant4398]

Thanks for the presentation. I have your book and also read there about the SBA. But I still have a question - why there're no much information about this pattern/style on the internet? If you google it - you will find a lot of links to SOA, but not much to SBA if any.

[@markrichards5014]

Service-based architecture is a term I coined for this hybrid of microservices back in 2013. Many companies are using this architecture, but didn't have a name for it. I'm currently working on an online training for service-based architecture for the O'Reilly platform.

[@iorch82]

About the granularity, some DDD authors talk about bounded conext sized microservices. Doesnt that put them into the SOA territory? Still cant see the differences other than shared data stores.

[@markrichards5014]

Granularity is the other big difference. Microservices = single purpose functions, SBA = domain services (all functionality within that larger domain). Additionally, microservices typically uses micro-frontends, whereas with SBA we typically have single or domain-based user interface.

[@mohamadothman9208]

Thank you very much

[@simonk1844]

Regarding the star-ratings, I could debate the conclusions on many of these. * Elasticity: depends upon startup time (as mark says) - but moderately coarse-grained services can be capable of quick startup. * Evolution: can often be worse for fine-grained services. Functionality changes can require access to additional data - which is more likely to be already available in a larger-grained service vs requiring a new inter-component integration for a fine-grained service. And changing an API used internally within a code-base is far easier than changing one used over a network. There's definitely a big gain in maintainability and evolution when a component is small enough to be maintained by a single team (< 8 devs), but the effects of even finer grain are highly debatable. * Modularity: given each service is a separate code-base then yes a fine-grained service has perfect "modularity". But it is balanced by needing to duplicate code. Modularity therefore does not necessarily mean maintainability or understandability. * Overall cost: agreed, fine-grained services require extra work. Particularly if each has its own DB. * Performance: fine-grained services can be even worse than described here, depending on problem. The critical point is the number of synchronous inter-component interactions - these have very high performance impact. And some fine-grained service approaches do a lot of these. * Reliability: rated as equal in both, but inter-process communication is a very common source of system failures - and some fine-grained designs do a lot of it. Potentially a fine-grained solution can provide limited service while other services have outages, but that depends a lot on other design factors. * Scalability: depends upon the resources needed. A moderately coarse-grained service doesn't necessarily need more resources than a very fine-grained one. * Testability: is really proportional to the number and complexity of connections to other services. As noted above, a fine-grained service can potentially have more such connections than a coarse-grained service. So as always in architecture, the answer depends upon the problem domain. Personally, I think the optimal size is driven by human nature and limitations; services should be small enough to be maintained by a team of no more than 8 devs. Below that I'm not convinced of the benefits of finer grain in most cases..

[@markrichards5014]

The star ratings are meant to be the *general* characteristics as compared to other styles using qualitative analysis. There are certainly cases (as you've pointed out) that can change these star ratings, and, as always, "it depends" on your particular circumstance and design.

[@murghay01]

This was amazing!

[@yar697]

Waching your video and reading your book at the same time. But cant understand which type of architecture i made on my project now. Its not fine grained, and some services are doing 3-4 related functions. All of them have separate DB. They separated to two domains. I think, that it it MS, but some still doubted)

[@JamesSmith-cm7sg]

Hi Mark, I assume these scores are independent of team size? For example, the scores could be radically different if you have 5 developers versus 500?

[@alxx736]

Can you make a Video about why microservices do not need ESB?

[@markrichards5014]

Good idea! In short, it's all about the bounded context in microservices and the consolidation of all business logic within a service. See lessons 43, 44, and 45 on how to provide the capabilities of an ESB in microservices.

[@alxx736]

@@markrichards5014 Thanks

[@deepakmc8090]

Good one

[@michaeldeng1981]

Totally agree, microservices are much harder. For most of enterprise projects, I think service-based architecture should be good enough.

[@apgd81]

Well noted…. Scalable, elastic but with bad performance