Chandan Singh

Yeah. So, hi. My name is Shandan, and I have been working for three years in Golang. Typically, and also before that, I have 9 years of experience. Before switching to Golang, I was working with different projects based on Python and also cloud-based technologies like AWS. So mostly, I was working on AWS cloud in conjunction with different ecosystems. For example, I was working on my first project, which was basically creating an analytics platform. There, I was using big data analytics tools. Like, we were creating an analytics platform using Hadoop, and it was a VM-based deployment back in 2015. Then, I started working on one of the projects, which was doing machine learning algorithms, productizing machine learning algorithms. The main challenge that we faced was the amount of data that we were handling was huge. Just to give perspective, it was around 500 GBs of data. And, this was heavily compute-heavy operations since it was machine learning algorithms, and the completion was having during using optimization servers, and there, my responsibility was to get the code from the machine where the data scientists or the ML engineers and convert it into a scalable fashion using different cloud technologies like ECS, Python, and Flask. Post that, I started working on Golang where I got a chance to work on creating custom controllers and custom resource definitions for Kubernetes. There, currently, we have deployed or developed seven to eight custom resource definitions, and it's custom business logic for configuring the different third-party applications. This is using the standard or base Kubernetes source code, which involves code generation, code execution, and then handling the reconciliation logic of the controllers. The main objective of this project is the client has a custom, own product, the security product or the application load balancer. And what we do or our controller does is it helps configure the security application slash load balancer based on the CRD resources that are deployed in Kubernetes. And then we are mostly involved in Goroutines and queues. And, we try to use the API server to monitor the cluster. And once resources are available, then the configuration happens on the registry.

System enabled for that. In a microservice architecture, how would you utilize AWS services to enable service discovery for a Golang-based service? How would you utilize AWS services to enable service discovery for a Golang-based service? So if I understand correctly, it's more of a service mesh that you're pointing out to. Typically, a service mesh needs to have a load balancer or API gateway. I could use ALB. And then using ELB, if we are using a virtual gateway, those gateways will be created and pointed to the service of the Golang, or the particular service is written in Golang. And then what will happen is, if the traffic is directly coming to that particular Golang server-based application, then the IP address or the DNS name, which is being generated by the load balancer, can be used as a serving URL to get access to this Golang-based service. If it's a multi-cluster-based instance, then in that case, we need to use an internal load balancer, provided by AWS. Then there needs to be communication between two clusters. If it's a different two Kubernetes clusters, and the client is in another different Kubernetes cluster, so in that case, we can use the internal load balancer to communicate with this Golang-based service. Thirdly, in service discovery, we can also use the fact that there's a kube-proxy. So, in that case, using AWS service doesn't make sense because you get service dot Namespace.svc.cluster.local or whatever is the domain name of that particular cluster. That DNS can be used for getting services from a Golang-based application. So that's one use case which I can think of. Secondly, if you want to be very cloud-heavy, in that case, we can use the Elastic Container Service, which provides better integration with AWS CodePipeline. So that's one thing which we can use. And on top of that, I think we can use STO or Linkerd.

Describe a process for migrating existing Go microservice to AWS serverless platform with minimal downtime. So, a, I'm assuming that this particular cluster or this particular application is already running on a micro on a container-based platform. It could be Kubernetes or it could be Docker or it could be any cloud-specific services or it could be in-house, on-premise application. So, first, we can deploy our application on the AWS platform. We can use Elastic container services or EKS, which is Elastic Kubernetes Service. There, we can run this particular application, and that depends on which platform you're using. Now, let's assume that your traffic is being served from this. I can think of two solutions. The first is that there needs to be a rolling update kind of a pattern where the application is ready on the AWS platform and ready to serve external traffic. In that case, you can use an existing load balancer and slowly and gradually migrate the traffic from, let's say, putting a weightage or a rolling update where some of the traffic goes to the application running on-premise and the one running on the AWS or EKS-based platform. This will happen in that, even if you're there would be two versions of the same version but with two replicas. One which, if the traffic is in a round-robin fashion, some of the free requests will go to your on-premise application, and then that will go to your container platform on AWS, which is also the application running on AWS. So once this happens, and the sanity check confirms that the traffic is working fine, then you need to change the load balancing or the traffic from which the traffic is getting routed. You can either change the entire routing or you can, if you're using a load balancer, change the weights of that particular route. So, this means that the entire traffic will be routed to the AWS platform. You need to take into consideration the sessions. The session needs to be maintained, so you need to route the traffic. You need to first stop the traffic to the current application running on-premise and then all the traffic back to the application running on the AWS platform. And this would be initially a blue-green deployment, typically, but with the same versions, not different versions. So, it's the same version which is starting on-premise and on the Amazon platform.

When refining a Go service, a practice to avoid tight coupling between services is to implement a microservice architecture. Typically, in microservices, the databases are running on a different server, whether it's serverless, managed databases, or a container platform. This means that the data being processed is getting processed from the same databases. If two services are using the same databases, you can bifurcate or break down those particular services into much smaller services. Internally, they use the same database, but the APIs or endpoints are different for different services inside a particular application. This is one way to avoid tight coupling. Another way is to consider the scope of the application. If it's a polyglot application where multiple languages are being used, you can use different types of APIs. For example, it could be a REST API or gRPC. If it's internally being used, gRPC would make more sense because it's faster and the implementation and integration are seamless with different languages. In terms of flexibility, if you want to expose it to the outer world and make it more user-friendly, you may go for the REST API or the REST services. These are couple of ways in which you can avoid tight coupling. You can also use the same load balancers but the same ingresses of gateways can be safe, but the routes to different protocols can be provided. You can provide path-based container objects, for example, by using ingress or gateway APIs to traffic data or particular URLs to different containers based on the URLs being accessed.

What are the benefits of using AWS Elastic Container to deploy Go microservices, and how would you leverage it? So, first of all, AWS container services is a managed service. Right? So, this gives you flexibility that you don't have to worry about the maintenance of the underneath host OS, that is taken care by ECS, as soon as Fargate. So if you use an Elastic Container Fargate, then you are, then the maintenance of the platform is owned by Amazon and not with the user's perspective. So OS patching and OS updating is the purview of Amazon and not with the user or the end customer who is using the service. And secondly, it has tighter integration with other services. So you get logging, metrics, inbuilt with ECS, and also get integration with and load balances. It could be network-based load balancer. It could be application-based load balancer based on the level of, I mean, it's if it's mostly load balancers are of type L seven, so application load balancer. So in that case, you can leverage this to directly serve your application. And since this is connected directly to the load balancer, you can have you can create Route 53 and have their own zones. And also you can use, manage, you can use certificates as well inside this. So you can use the entire AWS tag for using this. Now how do you leverage it is, basically, we need to first create a container of the microservices. Once the container is steady, we need to push it to it could be a public repository or it could be Amazon registry. Once that registry is there, once the code is pushed up, that particular container is pushed to the particular image registry. Then we need to use the container Elastic Container Services to run the particular to point it to the particular image history and provide the endpoint of the particular application. You can also use data encryption using data encryption strategies in containers. And you can use KMS for storing your databases or credentials, which is since super sensitive and credentials using which does not present inside the repository, from the database name or a key or API key, something like that. So you can use these integrations with KMS. And once it's there, once the EKS is once you provided the endpoint, the application will start running, and the load balancer will be used to serve those applications. And also the host is managed by the AWS, so you can on the fly change the specs of the host on which the container is running. So in this case, you can go from I mean, I have seen customers I have switched the host on which the container is running from 32 GB to 64 GB to 128 GB based on the workload.

What are the most critical aspects to consider when designing a Go Microservices for serverless architecture on AWS. I haven't worked on Go Microservices, yeah. So I'm unable to answer this question. But, if I just give a perspective, if I'm understanding correctly, you need to deploy logging, tracing, and event-based triggering as the way to go forward for.

