4 ms·

This seems like a common side-effect of an overly segmented microservice architecture. I’ve noticed this pattern numerous times, my guess is service/feature te

This seems like a common side-effect of an overly segmented microservice architecture. I’ve noticed this pattern numerous times, my guess is service/feature teams want to avoid at all costs taking another service dependency (and all the testing and coordination that entails) so they just punt. Sometimes a big old RDBMS housing all of your data which is actually already related in reality makes the most sense.

ascales 7y ago
I'd say it's more bad UX testing and bad project management over implementation or infrastructure. A well designed feature-set can be architected a nearly infinite number of ways.
- Ididntdothis 7y ago
  Some architectures make it easier to combine data than others. In one big database it’s relatively easy and quick to look at data from a different angle. If your data is distributed over several systems it’s much harder and takes longer to implement.
futureastronaut 7y ago
What if I told you that you could be hobbled by inconsistent, scattered state in a system not expicitly designed to be distributed. There's no point in jumping to the conclusion that they are using a design you're familiar with.
alkonaut 7y ago
This. A web shop with carts/checkout, inventory, search etc should be one monolith service over one database - even if your operation is a global megacorp. Do try to split it into microservices all you want, but if anyone notices (such as having to enter something twice) you failed.
- skrebbel 7y ago
  That will only work if the entire "global megacorp"'s database is the web shop database that you describe. How else are you going to show availability of products in a shop nearby you? How are you going to combine the webshop's delivery logistics with the distribution centers of the entire brick&mortar retail chain? How are you going to expose loyalty card benefits online? How are you going to keep the product catalog in sync with what's in stores? Like all retail bigcorps, I assume that IKEA has lots of internal systems, half self-cooked, half based on SAP or Oracle or whatnot, that together form the entireity of their operations. These formed long before "microservices" were hip and trendy and will be around long after the hype has died away. The webshop is a part of all that and it must be closely connected to the rest of the IT in lots and lots of places. So, what you're suggesting is "IKEA should just rebuild their entire product, sales, supply&demand, logistics and finance IT from scratch in a single monolith on a single database". That'd be a fine end-result indeed, but unachievable on any timescale.
  - detaro 7y ago
    I'm sure SAP will gladly spent a few billions of their money trying :D
  - alkonaut 7y ago
    They don’t need all IT in one service but the web shop needs at least a view of accounts, inventories and so on. That db can be a cached view which means it behaves as a single db with staleness issues (changed passwords or preferences may be stale, you may be able to add things to a cart that appears to be in stock but really is out of stock in the true inventory etc.). It’s better to have such a poorly working illusion of a single db than to have no such illusion at all which means having to log in multiple times etc.
- stepbeek 7y ago
  iirc Amazon worked like this for their first n years before the difficulties that resulted made a SOA more compelling. I think there's a middle ground between microservices and a single monolith for a large global corporation.
VBprogrammer 7y ago
> Sometimes a big old RDBMS housing all of your data which is actually already related in reality makes the most sense. Which is all fun and games until some intern gets asked to add a 'most popular' sort to the search page. He quickly figures out where the 'OrderProduct' table is, throws in a quick count and a group-by to the search query and the whole site gets taken down by it. Of course I take your point but there is somewhere between everything in one monolithic DB and every bit of data has its own microservice. It needs good judgement to divide it appropriately.
- marcosdumay 7y ago
  That's why you do stress testing with production data... That I know the store won't do. But then, if they are so large that it's a crisis, they have no excuse, and if they are small enough to have an excuse, they quickly revert to the last version and try to discover what went wrong.

ascales 7y ago

I'd say it's more bad UX testing and bad project management over implementation or infrastructure. A well designed feature-set can be architected a nearly infinite number of ways.

Ididntdothis 7y ago
Some architectures make it easier to combine data than others. In one big database it’s relatively easy and quick to look at data from a different angle. If your data is distributed over several systems it’s much harder and takes longer to implement.

futureastronaut 7y ago

What if I told you that you could be hobbled by inconsistent, scattered state in a system not expicitly designed to be distributed. There's no point in jumping to the conclusion that they are using a design you're familiar with.

alkonaut 7y ago

This. A web shop with carts/checkout, inventory, search etc should be one monolith service over one database - even if your operation is a global megacorp. Do try to split it into microservices all you want, but if anyone notices (such as having to enter something twice) you failed.

skrebbel 7y ago
That will only work if the entire "global megacorp"'s database is the web shop database that you describe. How else are you going to show availability of products in a shop nearby you? How are you going to combine the webshop's delivery logistics with the distribution centers of the entire brick&mortar retail chain? How are you going to expose loyalty card benefits online? How are you going to keep the product catalog in sync with what's in stores? Like all retail bigcorps, I assume that IKEA has lots of internal systems, half self-cooked, half based on SAP or Oracle or whatnot, that together form the entireity of their operations. These formed long before "microservices" were hip and trendy and will be around long after the hype has died away. The webshop is a part of all that and it must be closely connected to the rest of the IT in lots and lots of places. So, what you're suggesting is "IKEA should just rebuild their entire product, sales, supply&demand, logistics and finance IT from scratch in a single monolith on a single database". That'd be a fine end-result indeed, but unachievable on any timescale.
- detaro 7y ago
  I'm sure SAP will gladly spent a few billions of their money trying :D
- alkonaut 7y ago
  They don’t need all IT in one service but the web shop needs at least a view of accounts, inventories and so on. That db can be a cached view which means it behaves as a single db with staleness issues (changed passwords or preferences may be stale, you may be able to add things to a cart that appears to be in stock but really is out of stock in the true inventory etc.). It’s better to have such a poorly working illusion of a single db than to have no such illusion at all which means having to log in multiple times etc.
stepbeek 7y ago
iirc Amazon worked like this for their first n years before the difficulties that resulted made a SOA more compelling. I think there's a middle ground between microservices and a single monolith for a large global corporation.

VBprogrammer 7y ago

> Sometimes a big old RDBMS housing all of your data which is actually already related in reality makes the most sense. Which is all fun and games until some intern gets asked to add a 'most popular' sort to the search page. He quickly figures out where the 'OrderProduct' table is, throws in a quick count and a group-by to the search query and the whole site gets taken down by it. Of course I take your point but there is somewhere between everything in one monolithic DB and every bit of data has its own microservice. It needs good judgement to divide it appropriately.

marcosdumay 7y ago
That's why you do stress testing with production data... That I know the store won't do. But then, if they are so large that it's a crisis, they have no excuse, and if they are small enough to have an excuse, they quickly revert to the last version and try to discover what went wrong.