 Good evening everybody. How are you guys doing? After office, 8 hours in the meet-up. Guys, we are going to learn a lot of things today. Because I understand after working for 8 hours, came here in the meet-ups to learn something new. I think one more talk is here. I am going to talk about building micro-services with KOLANG and how we will manage our micro-services with MISOS. So, first let me introduce myself. I don't have any slide for myself. I am going to tell. Myself is Freve. I came from India. This is my social identity. I run 3 technical communities in Delhi. For Ruby, Golang and Cloud Foundry. Because I personally believe community and meet-ups are a good place to share our knowledge and learn from people. What industries and what expert people are working on and where this complete industry is moving on. To keep ourselves up to date, what new tool technology I am using, what others are using, so it is a good place. I was also one of the organizers of the first Govac on India in 2014-15. This is my social visit. So, thoughts of meeting local Goffers or meeting people. So, I started looking at the meet-up groups in Singapore. So, I contacted with Dan. So, I really thank Dan for giving this opportunity and platform to meeting with you all. So, without spending any more time, let me start my talk. So, I am going to cover what are the pain points of running monolith and layered application. And this pain point could be solved with micro-services. When we are building micro-services, then Go is one of the best languages that I feel fit for writing micro-services. Then once we decided moving our monolith and layered application to micro-services and we decided our language, then few points we need to keep in mind. Because it is a complete architecture of application and system development. First, I will talk a little about building, integration and deploying our micro-services. A few challenges, then questions and answers. And the guys feel free to ask any questions. Let us make this session interactive. So, how many of you are using Go that in production? So, rest of you are learning Go-Lang and you adopt Go-Lang. How many of you are working in a startup? So, I assume the rest of you are coming from a mid-sized or bigger organization. There must be some applications sitting in the corner. People don't want to touch, don't want to work. Because it is a very big application. Our manager come and said, hey, do you want to work on this project? No, no, I don't want to work. Because we know it is a very big application. A couple of teams are working on this project. So, I want something experimental language, new tool, some small applications. And slowly it is becoming very challenging for organization telling this kind of application. Because of its monolith nature. So, when I am saying monolith, so, I will give you one example. Here in the back, on your back, you are building a patch platform. You know a patch platform that forms as a service. Herco, CloudHunter, so, we was trying to build a patch platform. So, we was about 20 people, developer. In 6 to 7 months, we built our patch, developed our patch. After that, we started adding new features. And slowly what we realized, our productive team, the 20 people developed that patch platform. We become unproductive. Because there was a million signs of fault. Before adding any feature, we need to think twice, could my code will break something else? Could my code will break other component logic? And we were not able to put ourselves compared with our competitor. So, other competitors are adding features, new release, empty bin, empty base. So, that is what all fault, that what we have done. We have the industry expert developer. And today we are selling in the place. We are not able to add new release, new features. So, we understood is because of, we have very big application. So, very big application. Then we look down that application into microservices. So, microservices monolith. So, let's understand a few points about monolith. If you have one bin, if you have one code base, if you have one technology stack, then you are monolith. If you talk about the layer, then you have a white technology, you have the packet technology, you have the packet technology. So, again it could be layered systems. There is some benefits. So, from a decade, companies are using, they are developing monolith applications. So, there are few benefits for developer. They have the simple mental model of development. You know, I have single applications. I am working on this code base. Say it goes for operationally. You know, I have this technology stack. I need to configure for production. I need to make another instance. I need to deploy. I need to deploy SQL, SQLite. A few points we need to understand. As I said, after working six months on a patch platform, we become unproductive. Because when our development tools get overburden, means our refactoring takes days. Our testing takes weeks. Our build takes hours. Means we are in monolith. In terms of scaling, I have been problem with performance. I scale to my application with the 10 instances. I am present problem with the performance. So, what happens, I take an example. I use one scenario. In my organization, we had one product called back-end. Every five minutes, we are doing back-end code. And we are updating our database with a million of data. So, this goes in every 10 seconds. When we scale that complete instance application with 10 instances, we scale horizontally. The same computing thing goes with the 10 instances. 10 applications. So, if you go for micro-services, we divide our application based on the function and the computation models. So, if I need to scale that part, we scale that part only. When our deployment is limited, means we are doing a monthly release, two-month release, then we are in monolith. When a system grows out of limits, we have 10 days, we build 20 days, 15 days. Still, we are not more productive. Developers, blaming testers. Testers start blaming developers. And product manager blaming, I have project developer. I was expecting five more developers, two more testers. So, we are somewhere in monolith application development. Our background is monolith. Therefore, we have micro-services. So, let's understand micro-service. Micro-services are a small and autonomous service that work together. One application will split into 10, 20, 100 small micro-services who are doing a small and single work. If we elaborate this definition, then it could be a small and focused on doing one thing together. Again, if we decompose it more, then functional decision of decomposition into manageable and independent deployment components. We can upgrade our complete monolith application with the 100 micro-services. But that should be manageable. That should deploy independent. So, micro-refer for the size. So, our micro-services are one application, two, three developers working together. That codebase should fit in their mind. And that should be functionally decomposed. And micro-services should have not depend on other micro-services. They do inter-process communication. It could be API code. It could be masses-based, event-based architecture. So, now, how do we understand how many micro-services we will have? So, we decompose our micro-services based on our functionality. Based on our resource conjunctions. Based on our resource, like if you take example of re-compose of the question. So, we can make one application that will handle profile. That could handle order, seeping, cut. When we decompose this complete application. So, we create one micro-services profile. That micro-services will only take off profile management. Profile update. Keeping the code of the customer. Another micro-service should be cart. That will only take care of the cart when customer adding some items that will go into cart. Another would be order. Again, these small micro-services need to talk to each other. So, we could make an event-based architecture. It could be a REST API call. Depend on the kind of task, kind of dependency one micro-service has with other. And all micro-services should deploy independently. Should not depend on the other micro-services. For managing this, if you take example, as at present I was writing a blog, Netflix having 600 micro-services. Can we imagine how big infrastructure they have will become really tough for managing these many micro-services. So, for managing these micro-services, we can use some tools like Kubernetes, resource for managing and deploying for continuous delivery integration. So, we are ready to cover this. So, when we have the company micro-services, so few points like... Let me read this. Four things I always keep in mind when we do micro-services architecture. First is the independent code base. Another is the scaling list. Third one is the features. Fourth one is the deployment. So, code base is meant never for developer. It fits into their graph. One micro-services to developers are working. So, they are able to understand their complete application code base. If it could be monolith, it's very big application. You know, 100 people are working on this complete project. You know what this X guy is working. So, if it's micro-services, 100 developers working in this complete application, but they are on micro-services, they know what I'm working on. So, tool like building, testing, refactoring, it takes seconds. It's a very big application. I've done small changes. So, again, complete application needs to be tested. Complete application needs to be built. Complete application needs to be redeployed. When you're going to all complete application, complete platform, but it could be micro-services, then if I add a small UI changes, I'm going to deploy one component. I've done some changes in our provide micro-services. It could be in CP. I'm going to redeploy only one micro-services, not complete application. If this complete application goes down for somehow, I need to call my development team, my testing team, my operation team, and everybody is sitting in the office for three days, four days, adding fixing bugs, testing again, redeploy again. It would not be a case if it's a micro-based architecture. So, two guys are working together. Something goes wrong. So, they will roll back the code-based redeploy. They will work again separately. They feel it's done, it's doing the job what I'm expecting. They can redeploy. When then technology is tried, it's one of the beauty of micro-services. So, we have only this application. So, we assume 10 years back, we started with some excellent development. Then we started JSP, J2E. Take an example. We started with the Erubio Analytics. And it's still been 10 years when using the same technology as that. If it's micro-services, so we can use micro-services that fit for doing, we use the language that do the things better. If you take an example, if we are playing with a task, something is CPU-intensive, memory-intensive. So, we can prefer using Golang. We could prefer using Node.js. If something, a kind of script, kind of work, doing some scripting, we can go for Python. We can go for Ruby languages. So, here we are independent with the technology style. Today, I feel Python is not doing a good job. It's not best for this micro-services. We could go and explain with the other languages. We take it out We leave it at a small micro-service in other languages. We will test it out again. It's not work. Again, we always feel to go back with the previous language, previous tool. Team can explain new technology with micro-services. We can select a stack that's very lightweight. So, these are few points. If you talk about different scaling, I guess we see which micro-service needs to scale. You don't need to scale complete application. If something I need to scale with my shipping micro-service, we scale micro-services with the 10 steps, 2 steps. I'm not going to scale my complete all micro-services. Again, I've talked about feature things. We can play with our micro-service with adding new features, deploying, testing. It won't take much time. Now, here, Go comes in picture. Why Go is best for writing rest services? I played with the Ruby language, Python, Node.js. I believe every language has its own history, its own features, its own picture. Every language has its frameworks. And that's what's best. No language having something we cannot develop. But here, we need to decide which language, which framework is going to fit for which tasks, which micro-services. So, I prefer Go because Go is the language that comes with dynamic language and static language. If people work from the static language, so we prefer using a static language instead of programming. Because quotes are not compiled, then we are redeploying it. Before, we are working in the dynamic language. So, it's very efficient language. So, Go is language that's took features of the dynamic language and the static language. So, we can get both things. Our efficiency and our safety. So, why Go? Go is good for performance. It's easy to handle errors. So, it's one of the very good part of Go language. But take an example, if we are adding a function. The function could result in things. With the expected result. Or it could be error. So, we can expect both things. We can handle our errors. So, it's in-built in Go language. Safety is a static language, as I said. Fast development is very easy language. Next slide, I will cover why it's very we do fast development like it has in-built and limited libraries that do pretty good work. There's not too many libraries I need to go and play around. And these libraries are provided by a community and the Go itself. So, we talk about simplicity. So, Go has only 25 keywords. This is a simple example. Python has 33 we have 41 and C has 32. So, first thing I'm not mean for 25. I could go and remember 33 keywords. I can remember 41 keywords. But why don't I remember that many keywords? If 25 is enough. In Go language, there is full load. Every language has the condition full load. Like full add it up condition. Go like single full load. Single load condition full load. There is no switch. There is no do, there is no why. We can achieve our do functionality switch functionality with full full only. Could I write here? Then Okay. So, just I want to give you simple examples to understand how Go is easy. How easy it is. There are some inbuilt libraries you can use. Naid, Achieve, encoding, cryptography, HTML, templating, generating, and many more libraries. Go like package websites. You can see. So, next let's talk about Go tools. Go having some inbuilt tools. One of the things I would like to talk here about Go FMT. Go having a tool Go FMT that format our code. So, if you talk, if you go and see a a shag of someone in the language community, you will always find there is a thread because if asking what is the best way of writing out code this? What is the best way to do formatting? It should be a space. It should be tight. It should be full space. It should be a distance. But in Go like this, handle many issues. They have a tool called Go FMT. So, just you have to write in your working title Go FMT and it will be format to a complete code space. Complete project. So, I have a when I was working with developers, okay. Guys, please do format your code. Yeah. There is a service that uses sublime. So, sublime you have to add or package. We use it. So, there is a tool called Go link. Go win, Go test, Go dog for doing documentation. So, any question about Go like? So, is it clear what I am talking about? Cycle code will be fine. Okay. Okay. So, let me do one small example. Everyone know for you. Okay. For what do we do? I equals to what? Okay. I less than 10. I plus plus. And if you will write us on our code over here. Okay. So, this is a general formula. If we remove this part. If we remove this part. Okay. Then it's become sorry. Other language having a form, do and why? Right? For we are having the initialization increment, sorry, conditions and increment. Right? And here if you remove this part. So, it's become blue form. When we remove increment this becomes white form. Example of I know program could have been write in Bola. So, it will be understand better. Examples. Example of the Bola. All of us are functioning Bola. We carry two parts. Hmm? All of us are functioning Bola. Okay. If I just saw talking right. Put it like that. Okay. So, with any function here something forms. Gate. Okay. Here we are passing a parameter. It could be I. It could be string. That made it S. Okay. Here we can return result as string and error. It could be error. Now, when we do the gun type. Okay. We are adding a return. So, when this function get called. Okay. Here we have the result and error. And we are call this method. Gate we pass for a material like say name. Here we could check this error. If there not equals to null. Then we throw all error or throw something. Log dot cream. Let's understand. Here I am calling this method. Okay. And I pass parameter name. Okay. Here I will get name on this string type S. Okay. And it will return result as a string. Okay. Even it could return error here. And here we are getting two different. One is string. Another is error. And we could check our error. If we have error then it will break our code here. Okay. Or we will do something here. Otherwise it will pass on. Understood. I have not written anything. So, here I specified it have to return time. Okay. So, what we could do I removed here. Okay. I removed error. Now here I look to return some calculations of business logic. Okay. So, after I need to specify here it could be result. It could be error something. So, here error assign something X. Okay. And result having something name. So, I have to take care of both things. Error and result. Understood. Okay. So, any other question before moving to the next slide. That's fine. So, when we are moving from to microservices. So, we need to take care of few things. Like rapid monitoring and the rapid deployment. For doing all these things we can use some CICD tools like Jenkins. We can use Kubernetes. We can use MISOS. So, when we have the microservices then we could face with the integration issues. Bringing software into the production will become little hard because we have the 110, 20 microservices. It will take a lot of time if you not do automate all this deployment integration and deployment. And it could be error for handling all these things. We can use integration. Continuous integration. Continuous integration we can use Jenkins. Jenkins is the tool for Open source tool that for continuous system integration. 10 teams working on the 10 applications and when they are checking out their code. So, their code will be get tested it will get deployed. We can repeat big test of the project. We can configure automatic everything like integration test, unique test, functional test, it is a little hard. There are many things the benefit what we get about code will be always consistent states code will be always compiled to be automatically tested. Developer will get feedbacks before going code to production. And we can manage this whole cluster using mesos. Mesos is the tool for cluster management and actually what mesos does if we have the 10 VMs. So, we can represent our 10 VMs with the single VMs. And it will manage all the resources. Mesos is a scalable and distributed resource manager designed to manage the resource for the data samples We can use marathon for application deployment and make sure application is up and running is a more day of school. Further challenge could be testing transaction authentication. So, guys when we are moving application from monolithic to micro services. So, it is not always recommended to go and adopt micro services. Few things we need to keep in mind because we have the experience on building micro service architecture. What could be the alternatives options? Do our team is ready for adapting micro services? Do we are ready for adapting new tools? We are ready to play with the new languages. So, this is just an option ok. So, you have before using micro services you have to understand your requirement. You should talk with communities, understand with blocks. Then you could go for adapting micro services. Any questions? So, I have done with my talk. Yeah? Yeah. Yeah. So, Amisos 180s and Docker swarm for orchestration. So, how it works? I will give simple example ok. Recently I was doing one process with Amisos ok. Same things we can achieve with the Docker also. So, my day of stream having about their Jenkins server. And this servers are given to individual teams. Every team doing their integration, application integration and deployment. So, what Amisos do? Amisos having the framework called marathon ok. And the Amisos orchestrate our data center. So, once we install our, so Amisos is the tool for managing our data center orchestration ok. So, if you how Amisos works? Amisos has the concept of master and slave ok. Take an example we have 60m 1, 2, 3, 4, 5, 6 ok. We want to make this all VMs as a single machine. So, we will install our Amisos on one VM ok. And we install slaves on this many 5 VMs. And in of Amisos we will get single machine. We able to see single machine ok. Where is we deploy our application? So, that time master will decide which is slaves having the resource on that slaves it will deploy our application. It could go on 3 it could go on 5 it go on 6. What if master goes 1? Master yeah there we have option or there is we can make multiple master ok. So, if you do this complete orchestration. So, we will have 3D master 1, 2, 3 we can make 3D master ok. We can make 3D slaves. And we load we will load balance this master with juke keeper. So, juke keeper we will make sure one master is already operating. If one master is going down so another master we get up and take responsibility of the main master. Where we are deploying any application ok. So, master will is still pinging and taking which slaves having the resource on them. And we will deploy this application on that slaves. Any question? I use mesos or Kubernetes do same pattern. Mesos is for the big odd adjacent for cluster or the data center. Kubernetes could use for the managing of all of phillips, 120 phillips. This year we just use to go over the company manager. I have played with cloud funding. We have to have more processes where we having about 10 applications. And we have deployed on cloud funding ok. Later on for giving this complete system to our decision team. We have done all the operations on Kubernetes. So, this is the when we are doing my my business architecture. So, my services are talking to each services with event device or less space ok. So, all my services should expose less endpoints. So, we could deploy any things. Any other question? Has it kind of reasons ok, my business architecture team. If it is something for a single business task this management is doing, it will retire to or deploy on single team ok. So, this will be one single ok, two single ok. If our management is not using more memories not putting more memories and single. So, on one VN we could have the multiple services. It could be 2, could be 3. We need to decide what kind of tasks our management is doing. This is one of our frameworks on Mesos ok. For how you address this there. So, we can deploy this in the visual services of Mesos. You can deploy configure this there services of Mesos. Configure if you are using you see Mesos having an open source that is called VC OS. So, VC OS having a build this comes as a library. So, this one will be deployed you go to the libraries and click leave this over there it will deploy for you. If I have the individual setup of the Mesos then you have to you have to do and configure your services. By yourself. I think after that. Thank you.