Navigating Microservices Architecture | Gaurav Gargate | IK UpLevel MicroClass

[Music] thank you all right folks let's get going um at 604 gaurav you're here you're ready to go looks like or maybe may need a few seconds where god was here as well awesome so let's see folks so to all the alumni very warm welcome again and and and those are not alumni but hopefully soon soon too soon to become alumni also very well warm welcome those who are prospective students as well very quickly uh let me let me go through what you know kickstart is in 30 seconds and then we'll go into the the fun parts as well um so we have summarized what you know kickstart is on the slides um we have been around for about six years we have had a little more than four thousand alumni uh we've had more than 5000 plus offers at some of the best of the best coveted companies and teams on the planet um and it's very routine for us to get offers out of out of the program which are north of 250k our highest offer has been has been has been crossing seven has crossed 700k that was that was recent obviously relatively rare but but it exists we are in very interesting times uh if you if you put your mind to it you can up level permanently in your life the core of the program is that there is no way to game the system that is a deeply held belief the only way to actually become a part of part of a strong technical team is really to be a better engineer right when you are a part of the strong technical team that's exactly what you'll be looking for when somebody interviews for your team right there is pride and and there is craftsmanship in your work and how do we get there how do we become a better engineer that's what aerobic kickstart espouses and we have people like people like gaurav and other people um who come from come from that side of the world and they help you get better in a multi-month program experts we also teach patterns in problem solving right so you don't have to do randomized problems from here and there and hope that something shows up you do it the right way and it's a system and systems are far more important than goals a system of study to go through go through one thing after the other right i would um i would love to focus this session uh on microservices instead of you know kickstart i'm sure some of you will have questions on it please do sign up for our our upcoming webinars we do four uh uh every every week i'm sure you'll find a slot that's convenient to you uh we'll be very happy to answer any of your questions there uh it's an interactive session it's interactive uh webinar introductory workshop where ryan or i one of us will take it and we'll help you answer all the questions um there okay um you can also email started interview kickstart but the best best would be to just attend the webinar okay all right with with that um let's go to the next slide and yes that is this is the most fun part here um all right uh gaurav uh um gaurav and i worked at box together uh some of you know uh i was i was very early at box and i was fortunate enough to see a lot of good people come in during during my tenure gaurav girl stood out um recently left box um as a director of engineering and he joined confluent um those who those who don't know what confluent is uh probably have never worked with kafka but but those who even come from slight bit of a data world i'm sure must know kafka confront came out of conference and kafka came out of linkedin and one of the hottest startups today um and before box uh gaurav had his own stints and also worked at microsoft for a long time uh gaura is also a really fun person to be with and an exceptional instructor and really lucked out folks and without much much ado we are already at 609 let's get let's get going gaurav um over to you sir all right well uh thanks so much uh it's a pretty high bar to maintain that's i think you've sold me too high all right so um welcome everyone now today's session as you guys know it's a micro class um and this is all about micro service infrastructure and architecture um again i'm gonna have feel free to join me on medium on linkedin just definitely send me a note that this is from micro class ik that way i know the context behind it uh yeah so i already mentioned it but what more specifically is right now i am heading bunch of teams that help with confluence foundation side of the world on the cloud as well as some of the world on the observability similarly at box i was adding the microsoft's infrastructure or so as you can see i know a little bit about it um and happy to talk about it with you guys today so uh let's jump into today we are going to talk about four major areas of topics of this infrastructure microservices architecture which is slightly different although these are buzz words that can be used interchangeably i'll try to differentiate a little bit about it uh we'll touch a little bit on monoliths and microservices and then ultimately the life cycle and now again a lot of you have sent your questions so the team and i we kind of have tried to get them together distill it and these are the top topics or top areas that people have liked so just to give you a little bit more detail within these topics uh we'll be talking about these things so my intent with this micro class is to make sure obviously in one hour they're not gonna cover like everything it's a vast vast topic but i want to cover some things in detail that way you guys feel good enough as a food for thought to then further go and research so this is not gonna be an all-inclusive all-conclusive but this is more about how do you get started what's the overall skeletal of where you begin um these are some of the topics that we'll try to touch very quickly uh the content might be slightly heavy and i might move at a much faster pace so that we have time for q a at the end cool so which what that also means is don't watch netflix on other tab stay engaged stay with me and it'll be useful awesome so let's touch uh first on monoliths and services so there's like a lot of raw about this in the valley in general i have personally seen like three different monoliths i'm still dealing with some of that so the one question i would like to pose to the group here is think about it a very large well-built building are small but well-designed individual houses where do you want to live and the analogy pretty much is exactly what a model it is and micro services are now i want to debunk some of this misunderstanding that normal it's a bad model it's evil that's not true a lot of companies actually prefer to stay in models and their business model actually uh succeeds in normal facebook is a great example for some part so i want to quickly touch this microservices is not a one-all solution it's it's up and coming it's the new rare however i just want to say that models are not all bad remember models are very efficient because you can have all the code in one place it ships out and it's really good for capex you need pure servers you don't have to worry about inter-service hops and communication you can share the code very easily and model it everything is available for you right you don't have to go out after network on the network to fetch something and just being together you can actually make larger refactors changes all of that but there are different downsides which means it's all democratic whether everyone fails or everyone succeeds and there's a lot of problems around iso core isolation release isolation helping scale so on and so forth but i just want to make sure the advantages that you know of as well on microservices world it's great individual deployments small components each service can be owned by a different team all sexy all of that but it does come with the cost just like the picture you want to build the road so that everyone has access to their houses you're going to have individual plumbing and individual water supply individual electricity management all of that which means micro services although they help you accelerate certain areas of your code basis they do come with a price and i just want to know make sure that you guys understand that so it's pros and cons there's no one winner take home all but that's kind of how micro services and monoliths differ from each other cool so now we'll jump on to the next topic which is about just the infrastructure micro service infrastructure and to do this um and there was like a lot of feedback from the audience that you want something practical so i'll give you as practical as i can get i'm going to explain one request flow on box and walk you through how it works behind the course this is something that my teams built so you know i know a little bit about it obviously i i was there since like project new new five that kind of work so the scenario i'm going to talk about is if you go to box and if you look at certain like person's profile this is adam adams the ceo what happens when you look at this profile so my intent is i'll walk you through the entire architecture diagram with the request flow and then we'll go piece by piece and visit them on a whiteboard later so when you make a request through an api to go check on levi's profile the first thing you're going to do is your request is going to go get navigated through the to the world of internet to various different places on the world and go hit boxes data center once it hits the data center that's really the gateway and api gateway is a pretty much edge service that takes in requests over the internet once you get it there's an option where you can actually go toward that traffic straight to an older monolith and there's a monolith and dbe and all of that are your first interchanges with an identity ecosystem now this is we are piecing we are touching the pieces of microservices infrastructure and identity and security is a major major component of microservices and plus strategy so your first handshake is going to be your identity ecosystem so what happens here is a request comes in you go and go talk to identity which means it's going to authenticate you authentication means login and password are you a valid user but you might also get authorized what that means is are you allowed to perform this operation and once that happens you get back a jwt java javascript web token which means it's their identity for you and that's not injected in your header once you do that now the gateway's job is to go route you remember the gateway is more of like a quarterback or an orchestrator it takes some requests there's a few sanity checks authorization authentication maybe limiting all of that and then it says go to the job and someone else does the job so you would either get navigated to something like an application service which then talks to data database or caches behind it or you might talk to a monolith which means it's a heterogeneous ecosystem or you might even get navigated to another set of services now the idea here that i want to convey is just to get your job done just to load that home page you might hit out like five or six or ten different services in the back end and then microservices infrastructure makes all of that seamless and easy ultimately the infrastructure's job is to let developers focus just on the business logic so that they can do all of the heavy lifting so you could be navigated here or you can have cross service communication so on and so forth or you can be talking to some of the input services now just to be clear this is an actual diagram that i've also used in various external tech talks that represents part of box's infrastructure so this is as practical as you can get into how systems work at scale and we have scaled it to 70 80 000 requests per second um so this is this is as real as it gets and this is um and then we are going to touch some of these pieces obviously a lot of these services get pushed through cicd pipelines ci cd is continuous integration continuous deployment we'll talk about how that works we're also going to talk about how you log and monitor throughout your ecosystem we are going to talk about service mesh a little bit we touch on it and also talk about tracing that's what you're gonna get through this session we're gonna go into some details everywhere but this is a very bird's eye view of what the end of the result would be now very quickly here is a set of technologies again i just wanted to make sure people understand what happens in reality our gateway being a very i o heavy and less compute heavy service has been written on neti which is a non-blocking architecture some of our services are in java some are in node os is the api schema you can see there's scala there is java there is php logging and monitoring happens through wavefront and pd service measures smart stack or on y uh light step is a tracing ecosystem but there's my sequel red is hbase all of that so again this is just like a quick overview of what things are now let's go as i mentioned before and look into detail on each of these pieces and for that i'll go into more of like a whiteboard diagram here blackboard in this case so let's talk about auth n and r z as i mentioned when the request first comes in your first interaction is with identity remember no services infrastructure will work without a well-built identity ecosystem so what happens when the request comes in is you hit your gateway and a gateway in most cases is designed such that it has a bunch of filters now filters are nothing but individual jobs that have been designed as a bunch of filters that are chained together so you could have a request filter or you could have a bunch of response filters that's how gateways get designed and typically what happens is one of your requests filter is gonna talk to your authentication service it it says yes this person is authenticated then it might go talk to a authorization service and it's going to say yeah this person is authorized similarly you might change various different microservices in that request flow one is gonna go check if the rate limiter has been hit or not you can read about what regulators do maybe another one is going to do some business logic that is very specific so for example if your uber it might do like a driver health check before a request is accepted that hey has this driver i don't know paid his dues or has her car well service so on and so forth so that's a chain of request filters and each of this is a micro service hop similarly you could have responsibilities which means by the way make sure my data that goes out is secure make sure i have covered up everything so they're not leaking pii data or something like that so that's how gateways identity rate limiting of now the fun here is how do you then manage this whole inter-service communication so let's talk about that a little bit remember every service talking to another service is a network hop over the wire this is where inter-service communication becomes difficult because there are lots of things to worry about so now let's check what i mean by that if i'm servicing calling service b what are the network fields what if there's an error replied back what if i'm not able to find b because b as a box or as a node as a container is down so there are lots of things that have to be taken care of when you deal with inter-service communication now the only golden rule that applies in microservices is that everything will fail literally that's that's the only truth everything and everything will fail at any time so every service every code every logic you build has to be built with that amount of resiliency how you typically do that is every service usually uses a inter-service communication library now this is typical you might have something else but this is just what i'm calling as typical you might have an inter-service communication library that takes care of all this logic which means hey what if the service fails retry what if i get an error go decorate that error with something what if i'm not able to find this service go figure out something else so that's how all of the inter-service communication is taken care of however there are certain other sets of problems think about service b what if i'm getting too many requests which i just cannot even sustain what if my server is crashing because lots and lots of people are requesting the same thing this is where concepts of throttling this is where the concepts of circuit breaking they come into picture so what these libraries do is they prevent the incoming slaughter of requests by pushing back so throttling what it means is this service b is just gonna respond with a specific header and a specific message that tells the client or the consumer or the caller you wait don't call back because i'm busy so all of these intricacies have to be managed within your inter-service communication this is what a lot of service measures are doing these days so again i'm slowly um like touching on various different topics as you might have realized we move we're going to keep moving like this and i'm going to talk about various different topics um through a scenario so what's a service mesh a service mesh as the name suggests is a unified well-defined networking or communication mesh that connects all of these services again this is just a picture to discuss there are various different forms of service measures some service measures are centralized what that means is all of your addressing all of your navigation all of your naming happens through a central server everyone contacts this central location to say tell me how to reach somewhere else think about your think about usps or your regular post box no matter who you want to send your letter to it first hits your central post box and from there on the nothing happens so that's how a centralized service mesh works but there is another category of service meshes which work oops with that which are client-side what that means is instead of relying on a central source of truth like a dns each of these boxes will have their own copy of the network around them so this is a client-side load balancer mechanism which means if i service a one-acre service c i don't go talk to service c straight i just send a request to my local store here and this has a routing table with it to know how to hit c so those are that's like a service mesh that we can talk about within a client side load balanced way cool so all right so i'm touching various different topics that i promised in the slide before all right so now let's talk about actual services and the data that they fetch so let's change colors to make it fun all right the biggest topic that people always deal with and ask me is all right you have this service and i want to talk to my db are they patterns are there ways to do it are there best practices so on and so forth now in a pure micro services based architecture textbook style what they recommend is each service popped to its own db only our own table in this case not being that's the that's the norm that's the gold standard so what that means is each team that owns the logic can pretty much own the entire ecosystem of a service and a database behind it now they can make localized decisions of hey i want to actually use redis here i don't actually want mysql or dynamodb or whatever like you have 20 other vp they can also make decisions of hey by the way i actually want to add a cache layer here because my service and the load i am dealing with is really heavy and i kind of just want to make a quick solution so microservices architectures recommend that you approach them this way that way your teams are independent to make their own decisions as well as you're optimizing for your own request flows and look uh now again caching could be of various different types you could have a heat through cache which means before you redo the db you always read through the cache and then the cache figures out what to do with the db and so on and so forth you could have a write assigned cash which means you never go talk to the cash if there's a so on and so there's a ton of patterns around there but the intent would be the caches i use to make sure these are efficient and going with this type of micro service architecture pattern makes sure that they can actually hit them in a sustainable way but that's not where the fun is because in real life what happens is you have multiple services talking to multiple different people so sometimes the exact same table um again if you have opportunities if you're lucky and you're like dealing with a brand new system then yeah you might actually have um one table and one service talking to each other but in reality that doesn't happen in many cases i could be wrong in many cases so what happens in reality is you have service a and you have service b talking to the exact same db or table and this is where the fun starts because look really is easy datas are important you go fetch the data if it's not on the database you go talk to a read only slave or you have some caching logic so on and so forth easy to solve what about rights though as you can imagine there's a possibility of a race condition in correct so they might go and go update a certain field of a certain table of a certain row which even b wants to go update and suddenly you have a two-piece commit problem you have a race condition so on and so forth in a distributed world it's not as easy as imagine you're writing i don't know sql java code you can just like transaction boundary go to foo and bar and then if not transaction roll back it's easy when you write it in code but in a distributed systems world transaction management is an extremely hard problem because you're not only dealing with rollbacks and all of that you're also dealing with network failures imagine your service a who says go update some record um and you get a response true or yes but in reality it never actually happened and something happened with the network failed sometimes happened like b doesn't get a response so on and so there's a lot of complications so distributed transaction has certain amount of patterns now my recommendation would be to prevent distributed transactions as much as you can instead add compensation logic which means instead of relying on commit and then roll back you say let me go record whatever service requires and then if i don't find the data or if there's a race condition i will go apply another logic that goes and compensates for it so again i'm touching on the super transaction definitely there's a lot that gets here under a lot of protocols and a lot of best practices so on and so forth but that's typically what's going to happen with databases cool now let's touch on so we can look at access transactions quickly turn sharding uh again these are by the way all these are topics that people have asked for so you know that's what we're trying to cover what is shouting um shouting is a way to scale your bbs now you can only store so much in your database because you're going to hit some limits which means if you have a database and if you're hitting the limit you can vertically scale it which means you can add a beautiful bigger box with more ram and more disk and blah blah blah but that's going to only take you so far somewhere or another you've got to split your data that we can store within different places that's what shading is about so shouting means if you have a long table like this with like millions of millions of records you decide to divide that table into chunks and then each individual table now decides on a different tv in different tables logically it's the exact same entity logically they all are a user's table but physically they're all stored in separate vps and then what happens as you might imagine is if i'm making the request and say go fetch got up now the business logic or the service that's going to access this table has to figure out on which shard which is could be shutter one sharp two sharp three sharp four where does ghada's record actually exist that's the logic that the service has been figured out they can figure it out based on another mapping table that basically just maybe alphabetically assigns me to a certain shot or it could be deduced by the logic of like let's shower not hash my name and whatever key that comes up we'll go store it in that chart so sharding is a technique to go scalar databases horizontally with the data can be split now some as a exercise for the reader here is go look at various different sharing techniques and you can find tons and tons of data you'll hit something called as consistent hashing consistent hashing is nothing but the way to divide the data that way the load balancing is easier cool so what else did we touch from here we touched on various different pieces of microservices infrastructure routing how do you actually go to multiple different hubs how do you do identity how do you do inter-service communication how do you do service meshes you touch an authentic you talk about data access distributed transactions throttling so on and so forth now remember when you go build a microservices infrastructure in your company and you saw the diagram i showed you before all these pieces have to be big so that your engineers don't have to worry about it and that was my intent behind showing the discipline that there is a lot here almost every piece that i'm drawing here um has been pre-built as a service has been built as a library that way every engineer who's working only focuses on the business logic of the service code so that's about microservice infrastructure uh we are going to talk about logging service map tracing later on um but it's going to show you where we are let's move forward let's talk about this topic very quickly micro service or macro cells um again a very common question i get so what i'll do is i'll actually talk about this and i'll talk about combine the whole how do you do microservice architecture question together so remember we saw microsoft's infrastructure but what do you mean by microsoft architecture architecture is a step back typically what happens is so i'll do the analogy i get remember the building background i showed imagine you're going from a big building even into services then then question happens is who do you club together which apartments go stay together who does not stay with someone else so if you have multiple families living in the building you probably want to stay together in a single house or maybe not actually you know what depends on your choices but you know keeping it more professional think about the legal imagine they're like four different apartments shared by the legal team you probably want all the legal team to be together uh imagine engineering or design you want to make sure all of them stick together but imagine there is like a extremely sensitive equity team that doesn't want to leak any data you want to keep that team completely independent put it in your own house these decisions are what microservices architectures is all about and that's where you decide whether you want a microservice or macro service because a lot of architectural design actually is driven from what your business is all about now i'm sure you guys know this that uber went into like this extreme microservices world where they were known to have like thousands and thousands of microservices that's just the way that business evolved that's just the way decisions so they basically went from the complete granularity out of having individual very very thin micro services tons of advantages where you know everyone's free and nimble but it so happened that a team of five people would end up owning seven services imagine the load the operational heavy workload interference communication all those challenges whereas there have been many companies i think google famously had this somewhere out where they went with very very i think azure and bing they went with very fat macro services which means the logical divide of your microservice architecture is very driven by what type of business you are in what type of workloads you expect to happen what type of user personas you want to highlight very different things because bing search wants to be extremely fast and they want to combine data from various different places they decided that they'll plug all of the a lot of the logic into one big macro service that we don't pay the cost of inter-service hubs whereas maybe uber which is a certain asynchronous work pattern for their business because you're looking for uber and they're not like this like looking for a car it takes time that's just the way the nature is the marketplace they could afford to have that asynchronous mechanism so micro service architectures enhance the micro versus macro debate is very much driven by your business it's very much driven by what entities your business have and then how you decide to split your domains so there is no one fix for all you've got to do the research you've got to figure it out in my experience in many places it's kind of okay challenge engineering wise to build a microsoft infrastructure because you know a lot of patterns it's coding it's fun microsoft architectures is where companies fail cause you either overdo it you oversimplify it so on and so forth just food for thought again there is a difference between how you design your architecture versus how we just build infrastructure to support architecture cool that's about that oops now let's switch this as a promise we're going to touch on two more topics after this uh we're going to touch on how you build a service like a life cycle and i'm going to talk about operationalizing a little bit so building a service and the life cycle comes with a lot of frameworks how we built it and this is my example but people might have the ways we decided to make it very easy for developers so i'm just going to show you like a quick diagram of how it was i'm gonna this is um um if you if you could not move back and just stay closer to the microphone that might be slightly better okay because there's a bit of a noise and we lose you a little bit more thank you yeah sorry about that you know it's hard to contain my excitement now i'm kidding but let's look at this picture what this tells you is what type of framework an engineer possibly can get and this is like an example the real world example again practical example in box but the idea is microservice has a ton of moving pieces and it's very efficient if you can templatize framework a lot of these pieces so typically you start your i mean you would want to start your micro services which are backed by api which means you have an api repo now best opening based keyboard read about them these are very essential api design principles and tools so typically you would start with an api as an engineer i would go and build my api design i would feed it into some tooling that would take that api which is the json or avro or protobufs builder site and then you code gen a lot of pieces out of it because remember apis and schemas make it very easy uh to design your services so typically from an api you would build an sdk which is your your client side your stubs your data objects your implementations sorry your interfaces so on and so forth and then the engineer will go and add those implementations similarly we would code gen an entire service stack which means there's a data access layer there is like a implementation layer there's a testing layer so on we would then give you out of the box lots of metrics and lots remember each service when it's running it's going to have some typical same metrics unlocks and i'm going to talk about how those logs flow but you want to access that which is when was my request coming in when did it go out what errors what bugs so on and so forth uh box has is pretty big and confident also is pretty big on communities and docker everything in control is kook um so you could generate kubernetes and docker templates for you generate code gen data access objects remember when you have an api you are already specifying what data you want to access and you also get a whole cic template i'll walk through that as an example later on but i mean set up control there's some of our boxes jacking there's so many different beautiful tools out there but to add to it what you want for coherence and consistency in your micro services is you want a good way to manage and operationalize your service once you're in look i think the code is just probably half the battle i would actually say that's the easier battle because you guys all are good developers you guys know how to write code managing operating scaling your service is where the biggest challenge is and if you look at the companies out here in the valley i mean everywhere the companies who do that well actually they are able to grow it these are the companies who can scale elastic elastically have no downtime all of that good stuff now typical services should give you health check metrics oops uh it should give you good places and i'll explain what tracing means basic monitoring of your health and bunch of test results so that's like a quick look into the life cycle of building a service now what i'll do is i'll quickly show an example of a real world jenkins pipeline this is like an example of a pipeline um so there are various different stages if you are in an ide you save your code you push in from github you're going to have your dev environment your stage environment your product production environment you know ultimately going issue with production we'll quickly touch on how production rollouts happen that's the operational part but this is like a real good example of pipeline uh here are the different phases design development testing onboarding and operationalize of your service uh your intent should be have very quick cycles fast failures um so for example at the box people can ship at will which means if i'm a developer i like code i deploy to production it's gone um and i can know that test results are successful of pain as well okay let's quickly touch on observability and operationalizing and hardware abstraction so from slight perspective logging apis log tailors tracing in the stack health check alerts dashboards and we'll also talk about some form of resource isolation through kubernetes and docker so let me quickly touch on the observability stack i know we are probably running a little late but it's fun here's a service if i write some business logic i typically and this is running in a docker container i typically write to a certain mount file so in my business logic i'm saying whatever log4j or whoever your login library dot log and i'm saying it's an error it's an info it's a debug so on and so forth so i'm always writing to disk once i write to disk typically i have a tailor or a demon or a job or a side car whatever you want to call it that reads this lock remember this is a right eye lock i'm just reading this log and using a kafka pipeline or something like that all my services are shipping their logs into a centralized pipeline on these different topics and now i have a larger system you typically must have heard the elk stack elastic lock stash kibana now there's another job that goes and reads from this and does a bunch of number crunching which means i'm taking all of the logs from my entire cluster i'm doing indexing i'm doing aggregates i'm trying to combine them together analyze them together so on and so forth which then ultimately served to me by a nice little ui that i would know okay what happened at this moment on this machine or give me all errors that have been crunched by this system over here that's how a typical observability stack works now this is not just limited to logs as you see here this is not just logs but you're talking logs metrics and traces these are three essential components of an observability stack log tell you tell me what happens at this moment metrics can you tell me what's the health right now how was my cpu how is the memory consumption how are my incoming quests traces tell you where i am i have come from so trace think about trace as a as a needle that's showing the thread across various different all the way back i mean in this days covert dressing is like a common word that's all this is all about who's the company and where did it come from that's what racing does uh it can help you find out where it's coming from so that's all about the observability stack now when there are traces logger metrics there's creative duty that is basically just a way to think you tell me what's going on um there are lots of other tools like weight front that helps you visualize there is data dog again that helps you visualize all of this helps an engineer support staff customer success figure out what's exactly happening in the health of your system all right final topic the final topic is all about uh i know you guys are interested in the hardware isolation so let's look about kubernetes and docker so what's docker is a container isolation code runs but when you have tons of different containers running kubernetes or k8 as is commonly known is a way to manage these containers and when you have to manage you have to figure out who's healthy who's alive who's not alive um how do i reach a certain container how do i address one over the other so typically when i showed you the pipeline where i'm saying i'll deploy the code to production remember all of these containers have the exact same service running it's just that they are in a cluster so what happens when i deploy code and what is also typically called as a hot reload is that kubernetes will take a new piece or new version or new image of the code and then it will slowly start applying it through one box at a time one container at a time so if i say make sure my rolling starts happen it's gonna go push the code here and say one container is on version two or less of the version one then it's gonna do the next one next one the next one imagine something happens here and this one fails it quickly goes and resets resets roll back roll back so kubernetes with docker takes that entire um burden of hardware isolation how do you push code into production how do you manage modes coming up and down how do you just go add new container boxes all of that has been abstracted from an engineer or from a system so all you have to do in a microservices infrastructure world if you're using um any form it could be dockers and like docker containers and kubernetes it could be vms it could be some other hardware abstraction techniques you have the intent and the idea is you want a centralized place to manage your containers manage the images on a container and manage the addressability and discovery of your containers when the request is coming from the out so when a new request comes from the outside it doesn't know which part it's hitting all it knows is i'm gonna talk to this abstract ip or abstract whip i got and then kubernetes or whatever addressing technique you have will take care of routing that service to a specific container cool so that's a touch on kubernetes rolling restarts scales traces creative duties very quickly i just talked about testing again you saw the pipeline i showed you about that some time ago you know testing has various different forms just search for quality pyramid you have your unit tests you have your component tests you have your like api and schema tests and then you also have like end-to-end tests but in a microservices world you've got to do stuff like longevity tests which make sure the service is running and keeps running scale tests performance tests so on and so forth i think these are all artifacts of your ability to run services at scale cool so i think uh we have been covering at a very fast pace uh but hopefully you guys are getting got a good sense of all the topics we covered here um i was supposed to keep more than 10 minutes but i have time so if you guys have more questions cool thank you awesome thank you thank you very much folks again this is soham we just heard from gaurav on the microservices he went almost breadth first we had collected questions before the session and that is that is what influenced this obviously it's a vast topic and there is no way to do justice uh to this in in in an hour people have written books and books on it um what we are going to do next is we are going to take some of your questions okay um if you have a technical question please don't use the chat box uh please use the q a box which is here uh scroll through the q a box very likely uh somebody might have asked the same question you have had right so i will um go to what i'll do is i'll i'll read out the questions sure and then um and then and then feel free to answer them as well sure okay um folks again uh scroll through the questions upload the questions you really want answered um also please uh please avoid asking interview kickstart related questions if you can please do attend the webinar that's coming up there are several um several that we do every week ryan and i will be very happy to answer all your ik related questions there uh let's uh let's keep this very focused on microservices right the the topic is vast uh gaurav knows a lot more than i would probably ever know about the topic uh so let's uh let's make use of that right scroll through the questions afford the ones that you that you feel like you would love to get answered okay i'll give you another minute we have a girl like he said he has uh he has a few more minutes past seven pacific as well and we can we can continue to get answered okay cool folks very likely folks we will we will not be able to get through these many questions either the question is just increasing at a rapid rate so so please do scroll um see if your question has has already been asked then please upload it and we will we'll typically generally start with the top most uploaded questions and then we go down from there okay it's 6 53 let's take a few more seconds i still see upwards coming in which is very good right folks if your question does not get answered please note that there's nothing personal against you it never will be just a question of time and just a question of managing all the questions right um okay also um you know kickstart classes are certainly not this big but uh and we have we have very good ways of getting all the questions answered when we're in the class so so try not to project project this to the class though we do go quite in depth in a lot of number of technical topics yeah so this is uh do you have something any questions do you think so we should go let's do this um so the top most worded question is uh is actually from one of one of the alums what's the best strategy you would advise and breaking a huge monolith into micro services is it a good idea micro services only for new use cases that are being encountered or is it a better approach to divide the existing system into smaller services yeah which would catch it uh very good question let me just pre-text this uh i mean i have my own experiences again dividing your micro services or building and going is very very business specific decision it's bespoke to every company it depends on talent you have the appetite to go build infrastructure in your company the pace of which your company is moving how quickly is it going my personal opinion would be the following that you have a monolithic ecosystem and you want to build a microservices world i would say first start by proving that you have doing a sustainable well-defined microservices infrastructure within the company and typically to do that and that's that's like one of the tech talks i had done was i call it steel threading your architecture which means go pick an mvp that is uh small enough that it's not company ending but uh intense and complex in other words not just a mickey mouse project and go build all of that entirely in a micro services ecosystem which means take care of routine take care of identity take care of data access take your winter service all of that so typically i would say the approach that has worked for me is first stop the bleeding which means go build everything new in the microservices world that way you get used to you train your engineers you build a culture even microservices is actually a cultural change from model and once you have stopped the bleeding then you have a little bit of extra time to figure out okay now that my model is here let me now design my strategy to slice and dice it into the ways i feel are appropriate for my company so that's my approach first to stop the bleeding and then slowly carve out pieces out of the monolith now just a quick disclaimer before we go to the next question maybe your monolith might never completely die and it's okay heterogeneous and polyglot architectures are reality and it might just be okay it's completely fine very very good point very good point guarantee don't hate your monolith monarch has some really really good advantages with micro services will never provide very good excellent um awesome the uh the next question uh can you provide some pointers or links or book suggestions that help learning microservices better unless do you have anything fine sure i mean i think look uh okay read the google sre book i think it's really good book um it's very like sre focus but that's the reality devops is the world where we're all reaching so learn to embrace that side of the world um also read up on a lot of tech blogs that people have we are fortunate like the big boys of the valley the netflix's the google the facebooks always publish a lot of the stuff that i've done i spent a lot of many years in the past reading about it when i was assigned to build my quizzes in perspective box i went and spoke and interviewed many people like netflix and google and uber and all these because it's best to learn from them uh we're not reinventing anything here let's let's be fair i mean yeah so read up on tech blog read up on these books um and talk to people honestly go find people if you know of your network and your friends and see what their experience is happening wonderful uh folks i would like to add that google sre book is free free and online for everybody to read tech blogs i have personally found nginx blog um quite quite useful as well um i have also found i think uber's uh ubers as well quite useful just for my personal reading the uh especially microservices here and and uh and amazon also sells a book by i often forget sam or someone uh building microservices is also very good very good book just well for those who are more used to books versus articles so designing data intensive applications yes that is also a very very good book um as well okay um all right so so that what is the tool used for god of white boarding it is pretty good or blackboarding i must say um hey sorry guys for that you gotta sign up for the premium no no it's funny this is apple notes that's all look at that it's not so thanks to my laptop and all of that excellent excellent folks uh there are other tools as well uh those who don't aren't on apple devices there is one called explain everything which we use ik as well it's actually very good we have also written a blog post on how to handle remote interviews and we have enlisted num enumerated a number of tools in that also so feel free to check out our blogs as well and you'll see it there too awesome thank you gaura uh do you have any small project ideas for someone to get hands-on experience with micro services if they currently don't work in them right where do you get started and like do a small project any ideas yeah that's that's actually a good idea uh look i think you don't need to necessarily build everything from zero to one i think it's more important to um have a compounding effect by building on top of something that's already out there and you learn a lot just by doing it so let me to pick up good projects that people have built now there's i mean you literally can do a good search of very simple open source project a try them out try out an open source project and just start contributing to it you'll learn a lot just by doing that second uh think about a real life situation that you have and go build it on aws i'll give an example when we had a baby at home i wanted to build like a simple bar to know how many times the baby is pooped or whatever like that very simple using an amazon dash button to just say whatever so pick a personal pet project that you have and go build it on any cloud providers go get free credit from aws or google or azure um just use that eb just use their networking stack just use their cash just use those systems just by using those systems you build a lot of practical knowledge of how things work and fortunately you don't need like real users traffic it's like a bot that sends traffic to your service if you think you want to think about scaling and just type it out uh there's a lot uh which is available for free so far um i i think one thing that gaurav mentioned which i think i would love to emphasize is that use aws use aws there are lots of stuff that is already on it right and and you can make use of it and and you won't spend time in just creating the infrastructure and you you'll spend time in actually the request flows which help you understand things excellent excellent as always um uh example of compensation logic sure uh so what's compensation logic compensation logic helps you so it's more of a fix forward instead of a roll back think about it like that so imagine if we have a financial application where because of various race conditions or like useful things you charged or you debited uh or credited your user twice why because debiting and crediting is not important service so here's here for example here's my app that's talking to my service and i'm saying please uh subtract which is i've paid for something but imagine the network went off you drove through a tunnel something happened in the request reached the servers it went and made that db transaction but then you didn't get a response because you couldn't get that acknowledgement back so you press that again that means you've now sent two different requests requests to the same thing now because this particular distributed cluster of services are stateless and it hit a different part at the exact same time imagine you got credited twice now instead of building this complicated let me do two face commit safety net and all of that you could our company could just write another simple bot or a tool that makes sure that there is an auditing in place that make sure it looks at the db make sure it looks at unique transaction ids and ensures that hey maybe this some something seems wrong here the same user at the same particular time for the same he has been have two different debits applied to it so what he would do in this particular case is you typically would just send a message to let's say a kafka message broker confluence kafka good plug there and you would basically say for this transaction id for this particular operation that happened at this time go do compensation logic which means go insert subtracting add the exact same amount and then asynchronously another machine would go pick it up and make that change in a database so especially in financial operations and services sometimes you might see that your bank shows a credit processing it's still in the processing mode because some of the bookkeeping and auditing has not been finalized that's why you might see the money come to your bank or account but you're not able to withdraw it or use it because the compensation logic in place needs to still make sure that all the isa daughter and keys are dashed that's an example awesome um awesome thank you chris for asking that uh question very good uh and everybody else for affording it as well um so that makes uh makes life much easier uh helps us understand what everybody's looking for um how is the service mesh different from api gateway uh very good question service mesh is kind of like a pretty modern uh kind of a recent phenomena let's say five years eight years ten years the purists might say they always existed whatever so there is an eventuality where service measures might actually go replace your old school api gateways so today uh api gateway is more of an edge service that goes and does a bunch of routing whereas some smashers are an ecosystem that goes and your entire uh service network so service measures might like almost connect each of your node in an n squared kind of a fashion so gateways and service meshes actually service mesh can do the job that the gateway has been doing because this mesh is like read up check out on why and read up on data plane and control plane has two different things uh you'll have fun reading about it so data things and control things these days actually do a lot of stuff that gateways can do plate limiting throttling circuit breaking authorization so there is an eventual world where maybe traditional gateways might not be useful anymore uh but i think they're still like around because gateways can provide a certain amount of value which is ease of new filters as configurability mentioned in the diagram before up here somewhere uh anyway you guys know what i mean so yeah that's that's where they're both kind of coming together good question very good very good thanks mel um is the rate limited similar to circuit breaker and resiliency uh no short answer is no brake limiter is a is a component that helps limit the rate at which your requests are going it's extremely i mean a well-built rl system is extremely configurable uh but they give out like a pattern and that is gross simplification rate limiting is nothing but having a disabled counter and circuit breaking is more of prevention you could use a rate limiter to circuit break a certain request call but they're not exactly the same and if you skew and squint at it each and everything that i spoke about can help with resiliency so i can't like pinpoint and say these help with this against everything we have done that's a very very very good fine point girl a circuit breaker circuit breaker just breaks it um it doesn't just limit the limit the rate sounds very good awesome um how prevalent is the sagas pattern especially top companies i don't know about uh i mean i don't know what companies uh in general but yeah sagas uh distributed orchestrations some form of compensation these are all good patterns that are becoming more and more relevant and useful uh because i think so far sagas were very theoretical but now the tools have come so managing distributed workflows managing orchestrations managing uh inter-service all of that at the business logic level has been used up delivered through saka patterns so i'm pretty sure it's relevant although i can say for sure because i know i know but hazard question uber has this new open source project called cadence so yeah and i'm and i'm guessing that most of these places don't implement in a purest way any of these any of these sort of methods and and such they're just the way nobody does agile in the exact same way the way that is being said so nobody would um and also the patterns have been usually formed because because they they just follow the business logic so it's a pattern people implement different ways make sense uh thank you um okay and this is this is frequent in in in different ways that's been asked do you really need to have a different database for each microservice what if we are managing a lifecycle and building multiple microservices handle every stage of the lifecycle is there microservices if these microbes don't share the db then we will need to pass a lot of data from one to the other yeah short answer no i mean no one forces no one asks it's just as i said it's a recommended way now let's instead of thinking about whether it should be used or not think about why it is recommended and see if that problem is what you're facing with it's recommended for code isolation it's recommended so that a team doesn't have to manage or be dependent on someone else's vp it's recommended so that an entire if you can have the complete control of how your you don't have to do it uh but instead you then have to take care of a bunch of the scenarios explain about how do you do updates your two different services are coming and updating the same db how do you control one place locking the db another place wanting um yeah and for typical like life cycle management yeah i mean you need transient data to be managed because life cycles and workflows basically means you're constantly changing that maybe you know these use a persistent db maybe you just use uh messenger brokers and kafka and so doesn't that necessarily result in just more bugs because you're just passing a lot of data around um and such like consumption yeah it really depends um everything you do can result in bugs so it's all about the how and in this case my how if you're very schema driven if your interfaces are well defined if you have strong isolation and interfaces on how what's this is requesting and here's the behavior i expect then i think you can reduce the possibility of the bugs because there's a clean hand up between different components the best way to think about is think about linux piping you can run one command have a piper another command have a pipe and another command have a pipe each of this command is very well built isolated way tested and all it does is talk to each other with a simple text file so now that isolation is well done well defined well tested with garden the number of bugs can reduce i say so i suppose i haven't seen this one very directly but but i'm sure this follows uh this one is like you don't mean to convert every sql query into microservice right in that sense yeah yeah i mean there is obviously like a function as a service and all of that stuff like techniques um yeah i i somewhere i feel is a little bit of an overkill what i need to say is if you have a certain entity which is everything about a user limit that to just a user service everything about payments just make sure it's all done in a payment service that will also also contain the data sprawl exactly exactly awesome correctly hope that was useful um is is service discovery a part of service mesh yeah so again service meshes they help you connect your ecosystem together you could use the same service mesh to do the study um now there are various different tools to manage it i can read up on on my if you feel like it's pretty good tool coming up these days uh it does use xcd do some of the state management some people use it keeper so on and so forth so yeah that's one of the jobs yeah box we tried zookeeper i remember finally named of course uh in an interview when somebody asks do you use microservices is the expectation to be familiar with patterns like sagas and twelve factor necessarily or or not necessarily uh look this is a very philosophical question in my opinion in my opinion um interviewing should be more about what can you answer based on first principles and not about how much knowledge everything you've done which means even if you have not built microservices the interview should be thinking about what would you do if you have to um and then think on your feet and see if you have the first principles in place so yeah i have i'm opinionated opinionated when it comes to interviewing so i don't think uh uh yes but like i suppose you personally don't expect somebody to be familiar with these patterns the way they are laid out and such when if you ever ask a question like that unless i'm hiring someone at a pretty senior level in their job and the expectation is to come and do it but if i'm having someone for a slightly younger level you could come and learn then i don't think it's your question microservices and you never heard of sagas or twelve sector that's a problem right otherwise yes yes okay okay but otherwise otherwise it's it's it's generally generally okay um okay awesome good question uh when one container gets gets upgraded with a new feature and the other is still on an old build how is it ensured that the end-to-end user experience is not inconsistent the age-old question i think microservices are not folks this is this is the benefit of working and in large large places like to to someone this might seem like a very basic question um coming from there you would feel like it is actually a basic question but but anyway sorry i i can go on and on about working at good companies and good teams and these are some of your dailies very good thanks please go ahead no i mean the intent is if you want to build services that are stateless you want to bring services that are stateless that way your ha high availability and scalability are well done uh this is where backwards compatibility is very important um yeah and if you are not able to do backwards compatibility and if you're having a breaking change it's okay what that basically means is one after a million users again i hope this only matters when there's actually scale at play one of your million users probably is going to have a request being dropped or not served but again if you look at it from a very different perspective if your slash slos are about 99.9 uh one in like 40 000 requests or five in the particular requests are not gonna change it so much so yes there is there is an eventuality where you might have a drift in what your responses would be but then the idea is to reduce that window as much as possible but i do want to start by saying backwards compatibility is the most important thing um so don't have making changes otherwise you have to deploy it at 2am where there's no traffic um makes sense it makes sense um thank you uh in what cases are microservices uh my architecture pattern not a good fit right yes yeah i think again as i mentioned uh my microservices come with complexities of all the stuff i spoke about um sometimes you might really not have that kind of a business case you might not have those with engineers uh you might not have that much traffic your business might be offline all of those things yep uh um and and and and and that might mean that you might even consider a monolith like if the business is small the number of engineers is small and and the traffic is not that much like you might consider okay very good very very precise um this is a very generic question let me know if you would like to skip it what are some of the challenges in scaling micro services do you have like top two or three principles in that that come to mind in scaling um [Music] yeah i would say the operationalization of a microservices world is not easy um so again uh you can write bad code and you might deal with ton of like bugs and restarts and garbage collection being stuck so there's a lot um to unfold here but i would just say operationalizing a microservice has to be part of this first class citizen because that's where the biggest challenge is going to come from scaling is like i don't know it's like an open topic yeah yeah yeah that's right it's a vast topic as well um okay thanks robert um what are some best ways practice to solve tracing problems and dealing with thousands of services um well tracing is supposed to be the solve of problems so i don't know what is a tracing problem uh so your if there's a problem with the tool i don't know what to tell but tracing will help you understand where things broke so if you have like five different hops of your of your request being flowing traces will help you get that lens to see okay this worked well it this worked well this worked well this work will oh this is where it flew um so tracing as its own ecosystem comes with lots of spans and case ids and all of that i would say sticking to the tracing protocol is very important so read up on open tracing if you may because what this does is it gives you like a certain protocol that you follow that way your visualization your debugging and diagnosing is very easy okay very well thank you as services evolve new features are added improvements etcetera are made how do you gauge when to split and into smaller ones and how do you divide them functionally operationally what's what's it what's your thought process yeah i honestly would always divide services uh functionally and i would make sure that we invest in right tooling and technology to manage the operational side of the world uh just because a service has high operational load that's not the only reason to split it i would say that think about your think from a consumer's perspective and think about what workflows are contributing to the extra load or heaviness it might so happen that a service is growing in code but only 20 percent of the code base is actually being hit 90 of the time focus on that split that up that way you can make localized scaling decisions for that twenty percent of the code and then suddenly you realize the rest of the eighty percent is actually not very pushing heavy i would always go with functional divide awesome um thank you for the crisp answer of um api gateways reverse proxy now uh api gateways can act as a reverse proxy but that's not the typology no i'd say okay what does openshift do what does openshift do i'll have to google that i don't know okay very honest answer uh that's that's that's actually very good thank you um does kubernetes also help enable service mesh um yeah i don't think that's i'm gonna say something stupid but i don't think that's the right question service mesh you can it can exist with cool with vm with vms whatever um so it's kind of like talk about each other but yeah kubernetes definitely helps you with discovery which augments ourselves um let's see these are less affordable questions like can you touch base with waf um is that is that something uh that you know what it is and would you like to touch on uh what's w if someone can expand uh let's move on i think there are there are other questions as well uh how do you establish inter-service communication scaling so shall we say calling service b uh i think we touched that uh in the recording so i think once you start reading that recording um look at that you might be able to do it again very good um all right so yeah at the end of the question seconds here at the end of the questions um i think these are some of the things that are are you already covered or that they're sort of not necessarily uh microservices related only like uh hold on people are still reporting questions uh is between service oriented architecture and microservices architecture um service wanted architecture again these are just terminologies people use them interchangeably as the name suggests when this thing came out first it was more of soa which is think service don't think big that's how service driven architectures happen microservices happen as things started maturing i'm sure in the purest form there's like some difference in like how you address how you discover how you deploy but for most practical reasons people use it interchangeably okay so um one second let me just scroll the rest of the questions are there any libraries you would recommend um in in building off of the this thing especially the question specific question is i recommend that helps polyglot microservice work for rate limiting retries and such uh girl we can't hear you so okay uh rate limiting uh check out onboard weight limiting uh it's pretty good uh i've used it confident like you're trying to right now um reply logic again if you rely on service meshes uh price can happen you can also just literally take up any java open source to try uh intersense communication sdks that will help you there also you recommend sitecast for this or libraries inside application good question side cars are not cheap uh they are extremely efficient for core isolation you know you don't have to depend there's no dependency bs with libraries and all of that but siteground also um increase your capacity requirements they need more memory more disk space sometimes so on and so forth um so it's actually a question about um a like capex like amount of money you want to spend and let's not forget uh side cars do mean that there's an extra network half although it's localhost it's a little bit of complexity of managing sidecars can go down so you have to have separate head checks for your sidecar so on and so forth so the question is between coding complexity and operational complexity okay folks i think so i've been scrolling through questions um many of these have been actually discussed by god a session already so i would urge you to go take a look at the recording once you post it on youtube um some of the questions are not related to microservices they're just general uh system design uh questions as well some of the questions are a little far too philosophical as well so i'm going to skip them as well looks like i think we are also coming coming to an end uh of this uh there are uh there is maybe like one question uh uh gordon do you want to do you want to speak a little bit about kafka the role of kafka in this at all no actually um so as well yeah so there are two types of services in general in the in the world there's one service which is online which means a request comes in through http or through like the world to you and the second one is offline or async which means you have accepted the request from the internet you have done some processing you have responded back to the user and now your inter-service communication is not happening directly but it's happening through a scalable well-defined highly available message buses so kafka is probably like the gold standard right now to decouple like your inter-service communication to scale independently and globally so kafka and offline requests and offline services is probably probably the where a lot of the future is going um so think about literally all your new apps like the lyfts and the ubers and the open doors of the world um part of the box part of so many googles and maps they're all asynchronous so kafka is the gold standard when it comes to asynchronous message bus management um and obviously confluent uh is a huge like supporter and contributor to the kafka project but it also gives you an enterprise edition of kafka which is managed and hosted in all of that um yeah i think a event streaming and so think about or look up event streaming this in my opinion is the next wave of technology archetypes just like how databases were away even streaming is probably like another wave coming up wonderful thank you gaurav any any last words about learning microservices or doing anything specific at work and such what i personally think is about you covered today i think a college professor will not be able to cover it in a thousand years and just just experience dripping in every sentence thank you very much any any part would be very helpful um and thank you for extending this half an hour as well uh yeah one sec i think i got stuck in my video somewhere but yeah uh well i don't have much to advise uh have fun that's that's about it stay curious i guess fun with micro services and stay curious awesome all right man thank you very much for your time today um and uh and thanks all of you as well sorry we couldn't take all the there are still a hundred open questions um i i highly appreciate everybody who is very curious about this there is there is a real drive to learn please keep that up uh don't let anybody anybody shoot you down like that again nothing personal just in interest of time you have to you have to just close the session uh you want to learn more about ik please uh please go to the website sign up for the upcoming session i will be happy to answer any and all questions uh there okay all right thanks again folks and have a very good evening and whenever whichever time zone you are in thanks again for your time bye [Music] you

Channel: Interview Kickstart

Views: 2,599

Rating: 4.9024391 out of 5

Keywords: Navigating Microservices Architecture, Microservices, interview kickstart

Id: k45eUxcQ1nw

Length: 84min 39sec (5079 seconds)

Published: Thu Aug 20 2020