Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analysis of Software Architectures

firatatagun.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: Analysis of Software Architectures

#11

Post by virmundi »

amelius wrote: post #7
perlgeek wrote: post #6

This articles makes the assumption that features are easier to develop if subsystems are broken up into separate components, with separate data sources and deployments. But experience shows that this is only sometimes the case. Monolithic applications with a big SQL engine as the backend have the advantage that you can do joins very easily. If the data is split into three microservices, you spend much more time think…

I guess that not just the joins become more difficult in a partitioned system, but especially transactions. Maintaining transactional consistency across multiple services seems to me like a nightmare. Even writing tests that address consistency could be very difficult.

Often you don't worry about transactions across services. I know that someone will say we have to have them. In such cases, fine worry about them. In everything else, either isolate the write side of a transaction in one service or don't require them.

Re: Analysis of Software Architectures

#12

Post by [deleted] »

amelius wrote: post #7
perlgeek wrote: post #6

This articles makes the assumption that features are easier to develop if subsystems are broken up into separate components, with separate data sources and deployments. But experience shows that this is only sometimes the case. Monolithic applications with a big SQL engine as the backend have the advantage that you can do joins very easily. If the data is split into three microservices, you spend much more time think…

I guess that not just the joins become more difficult in a partitioned system, but especially transactions. Maintaining transactional consistency across multiple services seems to me like a nightmare. Even writing tests that address consistency could be very difficult.

[deleted]

Re: Analysis of Software Architectures

#13

Post by skrebbel »

alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

I violently agree, and I suspect most of HN does.

There's an associated danger though: I find that many startup hackers actively dismiss good ideas (and even entire programming languages) simply because they smell a bit of CoA.

Even the CoA crowd occasionally comes up with truly good ideas that have way more substance to them than the meaningless patterns mentioned in this article.

As an example: My personal pet peeve is the startup world's ignorance of Domain-Driven Design and CQRS (Command-Query Responsibility Segregation). If you want to make scalable backends, I really recommend you read up on CQRS, it's practical and it fits modern ideas. Most examples are in C#, but you'll survive.

For frontenders, CQRS is basically Flux on the backend, kinda sorta. It ought to be super hip right now but it isn't, and I suspect that's only because it comes from C#-o-world and has a ridiculous unpronounceable acronym.

Re: Analysis of Software Architectures

#14

Post by extrapickles »

alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

This frustrates me as well.

It's not just limited to the Culture of Architecture, a bunch of concepts in software seem to have similar issues (MVC vs MVVC, REST, etc). Unlike a bunch of other disciplines, there is a distinct lack of thought into what should be applied for each application problem. Electronics textbooks generally mention that a circuit is best for a specific set of applications, and talk about some of the limitations of applying the circuit (eg: very accurate voltage regulation, but does not tolerate fluctuations in temperature).

Re: Analysis of Software Architectures

#15

Post by cbd1984 »

alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

OK, help me understand:

Is there any difference between CoA and design patterns? Sure, "Broker topology" is probably trivial, but so's Chain Of Responsibility and Decorators and everything else the Gang of Four touches on.

So, are you just as opposed to design patterns as CoA?

Re: Analysis of Software Architectures

#16

Post by lotyrin »

kisstheblade wrote: post #10

Regarding microservices. They sound nice in theory, and certainly work for some cases. But what is the common pattern to handle a situation like this (in a performant and "scalable" way). Say you have two (completely separate micro-) services: - Order service - Customer service Now when a customer buys something, it is stored in the order service. But how is the customer information referenced in the order service? D…

The cross-service join problem is definitely a weak point of microservices. Generally you'd try to avoid designing service boundaries that you plan to do joins or transactions, etc. across. If you do need joins/transactions though, it's not impossible to coordinate them across services.

Your reporting feature that wants to provide a sortable list of orders+customer information, whether it lives in the order or customer services or in its own, would have to collect order information including customer ids, then use those ids to collect customer information, join these together in a working area of some kind if they're large (in-memory cache as you've mentioned is a decent candidate) and sort/filter that as needed. A cache + invalidation strategy appropriate to the application could definitely be needed for acceptable performance.

