Microservices

On today’s blog entry we are going to talk about the Microservices architecture. This architecture has an approach where when we are developing a single app, we develop it as lots of small services, each of them running on its own process and communicating with each other with something that can bind them together. Now I have already used microservices without knowing I was actually using them, perhaps this architecture is quite intuitive for best practices or something like that, but anyway the author of the article gives some characteristics about this which are the following:

·         Componentization via Services: The components of the microservice need to be gather into libraries that will be used later on by the microservice to communicate with remote parts of the whole program.

·         Organized around Business Capabilities: This characteristic refers that we need to create divisions, each of the divisions need to be focused on the business capability which include various things like storage, interface, and many other stuff, now for this part the team developing this part needs to have different knowledge not only about programming, but also knowledge about project management, databases and obviously user interaction or experience.

·         Products not Projects The resultant software needs to be acknowledged not as another project, but as a potential product which characteristic can be used to improve the whole capability of the business than just a small part of it

·         Smart endpoints and dumb pipes: The endpoints should be for all the logic of receiving requests and applying it accordingly, and the pipes should be like small messages buses that behaves as a message router.

·         Decentralized Governance: This refers that the developers should use any tool at their disposal so the work can be done more faster and in form, but also they should probably code in any language so they can use those tools at their fullest so the system is not language based, but technology based.

·         Decentralized Data Management: the conceptual model of the world will differ between systems, so you should prefer letting each service manage its own database, either different instances of the same database technology (Polyglot Persistence).

·         Infrastructure Automation: automated test ad automate deployment.

·         Design for failure: Our software must tolerate the failure of the external services.

·         Evolutionary Design: Design software that is capable to evolve in the future.