Exactly. Where I work, we've explicitly chosen to "choose boring technology" in the parts of our stack that aren't key differentiators in our product. The ide

Exactly. Where I work, we've explicitly chosen to "choose boring technology" in the parts of our stack that aren't key differentiators in our product. The idea goes back to the concept of "best practices" being essentially "what everybody else does," which essentially means "good enough, unless it's something that needs to be better than good enough." In essence, this has lead us to a philosophy that's very close to (but not quite) "AWS is our architecture 'standard library.'" We also define "boring technology" a little differently than the post does, I think. Basically, we think of it as "stuff that isn't going to page me in the middle of the night and wake me up." For us, because we're already on AWS, that tends to be AWS managed services, except for the services that directly provide functionality to our product, which we run containerized on EC2. Essentially, our comparison between AWS managed services and running some other service ourselves to meet the same need comes down to cost. If it costs less than about 3 engineers' salaries to run the AWS service, we're happy to hand off the pagers to them rather than wake up our engineers when those services get unhappy. We also apply this philosophy to our custom services. Right now, we have a monolithic web app that runs on Python + Flask + SQLAlchemy. So, by default, any new services run on Python + Flask + SQLAlchemy. Not FastAPI, not Django, not Rails and definitely not node.js. Python + Flask + PostgreSQL + SQLAlchemy, unless you have a convincing case for running something else. Not only is this extremely boring technology (Python has been around for ~30 years; Flask 12 years; SQLAlchemy 16 years; and Postgres -- who cares, we use it via RDS and let Amazon manage it), but we won't have to try and hire people who know Scala, for instance. We're also not above stealing large portions of our architecture, when appropriate. One good example is that we've essentially lifted the auth system for our new API from an example in one of the AWS blog posts. It works. We know we won't have to worry about it in the future. It's boring, and not a core feature of our product, so we don't want to have to care much about it. None of this isn't to say we don't have a lot of exciting stuff going on inside our product. We do. It's just that we have deliberately chosen for our non-core functionality to be boring and run on boring technology that's mostly managed by other people. I guess that's a little like us choosing to spend our "innovation tokens" wisely.