Home Up Forward Leave Message


For this post I'm not going to concentrate on how microservices came into being or why it is a good approach (see the references at the bottom for some good coverage on these aspects). I'll give a high level explanation what it is and how one can go about implementing them at the basic level. The idea of this post is to see how one can implement microservices client and service side in various languages with different approaches with some practical examples. After the introduction I will firstly take a very basic example and implement it in various languages (Golang, PHP, Javascript, Java, Python, C, C++, C# and Guile/Scheme and other will be added as I get time to implement them) over HTTP then show how the example can be done via a comms framework like ZeroMQ. I will then go on and develop a basic and very naive banking system based on microservices but with the components done in various programming languages.

Overview

Monolithic applications can normally be seen as applications that reside in a single location with either multiple APIs or some sort of interfaces to the application (if you are lucky). This application was/is normally developed in one programming language that accesses one massive database in one location.

Clients (thick, web or other applications) then access this single application directly. If changes are made to the monolithic application then everything need to be recompiled and redeployed on the server. Scaling implies that the application must be replicated in its entirety at the various locations or instances on the same server.

Interfacing with the client from other applications can be daunting at times seeing that either you must be on the same operating system or you must use the same programming language or you must actually run in the same process space as the monolithic application. Features cannot be swapped in and out of an offering on the fly and automated deployment is normally extremely difficult (like in a containerized enivornment).




With Microservices the idea is rather to have multiple smaller applications that are focussed around specific business capabilities with services that can be accessed from other applications through communication mediums like HTTP, ZeroQ, RabbitMQ, etc. making use of encoding protocols like JSON, ProtocolBuffers, MessagePack etc.

Each component only providing focussed services, one can then combine these components to form an application (or rather offering) that does the same functions as the monolithic application. The differences is that components can be added and removed as necessary; they can be moved around and distributed as needed. They can be rebuild and started with less of a hassle than in the case of monolithic applications. Components can be done in various programming languages; clients don't run in the process space of the components and components can have their own databases where needed.

Now one can have for example a component that does all the master data around customers and suppliers. As new components are added to the solution they can just reference the customer/supplier component without redoing all of the functionality.

When the components are written well they can be re-purposed, distributed and extended based on customized configuration.




It must be noted that not only the clients but the various services communicate with each other directly. The focus is to have the intelligence within the end points and not the communication pipe as is the case in the Enterprise Service Bus. Obviously one would need to ensure that services have adequate authentication and authorization build to protect them against unwanted access. Please note that microservices must not be too fine grained else the work done in getting them connected and working together then get to be a major issue. So the idea would normally be to take one business area per microservice offering. It should also be mentioned that microservices is not necessarily the right solutions for each and every application out there. The tight coupling with in-process libraries can be a major advantage in for example scientific multiprocessing solutions.



Here is an example of a simplified solution around microservices using multiple programming languages of an extremely basic (naive) banking solution. We have some "core" functionality within each module (programmed in different languages) that can be accessed by the user interfaces as well as other "core" modules.




References: