Vyas Reddy

Yeah, myself, Yas. I have 8 years of experience in software development. So I started as a PHP back-end developer, and now I shifted to Golang. And also, I worked as a lead engineer in one company. So I used to lead the front-end team, which used React, and it was a team of 5 to 8 people working individually, with goals and developers at the same time. And yeah. And from the last couple of months, I'm focusing on cloud and Kubernetes. So I'm exploring how to automate Kubernetes operations using Golang operators. So, creating resources or automating resources for Kubernetes users. I'm exploring into that space. And also, I'm interested in the web 3 space. It's like using Golang's Ethereum SDK. So I used to create small contracts. I'm working on some personal project. Yeah. And also, I do freelance in my free time, like creating any mobile applications using React Native or Flutter. So yeah. That's it about myself. Thank you.

To be honest, I have not used MongoDB much. So I'm familiar with Postgres and MySQL DBs. But for DB migration and everything, using Golang, we can easily use the SQLX library. So we have the migrations file And we can do seeding or something. So using the SQLX package. And also, you can go with the Go ORM. Using Go ORM, we can connect to any DB, not only SQL drivers. We can connect to the MongoDB drivers or Amazon DynamoDB drivers. Anything we can connect. So we can have a migrations folder. So we can see the migrations DB migrations.

Yeah. Basically, let's say if you're writing an application in our microservice architecture, we'll focus on single functionality, so we can say single responsibility in these data principles. So we'll focus on creating, let's say, a login or authentication model. We'll stick to that part, and we can easily scope and scale the login or authentication service using Kubernetes by creating ports or scaling the ports, replicas, and everything. So we can route the traffic to that service using a load balancer or ingress or egress. So, using this, we can create the basic structure so that we can evolve into many other services and scale to a Kubernetes structure. And also, we can use even given structures. Let's say, in microservice architecture, it's very hard to find the map of all services if you're maintaining hundreds of microservices. So it can be tough to keep a map for that service discovery. Instead, I prefer even architecture. So we can easily track all the publishers or subscribers using topics. We can list all the topics at one place. And by that, we can scale the application very easily, and it's a fault tolerance. Even if anything happens, we can easily retrieve the messages and serve later.

Yeah. Nishta has discussed about even given architecture. So it's a kind of, better way and industry standard architecture. So if we can follow, we can easily follow using in Golang, we can have the NASH streaming. They are giving many features using Jetstream. We can store the persistent messages for longer term. Whereas in RabbitMQ, it's very hard to store the message. I mean, persistent is not there. So and, also, let's say, we need to be careful about DBs actually. There's a concern when you are creating a microservice, so we need to make sure that, let's say you are creating a login or user authentication database. So we can make only user stable or authentication DB deployed separately, not in the centralized DB. So we can easily scale along with the application. If we distribute the DBs also in the same way of microservices, it's easy to scale. And to maintain data consistency, again, we need some Kubernetes administration, so we can find that if we need to make the changes accordingly for deployments or something. So for that, again, we can write Kubernetes operations. Let's say something is changed, so we can easily automate the process using the Kubernetes operations. I will explain that.

Yeah, see, basically, let's say, on the other hand, if you're getting any workloads, I mean, you know, what I can say is. So I'm not familiar with Kubernetes operations, but I can say using these patterns. Right? So, scheduler patterns, at a particular time, we need to scale the application. At a particular time, if you have a specific schedule, for example, at 9 o'clock, you need to scale the applications, you know, into more instances. We can use that scheduler pattern. So, using that, we can easily scale the applications at this particular time or different times. And also, I said, using Kubernetes operators, we can use custom controllers to easily achieve these patterns. We can easily scale instances using these custom controllers or CRDs. Yeah.

Yeah, see, 0 downtime is a very difficult job for any Kubernetes administrator. So that's the kind of challenge SREs came into the picture to address. And I can say using these operators and everything. So we can make sure, for example, if any bug occurs in production, we can easily access a kind of web playbook. I can say the Kubernetes operator, using that operator. So we can say if anything crashes, we'll try to reset our desired state. So, let's say we have three replicas. If something happens and something crashes, this operator will make what we call increasing our replicas. It will always try to match that desired state. So, yeah. And using this, you know, any Kubernetes team has inbuilt logic, which is called a controller. So they always match the same disaster. So for that, we need to have Kubernetes definitions. I mean, in EMLPulse, we'll have a reach-out policy always. Or, you know, if we keep it enabled, it cannot be recovered. And also, we can have a threshold limit easily, at so we can make sure, for example, Kubernetes tries for three times. If the port is failing, try to recover the port for three times, so we can make that threshold limit. We can keep that threshold limit. Yeah.

It's simple. So, before deploying our Go application, we can have that raise flag. So, we can while building the Go build or something, so we can easily have the raise flag. So let's say if you use that flag, it can say whether any data risk conditions are there or any coroutines are writing to this same resource, same variable. So it can easily find out the data risk conditions using that flag. Yeah. Again, so MongoDB collection. And also, we can make sure for this data res condition, we can use a mutex package. We can lock and unlock the threads or you know, the Go goroutines. Let's say if you are writing to the same resource, same variable or same kind of DB or something. So we can log that particular goroutine. Right? So we write log or we can use a read-write log. Yeah.

Audio design and optimize gross service to handle a large supercomputer. But what I mean is that we can have a rate link or in an API gateway. So before that, we can let's say before our application, we can have that rate limiter. And so we can let's say if our microservice is able to set for 200 requests per nanosecond or something. So we can have rate linked up for that. And if the let's say 300 requests came, but our service can serve only 200. So we can make that remaining 100 requests in some cache or something, and we can serve later in the next throughput. So, basically, we can have this rate limit if we are getting a large number of data. On the other side, using message queues is always a good choice for this kind of data. I mean, large amounts of data. So they just subscribe and publish the event. And whenever our service is there, it will pick up the event, and it will serve the transactions or anything.

I am not into deploying applications into Kubernetes. But generally, we use load balances for navigating traffic order, using ingress or ingress. And now we have many kinds of SaaS best practices in AWS. We can easily have the AWS load balancer, and we can easily load traffic. Also, now we have the APG. So, Google provides a good API gateway, which manages and tracks all network traffic, and balances traffic, enabling. Yeah, pretty much. I am not sure about this service's measure, or texture, on how to deploy.

Yeah, so we can follow the repository pattern. We can use that to maintain the models separately. And we can mock and easily write test cases using these mocks. If we can easily mock the DB interfaces, we can follow the repository pattern. Using that, we can connect to any DB. We'll stick to the data and everything in the models. Through models, we can get from repository to service and then controller. So, using this, we can differentiate the best at the model side. We can have the repository structure with repository model. We can write all queries or something. Let's say, MongoDB. We can write all the necessary things in the MongoDB repository and SQL repository and then service.