In the old days everything was monolithic, a program was entirely contained in the space of a single file.
In the microservice concept, software becomes the coordination of a myriad of small Web services that have one key feature: each is incredibly specialized in doing one thing.
Goodbye centralized database, goodbye complex authentication management, the main goal of this architecture is to break down the overall problem into a myriad of completely isolated subproblems. And when I say isolated I mean isolated in every possible way.
Not only must functionality be precisely delineated, but it is also critical to isolate the data itself by making sure that each service can control its own database.
But it is not enough, to call itself a web service, even the deployment itself must be isolated from everything else.
Absolute isolation in order to divide the complexity and create an incredible parallelism of work between development teams: each team engaged in the development of its own small microservice.
Some might argue that creating development parallelism would result in difficult coordination between the parties since Web services do not have unlike a ‘SOA architecture a document that guarantees interoperability. wrong! today many tools exist to create a perfect description of rest services and perhaps generate documentation and skeleton at the same time.
Want to go overboard? think what can be done with such magnificently isolated objects: Create small computers inside which a small webservice with its dbase lives in perfect autonomy.
Absolute isolation is not only logical but also physical.
But that is still not all. We are in the age of virtualization, and so today we may not limit ourselves to hardware isolation but opt for service virtualization in order to completely overcome physical limitations and forget about installations and configurations to create perfectly isolated and monstrously stable deployments.
Also isolated from the operating system
Top comments (0)