 Selamat pagi. Selamat pagi. Selamat pagi. Sekarang ini akan dipakar dalam perjalanan micro-services oleh Pn. Hari Pn. Pn. Hari Pn. Pn. Hari Pn. adalah konsultan software dengan lebih daripada 10 tahun pengalaman dalam domen seperti Banking, Network Security, Telecommunication dan Retail. Dia telah bekerja di beberapa perjalanan konteks. Dia terlalu terbangsa di mana dia adalah teknologi director. Dia berminat dalam perjalanan micro-services dan perjalanan micro-services dan perjalanan Pn. Terima kasih. Terima kasih. Terima kasih kerana menerima. Terima kasih kerana berjaya. Mereka telah lakukan kerja untuk saya. Jadi saya tidak ada banyak kerja untuk membantu. Ya, ini adalah perintah saya. Selain daripada bahagian ini, bahagian yang saya cuba bekerja pada hari ini adalah Closure dan Golang. Itu sangat tentang saya. Jadi mari kita mulakan. Sebelum kita mulakan, bagaimana banyak kita di sini bekerja dalam perjalanan micro-services yang berdasarkan perjalanan micro-services bergerak ke dalam perjalanan micro-services. Itu sangat menarik. Bagus. Bagaimana banyak anda tidak dengar tentang micro-services? Baiklah. Kenapa perjalanan ini? Sebelum tahun lalu, saya telah bekerja pada beberapa perjalanan yang bergerak dari sistem monologi ke perjalanan micro-services atau membangun perjalanan micro-services. Dan salah satu perjalanan ini telah berhasil pada Python. Dan itu telah berlaku dalam perjalanan yang baik dan baik. Dan perjalanan ini adalah perjalanan yang menarik dari apa-apa perjalanan saya. Dan saya ingin berkongsi bahawa orang-orang tidak perlu melalui semua perjalanan yang kami lalui. Jadi itu tentang perjalanan. Dan... Ya. Hanya untuk mendapatkan perjalanan micro-services dalam 2-3 menit. Dengan perjalanan micro-services, tidak banyak. Ia hanya sebuah perjalanan yang lebih di-interpretasi dari perjalanan micro-services. Saya yakin banyak kami telah melakukannya. Sebenarnya, anda hanya mengambil sebuah monolith dan tanpa mempunyai segala-galanya di satu tempat, anda mengambil segala-galanya ke kecil dan itu yang berlaku. Mereka mengambil sebuah api, tanpa mempunyai sebuah monolith. Sekarang, kenapa ini terlalu spesial? Ini bukan sesuatu yang baru. Dan apabila anda mengatakan micro-services, semua orang mengatakan bahawa perjalanan micro-services seperti anda mengatakan bagaimanapun micro-services dan bagaimanapun micro-services atau... Itu adalah pilihan yang besar. Tapi kemudian, sebelum kita melakukannya, kenapa semua perjalanan micro-services berlaku? Saya rasa setiap conferensi perjalanan sehingga kemudian anda akan melihat satu-satunya perjalanan micro-services. Dan itu akan menjadi sebuah pilihan yang benar-benar untuk menggantikan sesuatu yang sudah ada di sana. Anda dengar semua ini? Semuanya kecil, mendapatkan, memperkenalkan, siapa tidak menang? Dan... ini bukan baru. Kita sudah melihat semua ini sebelum ini. Semua pilihan lain telah mempunyai sebuah cat jadi saya perlu meletakkan di sini. Jadi, sesiapa yang berlaku dengan Java J2w, architektur tak conversation seperti braid ke-message EJV Saya melihatkan masalahnya. EJV telah berkenal dengan apa yang yang kita inginkan untuk menghasilkan modularitas, terutama mdbs, braid ke-message. Anda dapat menggemaskan peta-peta di jika mereka akan digudi ke pementsyaan menggunakan weblogik atau mayan-paman app, dan mereka akan terbentuk Mereka mempunyai autoskale dan mempunyai jemes yang betul-betul membuat kerja yang baik Dan mereka mempunyai sistem reaktif yang kita dapat membangun Ia sangat bagus dan saya harus kata anda dapat mempercaya mereka Mereka sangat mengalami masalah Apa masalahnya? Ia sudah berlaku Kemudian ada OSJI Selanjutnya, modul-modul, servis-servis, servis-servis, servis-servis, servis-servis Dan kemudian anda membangun mereka dan membangun mereka OSJI juga sangat bagus Dan jika seseorang mempercaya jawa-9 Ada sesuatu namanya projek jigsaw yang akan berlaku Dan anda cuba lagi bekerja secara modul-modularity Jika anda telah melakukannya banyak kali Dan sepatutnya sejak kita memulangkan software reaktif Ini telah menjadi masalah yang kita cuba meletakkan lagi dan lagi Tetapi kenapa kita tidak melakukannya? Sama-sama perkara yang mungkin sangat unik tentang servis-servis-servis Ia adalah protokol komunikasi dan bagaimana anda ingin melakukannya Orang-orang seperti itu tidak mempunyai sebuah venda atau teknologi Sebenarnya anda panggil itu ransomware Kerana seseorang memberi anda teknologi Dan kemudian anda melakukannya Untuk saya, ia mempunyai biologi Kerana kita mempunyai biologi Dan kemudian, semasa kita mempunyai biologi yang lebih besar dan lebih besar Kita perlu mempunyai banyak banyak duit untuk aplikasi Dan kemudian kemudian keputusan yang menjadikan Dengan servis-servis-servis, ia tidak tentang sebuah teknologi atau sebuah venda Ia hanya sebuah idea Dan ia semua tentang tidak melakukannya sebuah venda Dan terutamanya dengan Python, anda mungkin tidak mahu melakukannya Sudah tentu Saya dalam konferensi Python dan saya akan bercakap tentang Jangan cuba melakukannya dengan Python Ia bukan idea yang hebat, saya rasa Terima kasih Jadi bagaimana dengan pembentangan Python? Sudah tentu, kami mendengar banyak bahagian data Dan kami mendengar banyak penghantaran komputasi Dan sebagainya Python adalah sebagainya bahagian yang besar Dan juga, sebagainya bahagian web aplikasi Saya tidak ada pelajaran data atau sebagainya Saya hanya sebuah pembentangan pembentangan Saya mendengar aplikasi Saya ada beberapa pembentangan web atau sebagainya Tiada apa-apa Bagaimana pembentangan ini? Semua anda yakin dengan pembentangan global Ia tidak mempunyai anda untuk melakukannya Anda mempunyai pembentangan pembentangan Python Tapi anda tidak mempunyai kemungkinan untuk melakukannya Bagaimana anda mempunyai kemungkinan pembentangan atau sebagainya Sudah tentu anda boleh melakukannya Tapi terima kasih Bagaimana anda mempunyai kemungkinan pembentangan? Bagus Jika anda tidak mempunyai kemungkinan Ia adalah sebuah program paradigme Di mana anda melakukannya Banyak anda datang dari community Node.js Ia adalah program paradigme yang sangat bagus Bagaimana anda melakukannya? Ia adalah tempat yang sangat bagus untuk memulai API Microservices adalah semua tentang servis pembentangan Dan API Jika anda mempunyai sesuatu yang menyebabkan Bagaimana anda melakukannya? Tapi Bagaimana anda mempunyai pembentangan Python Microservices app? Saya tidak mempunyai Bagaimana anda melihat pembentangan pembentangan? Bagaimana anda mempunyai pembentangan? Saya mengatakan bahawa saya membuat pembentangan Saya membuat pembentangan pembentangan Microservices app Saya membuat pembentangan Dan setiap pembentangan diberi pada Python Ui saya sudah mempunyai javascript dan reaksi Tapi Semua pembentangan yang diberi pada Python Dan ia sangat teruk Saya tidak pernah dengar dari pembentangan hari ini juga Pada pembentangan, kemungkinan pembentangan Sama ada aplikasi web Memang mempunyai pembentangan Ia hanya mempunyai pembentangan Ia juga mempunyai pembentangan Saya tidak yakin anda dapat membuat pembentangan Tetapi ia tidak terlalu mudah Ada pembentangan selepas pembentangan Saya mengenai pembentangan Dia bercakap tentang pembentangan aplikasi pembentangan Jadi apa yang kita lakukan? Kita mempunyai pembentangan Tapi kita mencuba mempunyai pembentangan Dan pembentangan Ada sesiapa yang mempunyai pembentangan? Bagus Pembentangan pembentangan ini sangat bagus Ia adalah pembentangan servis Jika anda tidak membuat pembentangan atau anda tidak membuat pembentangan desa membuat aplikasi web Sama ada pembentangan Ketika itu, aplikasi yang saya bekerja telah mencuba membuat pembentangan yang berlaku Pada pembentangan Ketuaan yang anda mesti ia mempunyai pembentangan dan mempunyai pembentangan dan kita mempunyai beberapa filter yang menggunakan perangkatan. Jadi jika kita mempunyai semua filter ini, kita harus menghentikan data, mendapatkan semula dan kembali lagi dan menghentikan kepada keadaan keadaan keadaan keadaan keadaan keadaan keadaan keadaan keadaan. Untuk ini, Lambda itu adalah cara yang sangat baik. Dalam perlukan yang mencukupi kita pergunaan sebenarnya dan melakukan semua perangkatan untuk semua perangkatan, tapi seluruh itu, semua perangkatan yang kita masih ada di python dan Flask bukan benar-benar tempat yang baik untuk kita. Sebelum kita mulakan, saya rasa banyak kita memiliki aplikasi monologi, berapa banyak kita memiliki aplikasi web di python? Flask, jango, okey, bagus. Jadi jika kita belum berjumpa lagi, bagaimana kita melakukan perangkatan pertama kita? Ini adalah cara yang sangat murah untuk melakukan. Saya hanya memilih perangkatan paling basic kerana ini adalah apa yang saya gunakan untuk menunjukkan orang lain dan team saya bagaimana kita mulakan dan apa yang kita cuba lakukan. Kita memiliki perangkatan yang mudah dalam perangkatan. Sebenarnya, kita perlu berkata negara dan kemudian ia tidak terlalu dekat. Ia hanya metadata. Ia boleh menjadi apa-apa lagi. Ia boleh menjadi model perangkatan, mobil perangkatan dan apa-apa saja. Sebenarnya, mencukup informasi. Ini adalah aplikasi monologi. Apa yang kita lakukan? Kita hanya mengambil perangkatan di dalam perangkatan. Kita mengambilnya secara separat. Perangkatan tetap di dalam aplikasi monologi. Data masih ada dalam database yang penting. Kita tidak benar-benar membuat apa-apa tentangnya. Dengar sini, kita bekerja dan melakukannya. Kita melakukannya sekejap sekejap. Jadi, ia sangat panjang. Iterasi. Kita tidak mempunyai masa untuk melakukannya dan semuanya dan kemudian melakukannya lagi. Dan kerana kita di dalam perangkatan terus, kita perlu menunjukkan setiap hari atau setiap minggu. Jadi, ini adalah semua yang kita boleh lakukan dalam satu setiap hari. Kita hanya mengambil perangkatan separat dan melakukannya di perangkatan yang berbeza dan menggunakan perangkatan yang sama. Jadi, ini adalah satu perangkatan. Pertama perangkatan kedua, kita bergerak ke Redis. Kita bergerak ke metadata ke perangkatan separat. Jadi sekarang, mulai mempunyai perangkatan dengan diri sendiri. Ia boleh dikatakan dengan kurang-kurangnya. Dan ia boleh mempunyai perangkatan sendiri. Well, setelah itu, perangkatan itu tiba-tiba mulai berkata, okey, itu adalah perangkatan yang sangat muda. Jadi, anda boleh melakukannya dengan perangkatan. Sekarang, kita ada sesuatu yang sangat kompleksan, seperti kita perlu membangunkan sistem perangkatan. Dan ini sangat susah kerana ia mengejar banyak perangkatan dalam perangkatan. Dan kita tidak mampu membangunkan perangkatan, kan? Sekarang, orang mulai mendapatkan sedikit perangkatan yang mudah dan mereka berkata, okey, mari kita balik ke perangkatan perangkatan. Ia sangat susah untuk kita menjelaskan perangkatan dan membangunkan itu sebagai perangkatan baru. Jadi lagi, apa yang kita lanjutkan adalah, instead of building it inside the monolithic application, we started building the new features and services separately and now the view layer started separating out slowly. So essentially, this is a strategy called strangling. If anyone has read this old book called Enterprise Application Patterns, there is a pattern called strangling and what you do is instead of going and rewriting an entire application, you keep the existing beast alive but you start taking nibbles out of it. You start building stuff around it and then the center core becomes a useless dummy piece of code and then you can remove it. So this is the strategy we started following and then we started pulling out services more and more into from the monolithic application and as we went on, we had different storages. Most of the cases we had the master DB as the integration point because we could not afford a message bus at this point. I'll get to it but right now the integration point is still the database. Not a great idea but a good place to start. It's okay. We've all been there. We can integrate through database. When you talk about a typical microservice, even that simple lookup table, it's just got redis and it's got a service in front of it. All it does is get request. You just ask for it and it just gives you data. Even that simple service requires like it's got its API, it's got its logic, data, then you have dependencies. Like for example, even though it's just serving countries and states, sometimes it needs like certain information from other systems which need to come in. So that dependent services are always problem and then there is automation around it. So every single service that you deploy, you have to deploy it through a continuous you know, a CI system, some sort of Jenkins or something else like in a snap CI. Whatever it is, the automation itself is not easy. And then there is admin. When you have a monolithic application, you have the database. Some of us are okay with just going into the database and making modifications but in case of enterprise and especially audited enterprise applications, you have to have admin and the admin has to like you know, the admin interface should be audited enough that you know who did what. Now, when you have separate services, what happens to the admin interface which was on the monolithic application? We started building individual admins for individual services. Now this was becoming a pain and then there's monitoring. Sure, you can monitor, you have like data dog and you have like all that cool developed of these days. You could just you know, put Neuralink on all the boxes and then have one single dashboard. Sure, you'll have like a NASA like sure, you have a huge control center from where you can look at the entire architecture of your application. It sounds easy but in reality when you have like so many different pieces running amok and you have like admin and monitoring setup, it's easy to you know fail. For example, the service went on for two hours and we did not even know that was happening. The main application was still running but unless until the future, I mean, user started reporting issues we do not know. So that's quite a lot and it actually takes a lot of discipline to get there. So there is if you read up a little bit about microservices, it's called a post agile movement. Can you say post agile? Okay, getting to agile itself is subjectively hard thing. For example, would you consider yourself an agile software development company? That question itself cannot be answered very easily. Like what is agile that goes into a big discussion? First of all, you got to have iterative development. You got to have sprints. Then you have continuous integration and delivery. If you have one monolith and that goes through a CI system, goes through staging and goes to production. That is a good setup. Now that is an absolute necessity when you're going into microservices because now you need pipelining. You need multiple of these applications getting built, integrated and then deployed. It's not just code getting integrated. You need services which are getting integrated and then deployed. Then you have something called release chain. Release chain is basically if you have service A version 1, service B version 2 which are dependent. Then when you draw release chain, essentially it should when you pull that chain, you have to get the entire release out which has all the dependencies. That's hard and by the time you get to that stage it's going to be quite daunting. Now, why am I saying all this? I just built a really small microservice for a lookup table and now I'm just presenting all this information to you which makes it sound like we should not be doing microservices. Well, the reality is you might never get to an ideal state. This is the case. Probably a Netflix doing it so long as it has been doing. It has matured and whatever it has built, the tools which it has built is very much suited to Netflix itself. And when I read up Netflix literature to understand how I can apply some of the concepts into our applications, some of them don't really fit and microservices very, very specific to how you're running an organization. It's very much possible that you might have one monolithic piece and then several microservices around it and it's perfectly okay to be there. But still for me the motivation to slice an application into services into smaller pieces should come from like something concrete. For example, technical. So in our case, this lookup table was taking a lot of the database queries. Like for example, every single time the user goes up and fires up the home screen, the first thing they do is do lookup. And when they lookup, it's all cached, sure. But then every time there's caching validation, it hits the database. And every time we have to modify the database, we have to invalidate all the caches. And the main application was taking a hit because of the simple stupid lookup table. So it was very, very easy for us to say, okay, let's not bother the important parts of the application for a stupid lookup table. So we moved that aside. That also ensured that we need not have to buy additional infrastructure because the main application could sufficiently run on whatever you know, instances it had on our AWS. So that is one. Increasing resilience as I said is pretty much this, right? If I have to just change, okay, new state was added in India and I had to go update it, I don't have to go modify the original application. That itself gives me resilience that as long as I don't touch it, it's probably going to stay stable. So it gives me a lot more resilience to push it out. So the motivation here and my justification to my boss in terms of like, you know, okay, I have to build this thing. I need a week's time. So how do I buy that? Obviously, I can only the only thing I can justify is, okay, here's your JIRA tickets. Here are all the bugs that came up because of this piece being inside and this is the time I spent on it. So here's the money that you could save by pushing this out. Essentially putting a cost benefit aspect to it. Even though it's a purely technical topic, the reason I'm bringing this in is because you have to have some sort of a motivation in order to do microservices. Doing microservices just for the sake of it. Probably doesn't make sense. The last bit is external versus internal facing APIs. This we did mostly from the angle of security. Some of the APIs that we were using internally also happened to be useful to, you know, be to be clients of ours. So we had to expose them. And when you are inside a VPN, it's purely secure inside your AWS VPN, you're fine. But then do you want to have public IP addresses for most of your services? And when you expose one service to the external world, do you think the internal services should also communicate over that same IP? Probably not. What you want to be doing is you put a layer in front of it and create another service which is purely exposed for the external world. And you keep the internal world secure inside. Am I making sense? So this is from a technical angle. These are few things which we considered when we sliced our application of. From the business angle, when we started slicing this, business started coming up and telling to us, okay, now that we are aware that you can split this big application into smaller pieces, can we carve out products by themselves? For example, we had a region search, search nearby and very specific to the business functionality which I cannot reveal. Can we carve this out as an application and put a metered API on top of it and generate revenue from this side project? Sure, pull that out, keep it aside, which means now I have a service which I can internally also consume as a client and I can also make money out of it. And there are pieces which are like the non-performing assets in your application. You never know the kind of money you're sinking into it. For example, there was an RDS, a huge RDS instance which we had on AWS for this particular feature and that was sinking a lot of money in. Now our business wanted to understand why are we spending so much money on this arcane feature. So we had to split it out and now we really started controlling and metering the API and figuring out how much money are we putting in and how much money are we getting out. So this is again a very useful way of doing this. I mean in the sense that again a motivation to split your monolith into a separate application. Right? The last two bits are very, very simple, AB testing. So anyone heard of blue green deployments here? Okay. And canary deployments of course. So when you have blue green and canary, okay, just to back up and for the rest of us, blue green deployment is when you have an existing feature or an existing application and you have full feature parity, you deploy the new application and cut over in one go. You pretty much shift all your users to the new system and essentially that's one go. Right? And then you have canary deployment where you slowly move people from the older deployment to the newer deployment. Right? Now this canary is a little bit of what do you say? It's a little safer because you don't transfer the entire load at one go and you just over a period of time test the resilience of the system as well and then you transfer over. When you have one monolith, you have only a choice. You either do blue green or you either do canary deployments. Right? Now with microservices we could choose like you know for certain services we could do blue green. For certain services we could do canary. And it was a choice we could leave it up to individual teams. Instead of it always going up to like CTO or director of engineering level decision. Individual team leads could make that decision. Build versus buy. So for example one of the services that we were using is the Google Maps API and we were pretty much taking a lot of money sinking a lot of money into it because we were doing this routing algorithms like we would find distances and we had put an obstruction API on top of it. So we would get you know information from Google and then send it over to the rest of the application. We wanted to cache some of this and we were okay with inaccuracy and serve that information. Now when you are building your internal routing algorithms or you are big enough that now the Google APIs are expensive and more expensive than you can handle and you want to build that routing algorithm yourself you might want to build that as a service put a load balancer in front of it and start figuring out which is working better. Then you can do again investment return on investment calculations and then switch over. The last one is Organizational. Now this is probably the easiest. I think there was a team which was sitting in US there was a team which was sitting in UK and we were sitting in India and we had to write code what naturally happens is each team picked up an individual piece and started writing code and then we would integrate at the end of the day or at the end of the week. This is a fancy way of putting it as converse law. So to read the law it's very simple Organizational which design systems are constrained to produce designs which are copies of the communication structures of these organizations. An example I gave is geography but then even if you have more than seven people or eight people it's going to be hard to communicate among yourself and automatically there'll be silos which are formed. Anyone who's not read The Scrum Book I definitely recommend reading this book called Scrum Getting Twice the Work Done in Half the Time. This is an excellent book and it talks about team communication issues. Again, why am I talking about all this in microservices? It is also a team dynamics aspect and it is extremely strongly dictated by how your team is structured. We'll talk more about this but in our case I think what we figured out is each team having up to four to five people and then splitting up into separate teams is better than having large teams. Initially we started out being like eight or nine people all working on all of the services but then this is not scalable. I'll get to the problems in a bit. So microservices architecture in short is nothing but distributed systems, right? Anything that you find in distributed systems as a problem you're going to find it here. Split brain problems or two-phase comments. Anything in your computer science classes which you have heard about for distributed architectures. It's very much possible in microservices. First one, identity. Sure, we've built all the services now. But when you're communicating between the services what do you do? Not all actions are directly going to be hit to the service from the user. For example, as a user I'll be hitting the view. I'm saying I need to book a ticket to a movie and that goes to a booking service. Now as a result there are other services which are hit. I have just taken a sample which is payment and notification. I am redirected to the payment gateway and something gets cut from my wallet and it comes back to the main system. And then there's notification service which has to send me the SMS with the ticket information. Now all of these are independent systems and think about all the details that you have to send across the systems. When I send the book ticket information I'm sending my user details to the booking service. The booking service is aware of it. But does payment and notification know who are the people who are actually making this changes? And when you go audit the notification service and you figure out that an SMS went out to some number that has prohibited then do you know that this action happened because of someone booking a ticket or someone going and hacking up the API and sending an SMS out from the system? This could very well happen, right? If you have internal teams which are extremely huge and you cannot prevent frauds this is very much possible. Someone could just hit the API get some token back and get the money in their account or hit an API to send bulk SMSes outside. So how do you control that? You have to have identity information propagated across services. If you have a monolith you probably are following an OAuth or something like that, right? You have a resource owner and you have a token service and you just do your authentication and authorization and you're done pretty much. But when you have such a large system how do you pass this token around? How do you pass your OAuth token around to other people and each service now has to keep hitting the resource owner and asking permission can I go ahead? Can I go ahead? And this is actually a on the one hand it seems secure. Okay let's we started out with this we actually started out with okay let's do OAuth and each service has to independently ask authentication permissions and then validate the token and then progress. But it's not a very scalable idea if you have one action which hits more than 25, 30 services it's not a very good thing to do. So ideally what you want to do is have something called an open ID connect mechanism. This is what we're trying right now essentially it's a delegation mechanism where you do the ticket and you get it verified in one place pass the information around and then record it. So when you go individually to each service and audit the service each service will tell you why this action happened otherwise you wouldn't know who did it. Am I making sense here? Any questions so far? There's more to it I think I can if at all we have more time after this I'll get back to it otherwise we can catch up after the talk. There's something called service traceability. It's an extension to the identity problem that I'm speaking about but what is service traceability? Every action that happens in the system should be associated with the primary use case. For example in this case I'm booking a ticket for that ticket I have a booking reference number and every action in the system should be happening because of that. Now if that information is not propagated and if I simply call APIs then you don't know how to trace the calls. Why is this important? When you look at this it's very clear it's an orchestration flow you have several systems doing different parts of it that is booking this fulfillment then there's payment and then there's notifications. Now if you have orchestrations like these if you were to build a dashboard if you're admin someone calls up I have booked my ticket but I have not got my SMS so how do I go to the theater and show the box office that I have booked my ticket indeed? What does your call center person do? They need to have a dashboard level in a picture of this entire thing they should be able to say okay you booked it but I'm so sorry that your phone number was incorrect so which is why the notification field I'm going to send it to your email for that purpose you need to have service traceability you should be able to say with service where what happened so that you can dashboard on top of it Reconciliation So when you have distributor transactions and especially when you have microservices you don't want to disappoint your users for simple things for example I'm booking the ticket the notification fails it does not mean that my ticket flow should stop I would be disappointed if you have like 30 services on one of the service fails for which you would rollback my entire process of booking the ticket that would not be a good experience and even if you wanted to do it it's not easy because if you started committing stuff onto each system remember now we are on a microservices architecture so even your data is federated your data split across the system so each system would have committed its own changes now if you go ahead and say okay the last part failed rollback everything else that's not easy so usually we have to follow an eventually consistent model in the sense that we agree that things can go wrong and then let it go wrong end of the day go reconcile or end of the hour go reconcile what's the easiest way to reconcile cues every single message that goes from you know service to service we usually push it through cues as much as possible anything that is possible to make asynchronous make it asynchronous and operate on callback mechanism only request response cycles are usually view based we don't do request response cycles anywhere else everything else is cues why is this good because cues automatically have a dead letter infrastructure if something fails it's gonna say for example we started using piris and later sidekick on the rails part of the application it would have a dashboard which says what all failed we just go retry right and then later we moved to Kafka so when we moved to Kafka we had an entire messaging bus across the system this is going back to the old diagram that I showed in the beginning of the presentation right you have all the services they all publish and subscribe messages from the central messaging bus and the central messaging bus has a dashboard on top of it so the end of the day when you look at it it's very simple to say what failed and what needs to be retry if something fails again you know which service is failing you can go fix it independently sounds simple but when you get to it and when you have to set up the messaging bus infrastructure and the dashboard on top of it it's quite some work but you can get there but you can start with having cues independently between services okay take a side how easy or hard is it to manage a project which has microservices architecture it's actually very weird my product manager went crazy after we started splitting this up okay so how many of you follow sprints here like sprint cycles or scrum cycles good so usually if you have monolithic application it's all good you have a single sprint board you put your stuff there and then cards move along nicely and then you're done and then you're deployed what do we do here for a simple feature to book ticket i have cards across all three teams payment service booking service and notification service and if you notice the card for feature one is pretty much in different statuses in each of them how do i even account for this in a sprint usually when we account for sprints internally we account for it after the business value is delivered even demo on staging is not considered done we actually push it out to production not only if it's in production we call it done so when we have such kind of discipline if someone cannot say i just push payment service out so the business value is delivered what was delivered nothing you just have an ability to pay pay money but who's going to pay the money there is no booking there is no notification so how do you pull this change across so the way we are solving it right now i don't know if this is the perfect way to do it maybe if you have suggestions you can let me know we have masterboards we're using jira right now so we have masterboards where we have epics which define the feature and then we have individual projects where stories point to those epics and then we are tracing this it's not easy it's been little difficult but why am i bringing this up once you have microservices architecture it's not easy to plan features as you were probably doing it when you had monoliths because every time you do this you have different teams you have to figure out you have to figure out the contracts between each team and then deploy right so service i mean release cycles are going to be a little longer to begin with and later when you get into the rhythm of it you will figure out the best approach for your company because i can't give us a little bit talking about api because the communication between the teams is all about api so we had you know anybody who's looking at that kind of a sprint board is going to say why are all the stories not in progress at the same time everyone wanted these stories to be in progress right so the first thing which came to mind is okay if you guys agreed on the api to begin with and then if you started work you all could finish in parallel and then we'd integrate at the end isn't this going back to the old days when you don't have continuous integration this is again the same problem reinvented right so we anyway tried we did not want to say no straight away so we tried but then what did not work is when you decide on the api very much up front you miss out details and when you miss out details there is rework and that makes it even more longer so when you had to usually solve a crime they say follow the money right so when I when I when you design microservices architecture I would say follow the data interface to implementation when I say interface it could be UI it could be api it could be any end point from which an operation is triggered if it's going across multiple services follow the data figure out the data structures that have to be passed on in between the systems figure out all the non-functional aspects what are the SLA's of return times what is can it be a a callback mechanism can it be you know a request response cycle figure everything out and only then go into setting the api is on stone this may mean that you may have to develop some parts of the application before you can develop the others it cannot be parallelized that's the reality and every time you write a new api call usually the normal tendency we started getting into is can we can we push this api into this service does it belong in booking service does it belong in you know payment service it's it's a very easy mindset right when you have categories when you have a new functionality just feel like suffering it into something that exists but it's it's really really important at that point every new functionality that comes in is it it does it belong in a different service or should we write a new one altogether right it's hard but I think we're getting there slowly apis we already discussed there are different types and we really have to be very conscious about what we're trying to achieve do we want synchronous call backs as much as possible avoid synchronous synchronous have problems if you can do it asynchronously better okay last but I think we are running short of time in terms of code when you had a monolith okay before I go into this again I strongly recommend anyone who's interested in microservices to read this book by Sam Newman about microservices excellent book it actually gave a lot of guidance for us when we worked on it and the other book about microservices is from Jonas Bono that's about reactive microservices again an excellent architecture book and some of these things which I'm talking about were inspired by that but I'm just making points which did not work for us from there so one of the points which comes from that book is about how do you maintain your repository when you have a monolith you have a single repository you check into it your continuous integration system fix it up it goes to staging it goes to production simple now when you have microservices to begin with what we did is we had all the services within the same repository it would still build all over every single service you check in the entire repository builds and goes to production but that's okay that's a starting point but eventually you will have individual repositories for each service that's where you really want to be because that makes sense you have to have a repository per service why that makes sense is because of the next the way teams can be organized for code is usually around open source i think the best idea for a service is for each service to have a service owner when i say service owner if i am leading a service technically i should pretty much be so protective about it that any code comes in i should pretty much reject the pr the pull request why because i would try to keep the service as small as possible that's my objective what is a feature owner feature owner doesn't care about services he doesn't think services he thinks feature this is what i need to get out to the you know audience so that's what i'm doing and then next comes the business owner right the business owner is more important because here comes the money like why are you even doing this and how how do you justify when you have these three roles acting on top of a service you usually have that good pull and push and which generates dialogue around every action that you're doing so i strongly recommend eternal open source because you could then submit a pull request and then if the team agrees great but otherwise sure i'm running short of time here so i'll just stop but this i think we can talk more later so that's thanks a lot and yeah i hope it was okay so yeah questions i think i stopped i did not talk about a lot of topics especially around the protocols for api we started using jrpc for some time then we used trust based protocols then even plain old tcp we came down to that level because it makes sense in some cases but there are more topics so any questions how do you insoconsistency between services between services yeah uh but how is anything confirm to what is sure things like that how do you ensure that so uh we pretty much came to the conclusion that it's not going to be consistent we followed an eventually consistent model so in some cases data will not be propagated we designed a system for failure in the sense that we assume that certain services will not be up at certain points in time we also had legacy services which were buggy so which would always written 500 for no reason right we had to retry all of those the agile book is scrum the art of doing the microservices is microservices by Sam Newman the other one is by Jonas Boner i can share that with you later anything else the easiest answer to that question is it depends in my opinion i would strongly resist the urge to go towards a microservices approach i think monoliths are okay after having built one or two microservices applications i personally feel unless there is a strong business traction for your application that you actually need to scale and you know that your business is going to survive the next six months because working with startups the problem i always have is i don't even know if the business is going to exist in the next month so if i invest a lot of effort into doing a microservices architecture it might well be that the next month the business folds doesn't make sense usually i resist the urge to move towards unless i have like a clear road map for the next six months in terms of traction and like i usually document non-functional requirements in terms of scaling then work it backwards like how much cost does it take to run a monolith versus what cost savings do i have to split stuff so any other questions i'm going to be around so catch me if you have any other questions also i'd i'd love to hear your feedback or you know any other suggestions you might have for how to build microservices so thanks again thanks a lot