Let me try to break this down from first principles, since I'm not sure I agree with the largely negative sentiment ITT around how complex this looks:
Most software projects are long lasting, and have unpredictable and constantly changing requirements.
Agile is currently the best software development methodology under these constraints.
Effective Agile teams should not be larger than 10 people total, minus the PO and Scrum Master leaves 8 devs.
Its not possible to run a large scale, high traffic web application with only 8 devs.
Therefore, it makes sense to split large applications up into chunks small enough for a 10 person team to manage autonomously.
Since the application had to be split up, we now have to solve the communication issue. Now we need networking, DNS, TLS, have to consider latency and bandwidth, etc... We also have other issues if we’re running at scale: redundancy, monitoring, separate environments for testing and production, having a local dev environment similar to the production environment. There is a huge list of things that are not important to for an early stage startup to think about, but are very important and very difficult for most large enterprises to get right if they want to consistently and reliably deliver good software.
Google is a large enterprise that operates large scale web services that has proven they know how to get this stuff right.
This repo is a reference architecture, from Google, on how to run micro services at scale using modern tools and methodologies. If you think this is over engineered I think you're just not the target audience, and something like Heroku is much better suited for your scale.
Most software projects are long lasting, and have unpredictable and constantly changing requirements.
Agile is currently the best software development methodology under these constraints.
Effective Agile teams should not be larger than 10 people total, minus the PO and Scrum Master leaves 8 devs.
Its not possible to run a large scale, high traffic web application with only 8 devs.
Therefore, it makes sense to split large applications up into chunks small enough for a 10 person team to manage autonomously.
Since the application had to be split up, we now have to solve the communication issue. Now we need networking, DNS, TLS, have to consider latency and bandwidth, etc... We also have other issues if we’re running at scale: redundancy, monitoring, separate environments for testing and production, having a local dev environment similar to the production environment. There is a huge list of things that are not important to for an early stage startup to think about, but are very important and very difficult for most large enterprises to get right if they want to consistently and reliably deliver good software.
Google is a large enterprise that operates large scale web services that has proven they know how to get this stuff right.
This repo is a reference architecture, from Google, on how to run micro services at scale using modern tools and methodologies. If you think this is over engineered I think you're just not the target audience, and something like Heroku is much better suited for your scale.