So, like, which is supposed to run along with intent in asynchronously. So, in this case, the first issue I see is if you just write this inside the main, this won't have any output, and you will just get the launch the task info, but not the actual process or task won't even be done because goroutine is not having any kind of a watch or a weight mechanism or the to like, for example, if we were to run every cofunction, we need to have a mutex based counter. For example, you can use wait groups dot add so that it spawns the particular go functions and waits for those functions to get executed. So if you want to run multiple of such of these, if that's the condition, then in that case, you need to have multiple go functions with the same long running tasks in a loop. Sorry. In a go for go routine with a wait group. And, once you need to pass this wait group option, that particular parameter inside this Go func. And once this process is long running task is done and the task gets completed, you need to mark the wait request done so that the counter of that particular or the counter of the wait groups decreases. And, that means that the code of the or the coroutine has completed, the verification. So you can use wg.10 or you can just use w. Yeah. So that would be one thing. And, secondly, this go process itself is a long running task itself is not, is a single process. So if you want to launch multiple process of the same, then the same pattern needs to be applied. So for go process, it should be go func, and then followed by that, you need to have the go func will have the anonymous function would have its wait group. Then you need to have a wait group declaration inside the anonymous function, and then we need to pass wait groups as a parameter. And then in the process long running task parameter, you need to do defer wait groups dot done so that multiple processes can run at the same time. And there are lots of multiple functions which just need to be executed, and this

The code that processes there's a bug reported that it's not really processing. Function handler request takes the weight group. We are taking that weight group. We make a channel of stock type request, and its buffer is of size 100. Okay? It's not processing the request concurrently. So, we opened the request. We first thing is that you request the request, I don't see requests. Since it's a receiver object. The request itself is not getting passed in this case. So, like, the handle goes handle requests will request will process a request, but the input of this request is unavailable. So we need to put the request pointer and then whatever request you want to process. I mean, whatever is the process body, it's the request, like, whatever is the parameters required inside the request, it should go in the request struct. And that request that needs to be passed to this particular Go handle request so that it can be processed. So that is, I think, the main issue. And anything else apart from this? Also, for requests, well, yeah. But it's channels, channel. You can run this channel and then process because this channel, so you need to read and also this request yeah. We can do this thing. Request is getting redundant process. Yeah. This is fine. So we can do this. Wg.dem is also there.

What strategies would you employ to ensure Go microservices complies with framework principles? This is a very broad question. But then just to narrow it down, the framework should involve the best security practices. So that means the code should be variable limited, and the security scanning of those images should be done properly. That would be my first point. 2nd would be that I would use a heavy, cloud-specific, AWS-specific setup, then we can use code builder, code pipeline, and code commit for deploying the codes. Other tools can be used for creating those images, obviously not with the latest tag. And 3rd, secrets inside those should be used in an encrypted way, so they should be stored inside a Vault or a KMS. I think so. I don't have much idea on Go microservices and what well-architected principles is a very broad subject, so I would need more specifics on what exactly we are trying to do.

How do both channels in the serverless approach using AWS API Gateway? I mean, the So I assume that there's an API gateway. There, we have a Lambda function, which is having Go as its language. So by default, the API gateway or Lambda takes that particular context. Once that context is available, we can use Go channels to read the request coming to the Lambda in the context of a request. You can take that as a channel. It could be it should be buffered, but that based on whether we want to create a buffer object or do read and writes based on this buffer? Buffering would take another strategy because we need to be very specific about the size of the channel. So, for simplicity, we can take that channel. The request can be written to that particular channel. And even if the request comes in, the Lambda code inside the Lambda will keep on processing the requests as and when they come. So the output of that can be pushed to a channel. And if multiple requests are coming, you can take that request and process it. For example, you can have a function, let's say, calculate, and then take the request as an argument. And then whatever you want to calculate, you can do the custom logic and push the code as a payload back to the API gateway in JSON format, obviously using structs and omitting empty fields.

How about AI technology feature into Microsoft's tool?