3 ms·

There's a big difference between over architecting something and not designing for growth at all. Ultimately conway's law is what drives your architecture, bec

There's a big difference between over architecting something and not designing for growth at all. Ultimately conway's law is what drives your architecture, because communication among people will always be reflected in the software. If you have a cohesive team that works well together, build a unified component. If you have people working independently, those should be separate services. It doesn't require a lot of architectural astronautics to do this. Whether one uses some kind of Docker platform or PaaS has more to do with whether you prefer doing your own undifferentiated heavy lifting with containers, schedulers, servers, networks, and storage... Or not.

merb 11y ago
> There's a big difference between over architecting something and not designing for growth at all. Mostly I agree with you, but there is no difference between over architecting and designing for growth. Okai some people will just do everything right from the beginning, but as long as we are humans, nobody will do it right. So mostly keeping things really simple is way better than having everything extremly loosly (so that you could change parts as you grow). Let's consider ForeignKeys as an example and / or Transaction. Having them keeps you going really really fast, but as you grow some of the Database needs to be splitted and so that ForeignKeys don't work anymore especially when you introduce the model that every service needs to have his own data service. Okai that example wasn't that good, but let's go further, it's way easier to have a transaction in a single application than when you need to have some kind of a transaction go over multiple microservices. Also take filesystem access for an example, if you just have a "few" different places where you do that you should do it. But that is not a good design for growth, but a design for keeping things simple, it's just not necessary to have some Kind of interfaces and file service abstractions just to have an easy way to replace that kind of stuff. Most things I'm writing is stuff that I learned over the past years, that some things work and some things not. Back to the topic, Docker is great, I already said that, but it doesn't fit in the use case of everybody. And still most things Docker trying to solve are already solved (like application deploying, or prod and dev should nearly be identical [whatever that means..] (vagrant)), still nobody has found a good solution in scaling simple SQL Databases, when running them on your own hardware. Edit: Fixed some spelling mistakes, god it's hard to write that late.

merb 11y ago

> There's a big difference between over architecting something and not designing for growth at all. Mostly I agree with you, but there is no difference between over architecting and designing for growth. Okai some people will just do everything right from the beginning, but as long as we are humans, nobody will do it right. So mostly keeping things really simple is way better than having everything extremly loosly (so that you could change parts as you grow). Let's consider ForeignKeys as an example and / or Transaction. Having them keeps you going really really fast, but as you grow some of the Database needs to be splitted and so that ForeignKeys don't work anymore especially when you introduce the model that every service needs to have his own data service. Okai that example wasn't that good, but let's go further, it's way easier to have a transaction in a single application than when you need to have some kind of a transaction go over multiple microservices. Also take filesystem access for an example, if you just have a "few" different places where you do that you should do it. But that is not a good design for growth, but a design for keeping things simple, it's just not necessary to have some Kind of interfaces and file service abstractions just to have an easy way to replace that kind of stuff. Most things I'm writing is stuff that I learned over the past years, that some things work and some things not. Back to the topic, Docker is great, I already said that, but it doesn't fit in the use case of everybody. And still most things Docker trying to solve are already solved (like application deploying, or prod and dev should nearly be identical [whatever that means..] (vagrant)), still nobody has found a good solution in scaling simple SQL Databases, when running them on your own hardware. Edit: Fixed some spelling mistakes, god it's hard to write that late.