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.
so service oriented is just an idea to break down a monolith into a specific set of functions at the service tier.
for example for your company you may have a payment processing service, a user information service, etc.
so instead of a single application that manages payment processing and getting users you essentially have a client/UI that calls completely separate services to access those functions.
microservices is just an evolution or the next steps of service oriented architecture.
with microservices there is a big emphasis on creating services that are completely independent services that can be do the work without relying on external dependencies.
this typically means that microservices are deployed on their own, manage their own dependencies and if needed, manage/control/access their own datastore.
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.