 So the next talk is how to build a microservices using 0MQ and WSGI by Srinath GS. He's a head of engineering team at IDEA device building an orchestration platform for data center activities and application lifecycle management. Hi, hi everyone. I'm Srinath. I work at IDEA device as technical lead. We are building the next gen orchestration platform and we are trying to solve complicated use cases with cloud application lifecycle management. So in the process of building an orchestration engine, we stumbled upon a lot of patterns with microservices and we also started using 0MQ. And we ended up writing a framework which will serve as a bridge between 0MQ and the Python's standard WSGI protocol. So today I'm going to take you through all these topics. I think most of you would know about all of these things. So we'll see about what microservices are and what is 0MQ and how 0MQ helps us in building microservices and how to build restful microservices with 0MQ as well. And then we'll see a small real world example and then we'll also discuss about how Zadvisgi can be improved further. So what are microservices? Microservices is an architecture style where multiple independent processes communicate among each other. And each and every independent process does a well defined small subset of a particular big task which is supposed to be done. So microservices are the only way to scale your backend services as of now. And so given that it is so awesome that you can build a highly scalable web application or highly scalable any sort of application with microservices, there are some problems associated with it as well. So one of the main problems is service discovery and without knowing which endpoint to connect to and without knowing which endpoint to connect to to do a specific task, it becomes highly complicated for all the backend services to talk to each other. So that's problem number one. And given that all these microservices, all the processes talk to each other among a communication channel, so just having HTTP or just having a simple TCP server would not suffice. Because each and every task can be done by some microservice which might not be exposed out directly through some endpoint. So I'm talking about load balanced and service oriented architectures here when I'm talking about communication patterns and stuff. So why not just use HTTP and live with it. So one of the major problems with HTTP is that you need to know which port to connect to and you need to know you need so you can avoid the problem by having a load balancer. So probably that part of the problem can be solved. But then even before a particular process comes up, you cannot know where you should connect to. You wouldn't know where you should connect to. And always HTTP follows this request reply, request reply sort of a pattern where you send a request, you wait for a response after the response is given to you, you assume that the task is done. And one more process, one more problem that comes with HTTP is that you need to have a way to manage timeouts, retries, and if you have n number of workers, which worker can do what task and how can you allocate work among these workers as such. So that becomes a big problem. So here is where, here is where 0MQ would actually fit in and 0MQ helps us build, so 0MQ helps us build, distribute microservices which can be distributed amongst different machines in a data center or it can be in a single machine as well. It supports all sorts of communications, like basically it provides us sockets, right? So sockets which can be done, which comply with the TCP or which can be a Unix domain socket and 0MQ itself also gives us a lot of other features like in process communication and other stuff. So starting from version four, they have they have integrated with Libcurve, Curves ZMQ which is, which uses elliptical cryptography. So you can have, use 0MQ, you can have 0MQ bound on a public interface. So the security is also taken care of, right? So all this is fine, but why would you want to use a separate, you know, separate module which just gives us sockets but nothing else? Why would you want to use such a thing when I can build something on my own, right? But it's not just that 0MQ gives us only sockets, but it also gives us a variety of communication patterns to deal with and it also supports for, supports G event. So that way we can have optimal resource utilization when you're doing an IO call or when you're doing a wait for a particular process to come up and wait for a particular worker to be available or something like that. So if you use G event events, event based Qs and event based IO systems, so 0MQ also gives us a polar mechanism called green polar. So if you use all of these things, the application ends up using lesser amount of resources. So let's look at the 0MQ patterns. So first one is request reply. I think everyone knows about what request reply is, right? So request reply pattern is where you have n number of clients and any of the client can connect to the server and the server then sends a response back after doing a specific, you know, request or something like that. So this is one of the most used patterns even in today's world because even HTTP follows this lockstep mechanism where you send a request and then you wait for a response, right? All right. So, okay, the next pattern available is publish subscribe. So where you can have multiple publishers, you know, pushing data to one subscriber or you can have one publisher pushing data to many subscribers. And these subscribers can also have, can also subscribe to a specific topic, so to say. So the publisher can, when it is publishing, it can send events based on events pertaining to a specific topic. So the subscriber which has subscribed to a topic can get the request, right? So, okay. Next thing which 0MQ gives us is router dealer pattern. So in case of a router dealer pattern, what happens is that, so you have set of dealers connected to a router, right? So all these dealers when they're connecting to a router, so 0MQ also gives us this ability called 0MQ socket identity. So all the dealers in the, connected to the router can be addressed uniquely by using this socket identity, right? So when you want to send a request to a specific dealer, for example, if you want to send a specific request to D3, then the server code, the application code which is written in S1 can just send a request on the router socket with a specific identity which is equal to the dealer D3's identity, right? So then the dealer D3 will get the request and then it can then further process it. And you can build complex pipelining mechanisms using 0MQ by using this push pull mechanism. For example, you have a producer P1 which pushes to consumer C1 and then the consumer C1 in turn can push to an aggregator probably, right? So these are the different patterns available. So all right. So now we love 0MQ. 0MQ is cool. I want to use 0MQ, but I have my project written in Django or Pyramid or Flask or any other Python web framework. So I don't want to change a lot of my business logic. I want to do some minimalistic changes and I want to be able to run things using 0MQ. So which is where Python presents us with this nice thing called web server gateway interface. So where Whiskey stands for web server gateway interface and it is the Python standard for web applications. So what it does is web server gateway interface gives us two endpoints. One is the web server or the gateway side and the other one is the application or the framework side. So Python Whiskey has given us guidelines as to what all the gateway side should implement and what all the application side should implement. So we have these two interfaces. So now that we already are in the premise that I have written all my application code in Django or Pyramid or Flask, I don't want to change my code. So we can leave the application side of code as such. We don't have to change a lot of stuff in that. We can only change the server side of it. So by changing the server side, actually, our library's, does change only the server side of it. So that way we get the best of both worlds, so to say. So one of the awesome things with using a HTTP framework, a web framework like Django or Pyramid or anything of that sort, is that we don't have to write a complex function dispatch table. So if packet type is dispatched to this function, if parameter is dispatched to this function, if request method is dispatched to this function. So all of these things are handled thoroughly by the, during the routes configuration stage itself. So the function dispatch table is sort of, sort of in a way written in the routes, but we don't exactly write the function dispatch tables. So now we know we have zero MQ and we have a VisGi application. We want to make a bridge between them. So which is where Z VisGi will come and Z VisGi is open source. You can access it at github.com slash idea device slash Z VisGi. So it helps us to write restful APIs with zero MQ. It adheres to the VisGi protocol and we get all, we get the best of both worlds, right? All right. So this is okay. So now when we talk about real world scenarios, real world scenarios, we have, you know, we have n number of clients and all the clients, let's say they want to make a specific task, right? They want the server, you're back in to do a specific task. And thus that specific task can be split into n number of small tasks. For example, in the URL that is given, so rfc.zeroMQ.org slash spec colon seven. So it describes the major demo protocol, MDP, where, where, you know, the clients ask for make, to make, clients ask the server to make tea, right? Tea requires water, milk and tea obviously, right? Tea powder. So, so you have a set of workers assigned, one assigned for doing a specific task. So now the central dispatcher can then dispatch, split the work into smaller items and then it can dispatch it to different workers and then get the consolidated output and return back to the client, right? So that is one model. That's, that's probably one model of one way of doing it. We can also have an asynchronous way of execution where we send, we send a request to central dispatcher and then the central dispatcher says that it will be done when, when it's going to be done. And then, and then it can then dispatch the work to all the other workers that are available, right? So, so this protocol in short is called as major demo protocol and major demo protocol in, it also has further other specifications laid out. For example, heartbeats and heartbeats and, and all the URL schemes and everything else associated with it, right? All right. So, before that, so, okay, so this is one of the product that we are building right now, right? So this can bring up, bring up all these nodes and it can automatically figure out all the dependency, dependencies and it can orchestrate. It can basically realize this given graph to, to orchestrate by orchestrating specific parts of it and it can figure out which parts need to be done parallely and which part needs to be done serially and all. And then finally you will get a, get a sentry cluster, you will get a Postgres database and you would have Redis sitting on Docker and, and HAProxy separately, right? So, so all of this is done by using ZWisGi and in, in ZWisGi also we, we have, we have implemented the complete major demo protocol on our own, right? It will take some time for running. So, okay, what is the road ahead for ZWisGi as such, right? So, using ZWisGi, we can probably build an enterprise message bus. We can do queuing and we can throttle all the requests. We can come up with some HS strategies or normally also when you have microservices, you would want some admin channel where you can introspe, where you can go and inspect all the processes that are there in your cluster. And, and with ZeroMQ we also get to this problem where we don't have a direct way to talk to ZeroMQ, you need a gateway, you need a HTTP to ZeroMQ gateway. And we can also have certain client libraries like for doing get, post all, and broadcast and all those requests probably it can be based out of the request library itself. Request library allows us to change the transport layer. So, and also though we have an implementation where we have hard bits and worker management done, we are ready to open source the hard bit management, hard bit and worker management for, for the outside world. All right, this has started, right? There is some approval pending. I did not think of this. The alignment is slightly, yeah. So, so it has brought up Docker host, it has installed HAProxy on it, and it is bringing up all these other components on the same Docker host. So, in a way, we also help build microservices. All right. So, so I'm done. So do you have any questions? Hey, great talk. Thanks for that. Potentially the question is like ZeroMQ exposes a Python API as such. Yes. So, bindings are available for almost all languages. There are bindings available for go, there are bindings available for, so for .NET they rewrote the complete ZeroMQ code. And for Python we have PyZeroMQ. So PyZeroMQ does not allow you to accept requests like HTTP requests, right? So you don't have a facility to have URLs and you don't have this HTTP spec as such implemented in PyZeroMQ. Okay. So typically the scenario that I'm talking about is like we are having a storage solution. Okay. And let's say we have Samba configured in that. So whenever I make some changes, I want the Samba servers to restart basically. Okay. So how we typically approach to this, like we use the Python ZeroMQ APIs. And then instead of restarting the service through Django application, basically Django hangs off once you do any service restarts. So we span out a ZeroMQ microservice through the APIs and it just does the job. So why a whiskey again? I don't really need a HTTP to directly go to. So it depends on your application, right? So what, what necessarily is that, see, in your case you have built all the microservices which talk over HTTP, but they don't talk over ZeroMQ. They're not taking advantage of the ZeroMQ patterns that are available. For example, RouterDiller is such a powerful pattern that you don't have to know the IP address of the, of IP address or the port that is there in the, that, that is going to be there in, it can be there either in your machine or it can be there in any other machine. But you can allocate tasks to that. Given that ZeroMQ has such very powerful patterns in it, right? So you're, so by just having a HTTP based microservice architecture, you're not utilizing the complete potential of ZeroMQ, right? Any questions? Hello. Yeah. Great talk. Thanks. ZeroMQ as far as I understand it is broker less, right? Could you compare and contrast maybe like the difference between with broker versus broker less and maybe some use cases where, where it would fit. All right. All right. So ZeroMQ by itself it does not dictate whether you need a broker or not, right? But you can end up with configuration. For example, this major Domoprotocol involved a central dispatcher, which sort of is a broker, which sort of is a proxy between all the back end processes to the, to the clients, right? So, so you can arrive at a point where you have brokers in your architecture, you can arrive at a point where you don't have brokers with your, with your architecture. So, so if you don't have brokers, it becomes very difficult for you to, you know, identify all the end points where you have to do, where you have to connect to, right? But if you have a broker, it's just a single endpoint for you, right? So, so these are sort of the trade-offs between having a broker and not having a broker. But one of the major downsides of having a broker would mean that if that broker goes down, then you, then all your other processes would be rendered unreachable, right? Hi. This is not about ZeroMQ, but in general in microservices, how do you handle authentication between services? Authentication between services. So, so authentication between services can be done by either, if all, all of your microservices have to have some authentication, then you can come up with your internal component level authentication mechanism. That's one way to do it. Or you can use whatever authentication mechanism that you use for your external, external components. For example, user, user authentication or anything. So, as such, you can use. So, something like JSON WebToken, JWT. You can use anything that you would want to, right? Thanks. Any questions? Any more questions? Okay. Thanks enough. Yeah, thanks.