4 ms·

I love my service based architecture. It's about 10 years old and I can't imagine a better way of separating concerns and keeping a clean, maintainable, and re

I love my service based architecture. It's about 10 years old and I can't imagine a better way of separating concerns and keeping a clean, maintainable, and resilient e-commerce operation up and running. I don't have hundreds of services, there are maybe 30. Each service is responsible for a particular domain, and if another service wants access to that domain it must go through the appropriate service. I can't imagine having a single process "monolith" being responsible for so many things, it would be a nightmare. I also can't imagine not enforcing separation of concerns via services, code would be duplicated everywhere. I was thinking the other day about the cost of serialization, which isn't too bad. If it is too bad then you're probably sending too much data over the wire, and should do more processing on the remote end of the wire. I think some people go overboard with the micro part of microservices. If there isn't a clear separation of domain, then there should probably just be one service. You can still modularize the code as much as you want within the service.

lxe 6y ago
Sounds like you've hit the SOA sweet-spot.
lilbobbytables 6y ago
Do you get the benefits of separation by using separate data stores as well, or are most fed from a common database?
- jacob019 6y ago
  Most data is stored in the same database server instance. There is a database access service that with seperate modules for each database, by convention each of these modules has exclusive access to it's tables with the exception of a special module that performs cross-database joins, needed for performance with some reporting tasks. Other services don't talk directly to the database, they go through the database service. Some services use their own data stores in a variety of formats.
simonw 6y ago
How big is your team? What kind of process do you use to on-board new engineers to the point that they can make good design decisions within your architecture?
niffydroid 6y ago
We have the same way, a main monolith to do the basics, create and update. But other parts of the system handled by a server. A lot of it is queue consumption based. E.g a server for sending emails, another server for file exporting. Our main system also shares a module for connecting to the DB, which makes it easier to handle database upgrades or changes.
marcyb5st 6y ago
I'd like to challenge the "I can't imagine a better way of separating" bit. I agree that microservices, if done right, are awesome. Recently, however, I had the chance to work with a quite extensive codebase that powers a monolith for a fintech company. The code is written in Scala and extensively uses Akka-streams to neatly separate concerns. In my opinion this approach is the the sweet spot as 1) Devops burden is low as you only have one binary to run / deploy 2) Shapes of the various Akka-streams subgraphs are statically typed checked (unless you opt-out by doing stupid things), 3) makes it much easier to reason about the data flow, and 4) testability is really high as you don't have to mock services but only the upstream subgraphs. The downsides are that 1) the learning curve is very steep at the beginning as Akka in general is very complex to use effectively, and 2) squeezing the maximum performance can be hard as you don't have the ability to horizontally scale only some microservices. I fell in love with the approach and I'm migrating some personal projects to it.
- 0x445442 6y ago
  I've seen very few posts here mention horizontal scalability like you did. In my mind, it's the first and foremost reason to consider a distributed rewrite over a monolith. I would bitch long and hard if someone was suggesting the transition from monolith to micro-services without the metrics to prove horizontal scalability was becoming an issue.
  - marcyb5st 6y ago
    Fully agree. Another point worth considering is costs. Cloud providers now let you use ephemeral VMs which are amazing in terms of value. If you can identify some parts of your system that use too much in terms of resources you can get quite some nice costs savings by wrapping that around a microservice and deploy it in said cheap VMs.

lxe 6y ago

Sounds like you've hit the SOA sweet-spot.

lilbobbytables 6y ago

Do you get the benefits of separation by using separate data stores as well, or are most fed from a common database?

jacob019 6y ago
Most data is stored in the same database server instance. There is a database access service that with seperate modules for each database, by convention each of these modules has exclusive access to it's tables with the exception of a special module that performs cross-database joins, needed for performance with some reporting tasks. Other services don't talk directly to the database, they go through the database service. Some services use their own data stores in a variety of formats.

simonw 6y ago

How big is your team? What kind of process do you use to on-board new engineers to the point that they can make good design decisions within your architecture?

niffydroid 6y ago

We have the same way, a main monolith to do the basics, create and update. But other parts of the system handled by a server. A lot of it is queue consumption based. E.g a server for sending emails, another server for file exporting. Our main system also shares a module for connecting to the DB, which makes it easier to handle database upgrades or changes.

marcyb5st 6y ago

I'd like to challenge the "I can't imagine a better way of separating" bit. I agree that microservices, if done right, are awesome. Recently, however, I had the chance to work with a quite extensive codebase that powers a monolith for a fintech company. The code is written in Scala and extensively uses Akka-streams to neatly separate concerns. In my opinion this approach is the the sweet spot as 1) Devops burden is low as you only have one binary to run / deploy 2) Shapes of the various Akka-streams subgraphs are statically typed checked (unless you opt-out by doing stupid things), 3) makes it much easier to reason about the data flow, and 4) testability is really high as you don't have to mock services but only the upstream subgraphs. The downsides are that 1) the learning curve is very steep at the beginning as Akka in general is very complex to use effectively, and 2) squeezing the maximum performance can be hard as you don't have the ability to horizontally scale only some microservices. I fell in love with the approach and I'm migrating some personal projects to it.

0x445442 6y ago
I've seen very few posts here mention horizontal scalability like you did. In my mind, it's the first and foremost reason to consider a distributed rewrite over a monolith. I would bitch long and hard if someone was suggesting the transition from monolith to micro-services without the metrics to prove horizontal scalability was becoming an issue.
- marcyb5st 6y ago
  Fully agree. Another point worth considering is costs. Cloud providers now let you use ephemeral VMs which are amazing in terms of value. If you can identify some parts of your system that use too much in terms of resources you can get quite some nice costs savings by wrapping that around a microservice and deploy it in said cheap VMs.