> It’s interesting that there are folks who think there must be only one architecture to be the best in all cases. > To know this enough experience (both good

> It’s interesting that there are folks who think there must be only one architecture to be the best in all cases. > To know this enough experience (both good and bad) is needed with both microservices and monoliths. Over the years I have worked with a huge number of people who are looking for Silver Bullets and Best Practices, generally for one (or both) of these reasons: - To be blameless if the architecture doesn't work out (building with microservices is a Best Practice, it's not my fault it got very expensive) - To cut down on the number of deep-thinking decisions they have to make And to be fair on the second point, I don't necessarily disagree with the premise; if these kinds of decisions allow you to get going quicker, it's not necessarily the wrong choice at the moment. What everyone needs to keep in mind, though, is that if you don't do deep architectural thinking and planning at the start of a project (or even if you do sometimes...), you'll have to revisit it later. Often the same forces and pressures that led to taking shortcuts at the early architectural stages of a project will continue to be present down the road, and it'll be more work to fix it later than to do it right the first time. It's a tough balance. If there's a high risk that the project won't be alive in 6 months it probably doesn't matter. If it's a prototype that's very likely to get into and stay in production, then it really does matter.