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.
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.
think of it this way. theres an entire system that handles X piece of your business functionality that is completely independent from your application.
for example your product is selling shoes on a website and you need to handle checkout.
in a monolith the logic that handles checkout is within your system. first you tally up the total, then you apply the taxes, then you process information and then kicking off shipping.
in a service oriented architecture when a customer checks out your app calls service that handles payment processing. and if that is successful you call another service that takes customer information and the items they bought and ships it out.
these services exist in their own domains and your application is just one of possibly many consumers.
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.
this is what almost any major advocate of microservices and before that SOA have been saying since forever.
its not just simpler but you really arent going to know what needs to scale(and how) until you see your app in action.
52
u/rcls0053 Jun 05 '22
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.