 Hello everybody. I'm Abhishek Sharma. I'm a full stack software engineer by heart who works as a solution consultant at infochips. I mostly work on providing cloud-based solutions and I've also worked on IoT-based platforms and also the DevOps part of it. In my previous organization I've also built back-end as a service platform, totally in Python, Django, Django Restroom work. So the topic for today is I'll be presenting my views on microservices and containerization. I know there are there has been a lot of talks on microservices so I have changed my slides a little bit so that we all get to know microservices better. I'll be covering the cultural side of how organization adapts microservices and things like that. So let's begin. So let's define what is microservices. Microservices is an architectural style I would say to build an application as a suit of small services which communicates with each other with a lightweight protocol. They run on its own process and each service communicates with each other through IPC mechanism. You can use any communication protocol like HTTP, RPC over MQP or Web socket and things like that to communicate between two processes or two services. So when I first explored, when I first read what the microservices is I was a little bit confused about how it is different from service-oriented architecture and I had the same expression. So defining, differentiating between the two, I realized that microservices architecture is a specialization of service-oriented architecture. So microservices takes all good parts of service-oriented architecture and is implemented in a different way. So you can see a slight microservices circle coming out slightly. So there is a sort of difference in approach in implementing microservices. So as the term micro suggests, it is significantly smaller as compared to service-oriented architecture where services are built at a very large scale. So if you compare two services from SOA and microservices, so in microservices, services are significantly smaller. They use lightweight protocols to communicate with each other. So in service-oriented architecture, I think you guys must have seen that there is some kind of a middleware we use to communicate between the services. So if that middleware goes down, your entire application goes down. So that is not the case in case of microservices. In microservices, services communicate with each other by defining their own protocols and the contract they agreed upon. So with that definition of microservices, I have listed down the characteristics of what microservices should have. So if we look at it one by one, so it has to be minimal. So each microservices should adapt single function responsibility pattern. So let's say if you are writing an e-commerce website and if there is a payment service, so that service should only be dealing with the payment part. Other services should... It's okay for other services to not know the underlying implementation, how payment is processed and things like that. So if one service is able to communicate with other services and it is able to get the response, it's okay. The second part is independently deployable. So as we are talking about distributed systems over here, so each individual services has to be independently deployable on our cloud instances. So not only that, I mean... So even the deployment strategy has to be independent from each other when we talk about service to service. So let's say if you are writing a web socket server, then maybe you have to choose the best... You can choose best deployment strategy for that particular service and maybe a simple authentication or authorization service, then you can maybe go ahead and choose the deployment strategy for that. So deployment strategy can differ from one service to another. The third part is configurable. So yes, of course, it has to be configurable because microservices are autonomous. So it should be able to self-govern itself and you have to use environment variables, file system mounts or maybe some sort of a service discovery or like key value pair store so that you can read the parameters dynamically and your service acts accordingly. The fourth part is replaceable portion. So whenever we write a service, we sometimes face problems like this service is not acting properly in terms of fulfilling the non-functional requirements. So we think of writing that service again maybe in using some different or better architecture. So your service should be kind of a plug and play nature. So if at all you are deploying a new version of your service, it should be completely replaceable and your system should work smooth. The fifth part is it should be organized around business capabilities. So I think we have already covered this because each functional areas of your business, your services should focus on the implementing those business capabilities. The next part is smart endpoints. So as microservices gives us lot of flexibility in terms of choosing our own protocols, how one service communicates to another. So it's good that we choose the best protocol and we define best endpoints so that service can communicate to each other very effectively. So it's not like it should always use HTTP and it should always use TCP or something like that. Choose your protocol wisely so that you get the best performance. The next part is elasticity. Elasticity in terms of scaling. So let's say if you are getting a lot of traffic onto your server, so your services and your infrastructure should be able to scale up and down based on the necessity. The next point is resilience. So I think microservices needs to be resilient in terms of like if there is a downtime for a particular service, it should not affect the other functionalities of your application. The next part is of course versioning as we'll be developing our services in a very iterative way. So one should keep their deployment strategies and development cycle according to the versioning. So it should be able to adapt this point. So infrastructure automation, yes. So as microservices we'll be dealing with as we are dealing with distributed system and it has to be monitored always. So whenever there is a high traffic, so it should be able to scale up and down. So your infrastructure, you have to decide your infrastructure in such a way that it should allow automatically scaling up and down based on the traffic that you are facing. Centralised logging and monitoring. I've seen people taking this part as an afterthought. They generally don't care about this portion, centralised logging and monitoring and they end up facing a lot of issues when they see downtime of a particular service because they'll not be able to figure out what's happening wrong. So you should have a centralised dashboard kind of a thing or something where you can look all the logs and monitoring stuff and things like that. The next part is encapsulation. Your service should have all the components that are required to run that service effectively. So it should not be, it's like, if let's say one service requires RDBMS, so it should have all the components near to the service so that they can talk to each other very effectively. And of course it has to be stateless. So let's quickly go through what are the advantages of microservices over monolithic architecture. The first point is microservices relies on each other public API. So I've seen couple of times that in service-oriented architecture, most of the developers directly communicate with the database of other services and things like that. So that should not be the case in terms of microservices as we are going to deploy our services independently. So it has to communicate with the wrapper or the APIs that you built around it. The second part is decentralisation and no single point of failure. So we have already discussed that in service-oriented architecture there is a concept of middleware which always runs in between so that service can talk to each other effectively. So if that middleware goes down, so that becomes a single point of failure in terms of service-oriented architecture. So in microservices, it is not the case. Everything is decentralised and each service talks to each other with the best effective way. The third point is right tool for the right job. So with microservices, we get a freedom of choosing the technology stack, technology or I would say a language. The best language you can write your services in. So we can write one services in Python or another in Node.js and things like that. So you get the freedom and you get the flexibility of choosing right tool for the right job. The next thing is polyglot persistence. So this is kind of like if, let's say, one microservices requires RDBMS, you can go ahead and use any SQL database and let's say if another service is dealing with, let's say, for example, time series data, so maybe you can then think of choosing the database accordingly and maybe you can go ahead with no SQL database and database of that sort. Single responsibility, as we already discussed, it should be focused more on one aspect of the business requirement. I mean, one aspect of it. The scalability part, yes, so each service should be developed in a way so that we can scale it up very smoothly. So even if, let's say, we are upgrading it, so we should be able to upgrade those services smoothly and things like that. The next one is decoupled. So microservices should, I mean, the components in the microservices should be loosely coupled and highly cohesive. So you should develop your microservices in a way so that you can decouple all the components that are there in the services and let them talk to each other based on the requirement. The next part is bounded context. It's okay for one services to not know the underlying implementation of the other. So that is what bounded context means. So the next point is more towards cultural side, like end-to-end ownership. So with the normal software development lifecycle, we have seen that projects start from requirement analysis and then it moves toward design and then development. And sooner or later it goes to support and maintenance. So that is not the case. There is a slight difference here. One team owns the entire service development lifecycle over here and they completely own it. And independent governance as well so that they can, because microservices, microservices has to be autonomous. So it should have all the components that can help us track the monitoring metrics and things like that. So let's move on to how can you write microservices in Python. So when I heard about it, I just Googled it out saying like this, what is the best framework to write microservices in Python. So the first thing that I get is about Namaiko, which says that it is a Python framework for building microservices. So we'll not go into the documentation of it. I have listed down some of the features that it supports. You can install Namaiko with simple pip install Namaiko. The supported protocols through which one service can communicate with each other. So it supports these many. You can go ahead and use simple STTP and Git and Post. You can do communication over RPC, MQP. You can do PubSub, WebSocket. And it also provides WebSocket support. So there are other features as well. So it has a support for unit testing and I guess integration testing as well. So this is a very feature rich framework as far as microservices is concerned. So I think this is good. But as we all know that microservices, it has to be relatively small. We have already seen the minimal point of it. So it's not a constraint that you have to use. You have to always use this framework. So let's say your services only requires STTP endpoints and things like that. You can go ahead and use Flask. So that is the kind of freedom that we get when we build microservices. So you can use Flask and let's say if you are dealing with Async or you can maybe go ahead and use Django channels or Scenic. I guess there was a talk about it in micros and the Europe Python. So you can choose your frameworks based on your requirement. So let's see how our services packaged and deployed. So deployment plays a crucial part when we talk about microservices. So these are the options that I have listed. This first one is traditional like how we used to do in the monolithic. We used to create a script that will SSH to our remote machine and it will check out all our code and then it will try to execute our script. But that becomes really difficult when we talk about discrete environment because microservices has to run in discrete environment. So we are left with the other two options like virtualization and containerization. You can go ahead and use virtualization but it becomes quite bulky because it holds the entire OS. So there will be a guest OS running in your VM boxes so it becomes quite bulky. So the next thing is containerization which uses Linux kernel capabilities. Docker container has this lib container execution environment which directly talks with Linux kernel components. So you can go ahead and use so that the image size becomes very, very small and comparatively it becomes much lightweight than hypervisor or VM and things like that. So I will put this question for you guys like if Docker provides the isolation, so do you really need virtual ENV? So I mean we all know that what virtual ENV is for. It provides good sort of isolation when we talk about Python libraries and things like that. But here we are dealing with Docker which provides separate root FS. So it's okay if you don't use virtual ENV. It's not mandatory but I guess there's no additional text involved as well. So you can go ahead and use virtual ENV. So it's up to you guys whether you want to use it or not. Let's move on to how to containerize Python-based services with Docker. So there are four steps. This is a simple Flask app which so on the root it will just return the string Dockerizing Flask app and it will start our server on all the IP addresses on our local instances. So these are the four steps I have listed down all the scripts over here. So you have to just create your Docker file. You have to say all the commands over there and once that is done you can build your Docker image with Docker build command and then you can run the Docker container using Docker run. And with the help of Docker PS iPhone A you will be able to see all the Docker container that are running or not running on a particular machine. So let's talk a little bit about how can we deal with continuous integration and continuous deployment approach in microservices and containerization. So this is with respect to Jenkins but I guess you can also use GitLab CI runners and Circle CI to automate this but this covers Jenkins part of it. So let's say when our developer pushes any change to the Git repository with the help of Webhook Jenkins triggers a build. So Jenkins uses Docker to build an image based on Docker file. So once the your container is up and running you can maybe run all the test cases and if let's say test if all the test cases are passed then maybe you can push your Docker image to the Docker registry and you can inform all the instances that are running that image to pull the latest version of it. So the next slide is about like when to use microservices. So I would say don't go with the flow like every big big big companies are using microservices. So just don't choose your architecture just by the latest architecture style pattern and technology. So I would say if decentralization is identified and very inception of your project so maybe you can think of writing microservices and maybe if like you are doing a very CPU intensive operation like if you are maybe doing image processing and video encoding or decoding and machine learning and maybe artificial intelligence. So that case it might be helpful because you might really need to scale those portions the heavy intensive operation portion in future whenever you face a lot of traffic. So I think that is the area I can maybe think of when you can choose to go with choosing your architecture as a microservices architecture. So I have talked with most of the developers who are using microservices. These are the common mistakes they do when they use microservices. Like in SOA we generally talk with the database directly. So they use shared database instead of talking through public API they go ahead and directly do the queries to the database. So this is the one mistake that I have seen that people generally do. The second thing is they consider HTTP is the only protocol to communicate between services. Well that is not the fact though writing HTTP services is simpler and it's easy to get HTTP services up and running. But that doesn't mean that you should only go ahead with HTTP. Maybe a few services are meant to be together. So you don't need to do a round trip and do HTTP call. You can just go ahead and directly communicate with some sort of a TCP connection and things like that. The third one is people also end up writing their own service discovery. So this is in fact I've seen in like people write microservices for service discovery. So don't do that. There are the tools and technologies are very much advanced. When we talk about service discovery you can go ahead and use those tools directly. Don't reinvent the wheel forcing microservices where it's not required. So just don't go with the talks that all the big companies are using microservices that that's the only reason you have to use microservices. The next point is logging and monitoring as an afterthought. I have already discussed this. People generally take this as an afterthought and they end up facing a lot of troubles when you have to identify issues and you have to let's say see what are the monitoring statistics and metrics and things like that. One technology and framework everywhere. They end up choosing one language and one framework, one particular framework for writing all the services. So don't do that. I think there are you can choose language that is best suitable for writing that particular microservices. So I've seen people especially in Java they use Spring for writing all the HTTP services. So don't do that. There are micro frameworks available even in Java as well. We do have a lot in Python. So especially in case of Java I've seen people use a lot of bulky frameworks and they say that it's microservices. So the next is a tradeoff of using microservices. So these are some of the tradeoffs that I have identified. There are operations and tools cost that is involved. So you may end up dealing with a lot of tools at the very initial phase of your project. So there are a lot of cost involved in this. The second one is cultural cost. You might be your team or your organization might not adapt microservices very smoothly. So you have to maybe convince them. So there is a lot of cultural cost involved in that because generally what happens in an organization is there is one team for the entire product but here we'll be having different team for different services. So there's a sort of a cultural shift in that part. Distributed system complexity. So it's microservices is all about distributed system. So it has all the complexity with what we have in distributed systems. Interfaces should be well defined. So the documentation is must. So let's say if I'm working on a let's say we are working on an e-commerce website and I'm dealing with a payment service. So I should know I should tell what parameters am I expecting and things like that very clearly to the other teams so that they can communicate it accordingly and the transaction becomes much smooth. The next point is microservices DevOps first architectural style. So yes as it is as one of the characteristics of microservices is it has to be independently deployable. So I think DevOps thought process is required from the I think the very first day when we start approaching architecture in microservices way. And the other thing is team communication overhead is there. So you have you might be communicating a lot across the team about how are you going to communicate and things like that. So that's why I said the documentation is must so that you can do all your communication effectively and things like that. So yeah, thank you. Thank you. Are we check for this interesting talk? Are there questions? Okay. Thanks for the talk. Can you please elaborate a little bit more on the shared database issue? Like when is a problem even if there is replication between database could still be a problem that? Yes. So what people do is let's say if two services wants to share a particular database. So what they do is they directly fire and query to the database and get the results. So I think that is not effective when we think about scalability because database might end up becoming the root cause when we think of scalability because we'll be keep on scaling or microservices instances but the database will remain one. So in that perspective, it's good not to make database call directly use the API so that you are smooth when it when we talk about scalability and things like that. So that is what. So in case you say use API like the API of a microservice connected to the database? Yes. So it's not more or less the same? So with API you can have a load balancer in front of it and it can redirect to whatever service instances it can and then you can scale the database independently but in case of shared database you might not be able to do that very smoothly. So that is the point. Okay, thanks. More questions? Thank you for the talk. Are your slides available online? There are a few that were quite detailed and I wanted to pick them up later. Sorry, I didn't get... Are your slides available online? So I'll put it on my GitHub maybe so that you can look into it. All right, I see no more questions so let's thank Avishak again for the talk.