Back to building monolith applications?
Most experienced engineers would likely recommend implementing microservices, APIs, and serverless architectures in the current technology landscape. And not dare to talk about building a monolith solution. But this is what one Amazon Prime Video team did because of too high infrastructure costs and scaling bottlenecks. By ditching serverless, microservices, and AWS Lambda, they saved 90% of their infrastructure costs and solved their performance issues. Read the full story here.
Implementing the latest infrastructure and development concepts for the sake of it does not necessarily bring the best solutions. It's like pushing database normalization to the extreme, to the detriment of performance. Denormalization is often necessary.
Every case is different when building an [new] IT solution and comes with other requirements. Different IT architectures will have various pros and cons, and no solutions will be perfect. You must challenge your team to think out of the box, assessing "modern" ways of doing things while not excluding traditional ones. You must also recognize the existing IT landscape and technical debt because it's not like you can erase everything and start from scratch. If necessary, build a minimum viable product to prove your proposed architecture is scalable and delivers the required performance.
Project Portfolio Manager at UBS
4 个月The right tool for the right problem. Every case is different. It's always like that.
I am not sure we are back to building monolith applications. Some of the core banking monsters in the banking industry deserve a fair amount of re-engineering and a key element of a cleanup strategy is to divide (the complexity) to reign and establish well designed interfaces (read software contracts) between the functional components of a complex system. I think the author of the Amazon Prime post is realizing that cost efficient cloud based software development include a new dimension software developers never faced before: cost optimization. And that's something the usual finance teams are helpless with, since reducing cost is achieved with a re-platforming effort (usually costly in itself) to be cost efficient: It is not a financial engineering exercise, it is an engineering exercise. When asked about the cloud i have a invariable answer: Way more flexible, but do not think it is going to be cheaper. Cloud cost optimization has a significant impact on how we design software. The naive lift and shift strategy we often see lead to cost explosions, particularly in microservice based architectures with implementation assuming all services can stay up 100% of the time.