Depending on the characteristics of the team: size, planning style, communication style, etc. the cost of having to solve cases like these can be well worth paying to have smaller projects which can be reviewed easier with clearer ownership responsibility etc. Sometimes the tradeoff is a dramatic win and these are where the microservices advocates come from.

Everything is trade-offs. With billions of humans, the worst design pattern/methodology/technology you can think of still probably has an appropriate application somewhere.

Re: Analysis of Software Architectures

#17

Post by geodel »

userbinator wrote: post #5

As someone who worked briefly on "enterprise" software (in Java), this article brings back memories of preposterously complex and uncomfortably bureaucratic monster-systems that were a nightmare to work on. It also reminds me of http://www.joelonsoftware.com/articles/fog0000000018.html

Good for you. I keep working more or less on similar kind of systems where an 2 line change in a method turns out 20 code + 5 config file change.

Re: Analysis of Software Architectures

#18

Post by kisstheblade »

lotyrin wrote: post #16
kisstheblade wrote: post #10

Regarding microservices. They sound nice in theory, and certainly work for some cases. But what is the common pattern to handle a situation like this (in a performant and "scalable" way). Say you have two (completely separate micro-) services: - Order service - Customer service Now when a customer buys something, it is stored in the order service. But how is the customer information referenced in the order service? D…

The cross-service join problem is definitely a weak point of microservices. Generally you'd try to avoid designing service boundaries that you plan to do joins or transactions, etc. across. If you do need joins/transactions though, it's not impossible to coordinate them across services. Your reporting feature that wants to provide a sortable list of orders+customer information, whether it lives in the order or custom…

Agreed.

Usually it's always the "user" object which cuts across services. Was wondering if there is some common pattern for handling this.

For the scenario I outlined here some kind of "third service" / aggregated view of the data could also be a solution. Ie. store the data needed for queries in some queryable datastore (nosql, sql; pull the info from the needed services and refresh the view when needed)

Re: Analysis of Software Architectures

#19

Post by perlgeek »

kisstheblade wrote: post #10

Regarding microservices. They sound nice in theory, and certainly work for some cases. But what is the common pattern to handle a situation like this (in a performant and "scalable" way). Say you have two (completely separate micro-) services: - Order service - Customer service Now when a customer buys something, it is stored in the order service. But how is the customer information referenced in the order service? D…

Denormalization is often a practical answer; the order service keeps an (immutable) copy of the customer's name and delivery address.

If the customer changes the address, it will only matter for new orders.

One can argue that this is actually a sensible behavior, because there's a point after which you can't change the delivery address anyway (once it has been handed over to the delivery service, for example), and this behavior of copying the address just moves the point a bit.

Likewise, when a customer buys a product, a copy of the product description and price is included in the order; if the price changes between the checkout and the delivery, it's good if that isn't reflect in the amount that is invoiced. After all, the checkout established a contract that cannot be easily changed retroactively.

Re: Analysis of Software Architectures

#20

Post by perlgeek »

skrebbel wrote: post #13
alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

I violently agree, and I suspect most of HN does. There's an associated danger though: I find that many startup hackers actively dismiss good ideas (and even entire programming languages) simply because they smell a bit of CoA. Even the CoA crowd occasionally comes up with truly good ideas that have way more substance to them than the meaningless patterns mentioned in this article. As an example: My personal pet peev…

> As an example: My personal pet peeve is the startup world's ignorance of Domain-Driven Design and CQRS (Command-Query Responsibility Segregation). If you want to make scalable backends, I really recommend you read up on CQRS, it's practical and it fits modern ideas. Most examples are in C#, but you'll survive.

Most starts never become successful enough to have to worry about scalability; in fact, if they do, it's almost a luxury.

I don't have experience with CQRS and event sourcing, but it does seem to come with its own share of problems, for example dealing with changes of the data model, which I suspect would happen often in young businesses.

Post reply on HN