The so-called "right tool" is also considerably more expensive on AWS. We let our actual needs mandate the tools we use. We don't play the game of gold-plating our tools because we might need it someday. Also, migrating data from MongoDB to PostgreSQL is trivial. Since our architecture mandates that clients access data via APIs then the clients aren't affected by the change.
> The so-called "right tool" is also considerably more expensive on AWS.
I am currently in the process of reducing out AWS service coverage. I'm not sure if I've phrased that right, but reducing the amount of scalable services that they suggest and offer and that were promoted to the company I work for.
It's a numbers game, if you are serving a lot of clients, or processing a lot of things, AWS is fine, next question is, what is a lot?
All things are relative to workloads of course, but lets say you're serving 1 million requests a day, not concurrent, but overall, if you have an API gateway tied to aws lambda or step functions etc. Okay, I can understand you might want to scale up some of the 'workload' services.
Out of those 1 million requests, it's worth a companies time to take the step to evaluate, "Hey we have a contract with AWS, maybe a fixed price contract, but do we need it ?"
Fast forward after you realize maybe 10%~ lets say can be left as 'scalable' because they're CPU intesive or they could be consolidated to be a single 'microservice'. Great, now you have your scalable workload, the rest can be thrown on a single server..
> Since our architecture mandates that clients access data via APIs then the clients aren't affected by the change.
Architecture by definition should be forward stable. It shouldn't mandate anything, it should just facilitate the requirement. How you implement it isn't an architects concern (in theory).
AWS kind of makes a lot of tech debt here that is hard to justify to the people above. Because they've already paid. So now as a software engineer, I found a ~40% saving possible, but it doesn't sound right.
I'm honestly getting to discouraged with things. The MAX client list we will ever look at I was told was max 500 people. Maybe 200 concurrent.
I was specifically talking about the pricing between DynamoDB and Aurora running the PostgreSQL engine. If DynamoDB satisfies your needs, then you should run it - because it is a lot cheaper! But, it's not an RDBMS. Sometimes you really do need an RDBMS. Like I said, starting off with DnyamoDB and migrating to PostgreSQL is simple - and your clients aren't affected so long as they were never directly accessing the data store. That was my point. Architecture is what allows you to make these kinds of changes to your system without impacting every other component comprising the system.
Generally-speaking, API based systems and interactions between components in the system, are very scalable. AWS facilitates the creation of such a system. Utilizing their serverless components essentially forces you to utilize best practices when building your system - which can be a benefit to teams, especially readl-world teams struggling with a bit of dysfunction.
