If you start to thing of microservices architecture, the concept demonstrates the benefit of complex problems divided among many teams, participating toghether on one digital product. There is also a technical aspect, much more interesting to nature of our readers.
A a microservice must be deployable indepently of other microservices cooperating in one big microservices grid. The idea is to share power of teams on a single product through well defined interfaces and properly mantained services that talk to each other.
Microservices talk through contracts, the task of a team mantaining a microservice is to keep it up to date with demands, stable and highly available.
If we take a closer look at technical aspect, we can see a service with sort of IP port open for communication. REST is very popular concept for implementing contracts mentioned above. We all know REST API. But there are other protocols for communication among (micro)services, such as SOAP. Or very popular queues, such as Kafka.
The microservice itself could be a large complex project consisting of many modules. There are many ways how to implement contract of a microservice. Frameworks such as Java Spring help with technical aspect such as security, transaction control, automatic dependency injection, ORM and other technologies.
And then there is a task for you, as a developer, to handle and persist the information processed by the service. One of the design techniques is DDD, domain driven design.
Of course, finally there is a database. It is expected that a microservice will take care of its data. There are many options available now: SQL, NoSQL, Redis, to name few.
I hope you find this article interesting and helpful.
Top comments (0)