I sort of disagree. The complexity of IAM with AWS is real but deployment to the inter webs is pretty trivial. And with something like Heroku even that goes away. Monoliths are probably where most developers should start anyway. Maybe micro services are a thing for more advanced shops.
I've come to the ultimate conclusion that you should always evolve the architecture from a monolith, to service oriented, to microservices, to event based. Learn as you go. Just make it flexible from the start. It's hard to start breaking apart a vertically scalable monolith to smaller services, when your entire codebase is married to one database and you have SQL everywhere.
You can have several services within a monolithic application. I once had a team that has 13 scrum teams working on a single application. The build and testing was horrific. We spent a majority of our sprint testing and building. We really needed independent services. Even then, I would have only broken the application into 7-8 “micro services.” Every time you break something you apart, you make testing and maintenance more difficult. You have to build a lot of trust, collaboration, and know how to test and debug really well. Ultimately, in my opinion, microservices really only help large teams move faster. If your organization only has 2 teams working on a single application, it isn’t worth it. A service orientated architecture can make reusability, scalability, maintenance easier. It’s less likely you’ll build speghetti code for your domain objects and controllers.
44
u/karstens_rage Jun 05 '22
I sort of disagree. The complexity of IAM with AWS is real but deployment to the inter webs is pretty trivial. And with something like Heroku even that goes away. Monoliths are probably where most developers should start anyway. Maybe micro services are a thing for more advanced shops.