A small piece software that can to be easily managed by 5 or less members team is a Micro service. The essence of Micro services is smaller team size because it is lesser overhead to manage, faster to execute ideas, and easier to communicate. Hence Micro service is as much as a culture as it is a architecture idea. Micro services can be independently developed, deployed, scaled, and deprecated. Speed, and safety are the main attributes that differentiates micro services from monolithic software systems.
Micro services enable independently develop, deploy, scale, and deprecate software systems.
What’s missing in existing systems?
Traditionally softwares systems are monolithic systems that are huge in size (code base), and complex in features (functionalities). They are managed by sub dividing into smaller modules. However, since they are built into the same system (developed and deployed together) they are techically tightly coupled. Both development and maintenance efforts are affected by this tight coupling since problems can percolate to other modules easily. So many software projects are delayed and/or dropped dead because of these bottle necks.
Micro servies on the other hand are ingeniously modeled to reduce tight-coupling just so applications can succeed or fail independently. This reduces ‘time to market’ and establishes closer feedback loop with stake holders. Micro services shifts the non-essential complexity from software development teams to dev operations. You should consider micro services only if you are able to automate Devops.
Following Agile lean practices of delivery, micro services can cater to domain or sub-domain specific services. To process a online order, Product micro service can integrate with Quote, Order, Payments, and Fulfillment services independently.
Fundamentally you can take this big chunk size application and sub divide into various smaller pieces so they are easily manageable. From a managers perspective, being independent means less hassle of managing. From Leads perspective, focused work on a particular domain and more chances of innovation. From developers perspective, use whatever technology you like to use for this micro service and being agnostic of vendor. I have seen some teams use N-Unit testing framework and other MSTest between teams in same organization. Some of them used TeamCity for continuous integration or TFS for gated check-ins.
As long as your micro service provisions versioning and you are able to deploy independently, it help teams be more productive by reducing ‘time to market’, and creates a closer feedback loop with the customer. It really scares higher-ups if new changes are breaking apart existing functionality.
By scaling independently, micro services can cater to high traffic volume for a specific business domain. This is both cost effective, and the safest way to provision large number of requests without eating away into each other resources. There is no way that Fulfillment domain should be going down because of higher volume for Order domain. Orders processing service can be scaled higher, and Fulfillment system can provision the Orders at its own pace. In a monolithic system, increased traffic to order processing system could bring down Fulfillment system by eating away complete server resources.
Failing to learn from failure is the real failure.
Since micro services are so tiny that they can be easily scrapped and replaced. Lots of time companies come up with new applications that are useless due to regulatory or policy changes. Change or shutdown obsolete software components businesses can save money in terms of resource utilization. Since it is easy to replace a service, it is also easier to upgrade a micro service.