logoalt Hacker News

threethirtytwolast Sunday at 1:21 AM2 repliesview on HN

Yeah. that's a bad thing right? Maintaining backward compatibility to the end of time in the name of safety.

I'm not saying monoliths are better then microservices.

I'm saying for THIS specific issue, you will not need to even think about API compatibility with monoliths. It's a concept you can throw out the window because type checkers and integration tests catch this FOR YOU automatically and the single deployment insures that the compatibility will never break.

If you choose monoliths you are CHOOSING for this convenience, if you choose microservices you are CHOOSING the possibility for things to break and AWS chose this and chose to introduce a backwards compatibility restriction to deal with this problem.

I use "choose" loosely here. More likely AWS ppl just didn't think about this problem at the time. It's not obvious... or they had other requirements that necessitated microservices... The point is, this problem in essence is a logical consequence of the choice.


Replies

procaryotelast Sunday at 8:27 AM

> or they had other requirements that necessitated microservices

Scale

Both in people, and in "how do we make this service handle the load". A monolith is easy if you have few developers and not a lot of load.

With more developers it gets hard as they start affecting eachother across this monolith.

With more load it gets difficult as the usage profile of a backend server becomes very varied and performance issues hard to even find. What looks like a performance loss in one area might just be another unrelated part of the monolith eating your resources,

show 1 reply
Seattle3503last Sunday at 8:36 AM

> Yeah. that's a bad thing right? Maintaining backward compatibility to the end of time in the name of safety.

This this is what I don't get about some comments in this thread. Choosing internal backwards compatibility for services managed by a team of three engineers doesn't make a lot of sense to me. You (should) have the organizational agility to make big changes quickly, not a lot of consensus building should be required.

For the S3 APIs? Sure, maintaining backwards compatibility on those makes sense.

show 1 reply