A microservice is a tightly scoped, strongly encapsulated, loosely coupled, independently deployable and independently scalable application component. Microservice architecture (MSA) is a design paradigm, based on a combination of SOA and domain-driven design (DDD), that enables ability and scalability.The important part is 'independently deployable and independently scalable application component' Its the backend implementation that makes a micro service not the interface or how its exposed.John-
The flexibility and modularity of microservices are what make them so appealing. They may be installed in containers, such as Docker, making scaling and management a breeze. Furthermore, it is an excellent fit for contemporary DevOps practises, allowing for a more agile development process. These services may be independently designed, deployed, and maintained, which is a game changer for developers.
It's fun to have these kind of discussions in TM Forum!
I don't think TM Forum should take side in the monolith vs microservices debate. both approaches have merits and problems.Recently Amazon Video have shown that they regretted their move to microservices and have reverted to a "monolith".And many OSS and BSS vendors, members of TM Forum, still use a monolith while some have adopted micro services.
One of the ODA guides says that what matters most is that business capabilities are exposed via API. We are here to help businesses and their customers.
To be fair, Matthieu, there is an implication, if not explicitly stated, that an ODA component will likely be implemented as a microservice (or a coherent collection thereof). The ODA technical architecture (such as deployment within K8s, event based communications, etc.) "smells" like microservices :) .
I agree with Matthieu.
Microservice is an architecture style.
Let us consider that if Mr.A and myself are into telecom provider business and have everything same(business type, business drivers, resources, budget, etc - assuming everything is same) then too our earnings/revenue/output/valuation may not be the same - reason being the implementation of the resources(human resources, tools, investments, etc). Similarly, implementation of Microservices is not a silver bullet!!!! It may benefit your business but sometimes it may not or migrating from Monolithic to Microservices may not give you good ROI.
Microservices, typically have few features to follow, again it depends on your implementation whether you want to go strictly by books or tailor them to match your needs to harvest maximum ROI. Let us discuss few of the features : 1. Single Responsibility - The service must implement single functionality/business sub domain ( Eg: Financial Transaction on a customer account / Issuing provisioning commands to customer device/etc). 2. Your application / microservice must be resilient - Facing an exception and not returning the desired response/output is not a microservice feature, instead, it must be capable to handle such situations. 3. Various Microservice design patterns implementations - use the different patterns for your microservice. 4. Database - Single responsibility database, if you go by books :) , database schema based microservices also work fine.
Best possible way out is understand your existing Architecture Landscape and then decide on the architecture type for implementation of ODA component / any new component in your Architecture Landscape.
To answer the original question - SOA, use of ESB, API management using tools like APIGEE/SwaggerHub/etc are again ways with which you manage your Architecture Landscape and now you have Microservices added to this list - hope the details furnished helps.