Purushottam Dike

Hey, calm down. I think we can have a conversation. Yeah, with the Gather AI, I will learn a lot of things from scratch for new emerging technologies, DevOps, machine learning, and artificial intelligence. And I've heard about the Gather AI on the internet and learned that the company's profile is pretty much employee-friendly. And I like to work in an environment where employees are treated as lovely. That's it.

With respect to hosting the application with Kubernetes versus a VM, I will definitely go with the better approach to learn the things, which is our requirement, and whether the application is suitable for a monolithic or microservice-based architecture. That's the things we need to consider, how much CPU and how much load that virtual machines can handle, and with respect to Kubernetes, if there's a microservice-based architecture of that application is possible, then we will definitely go with Kubernetes and not with the virtual machine, so it's monolithic architecture, and the application size is very big, and we require special attention to the virtual environment for that particular application. In my organization, we have a lot of virtual machines as well as a Kubernetes infrastructure, so it basically depends on the requirements of the organization. If you want to choose for the microservice-based architecture, then you go with Kubernetes; otherwise, you should use a VM.

Why do you need a route table and when do you need a route table? When we are working with any private VPC and we need to have subnets, and subnets contain a route table, that route table is used whenever we want to allow or deny access to particular routes. We can say it's internet-facing or network-facing IP address, or we can create rules that can handle a particular port or allow ingress or egress traffic. That way, we need to have a route table, and the route table will be connected to the subnets, and the subnets will be connected with the VPC. This is how the infrastructure as code with a private network will work. So, this question, why do you need a route table? Basically, a route table is used to have accessibility of a particular application to the external world or to the internal through an API or through any databases. That way, you can support port forwarding or port mapping with a route table or provided with CIDR blocks. And when do you need a route table? Obviously, if you want to allow access or deny access to particular routes through particular CIDR or particular port number, then you use it.

Yeah, how database indexing works with respect to indexing of databases, we'll have MongoDB, and in my organization, there's MongoDB, PostgreSQL, Redis, and we have a lot of databases. We have indexes in that application. An index is nothing but allocating records based on indexes in the database on a particular database, which helps us retrieve a particular table, column, or row of a particular table. If it's from a NoSQL database, like MongoDB, we have collections with indexes and index numbers, such as an underscore ID, which takes the thing as an index of that particular record. That index is used to identify the record for a particular use case. So, whenever we're doing any CRUD operation, like create, read, update, or delete operations through the database, indexing like when we're removing a particular record, it will ask us which index or ID we want to remove that record. We're using indexes for that matter. Yeah, that's it. Thanks.

Yeah, 10 things, top 10 things that you care for to keep the system secure. Then first, I should avoid external access to the internet, to instances. Second, I will allow SSH ports that should not communicate directly from port 22, that's one security mechanism. Third, I can say about allowing two-factor authentication with the following, like MFA with the AWS account. Fourth, I can say allowing, denying the access of ports, or disabling the ports that we are not using. And another one, the application should not communicate with external works.

Whenever I face challenges with autoscaling a Kubernetes cluster, VM, or instances horizontally, the challenges I face are storage issues with the database, and the storage is not enough for scaling the application. CPU and memory allocated to particular pods are not enough. We fix these challenges by attaching or increasing the size of instance storage. With respect to EC2 instances and autoscaling, I prefer the custom autoscaler. For AWS autoscaling with HPA, we create separate instances, which takes more time, affecting the application's performance. This is bad for the user experience. Autoscaling with EC2 instances or VMs is challenging in terms of performance, but it can work if you have a sufficient number of instances.

How did you manage the DB changes that the developers want to deploy at the production? Yeah, with respect to managing the DB changes, we're creating a planned CM, which is change management. So, with the change management, we have a request process. With respect to that request, we have a plan for seven days, and then we get approvals from various engineering managers. Those managers give approval to the tickets and the CM, and then we manage to upgrade or update the databases, database instances, database servers, or VMs. To answer your question, we're doing planned change management. That's the thing.

docker build -t <tag>. and check True, except Exception as e: print(f"Docker build failed: {e}") BuildDockerImageTag. Ok, so there is one function called build_docker_image and it takes the argument as a tag. And once we call, there is one import, there is one import, one subprocess, post_library and we call the build_docker_image function and in that function, we have try except and in a try, we have subprocess and subprocess.run and in that subprocess.run, we have docker build -t and then tag and yeah, and dot, ok. So in that, in that check True, so it will work fine and except subprocess CalledProcessError, print docker build failed, like in and I think this code will work, might fail the building process. Yeah, this code, I think it will work and if it is not, then there might be the problem with exception that subprocess CalledProcessError and yeah, that's the thing.

Okay, how to deploy a multi-tier application using Terraform with high availability in both AWS and Azure environments. With respect to multi-tier application deployment using Terraform, ensuring high availability is crucial. We should have existing infrastructure ready and up and running, then create a parallel infrastructure with that. For a multi-tier application, like an application interface, database, and user interaction, we have various configurations. I'm considering three tiers: application level, database level, and user level. When deploying a multi-tier application with Terraform, we must use special workspaces. With respect to workspaces, databases should be separate, and application code or application artifacts should be deployed in separate instances. Communication between them will be handled through a network of Kubernetes, like an internal network with ingress and nginx controllers. With Terraform code, first, we need to create a database instance, such as an RDS instance in AWS. We can use RDS with PostgreSQL or MySQL. After that, we'll create the instance of RDS, create credentials, and store the credential in secrets. Later on, we'll create another Kubernetes infrastructure with this separate workspace. The workspace will contain Kubernetes deployments, and the deployment will have a connection with a headless service and continuous ports. Those ports will be connected directly to the database. Alternatively, we can have a direct database connection with the ingress, and whatever request we get with the ingress will be transferred from the port level to the container level, deployment, and then database with the endpoint. For Azure, we can use Azure pipelines to deploy an end-to-end application from scratch to data, from database to application, or whatever layer we want to use. That's it.

Your web application on Kubernetes repeatedly crashes due to memory leaks, how would you diagnose and resolve the issues and which metrics would be vital for monitoring? With respect to Kubernetes crash reports, we have Kubernetes pods, which are crashing because of a memory issue. Okay, so we can create another sidecar container in that sidecar container, we can have their monitoring logs that can be of Prometheus metrics or application metrics for Kibana. So we can have any monitoring mechanism like with Kibana or Prometheus and then Grafana for the graphical representation of the data and Kibana Elasticsearch to show the data with the actual logs of the application. And the crashes due to memory leaks and diagnose and resolving that issue, we need to check how much memory and CPU we have allocated. At the initial level, we might have a little slow, but we can say limit, whatever the limits we have set for the particular pod to grow up to that particular memory or CPU that we need to check and we need to increase by using kubectl commands, we can use kubectl describe pod and deployment and deployment contains pod. So that thing we can describe and get to know that this issue is happening and we can change the namespace or we can say to solving that issue, we can increase the pods or we can have HP, horizontal pod autoscaler or vertical pod autoscaler and third option we can have, we can say custom autoscaler like KEDA, Kubernetes event-driven autoscaler. So we can use event-driven autoscaler to autoscale the issue, autoscale the pods and then containers for that matter. So that way we can mitigate the issue of the memory leaks and the diagnosing, we need to have a mechanism to take the logs by kubectl logs command of the particular deployment or particular pod, yeah, that would be vital for the monitoring. So as I said, we can use application logs or like info, warning, or errors of that particular application and that application will be able to collect and then send those logs to Prometheus for the visualizer and Prometheus will give that metrics to Grafana. That thing we can say and we can use Loki as well if you want to, and there is another solution for monitoring logs, we can have Datadog as well. So we can use our monitoring solution, it depends on our application requirement. So that's it.

What methodology would you apply in a day of life cycle to meet the compliance standard like SOC 2 or GDPR deployment application? Okay, to be frank, in my organization, we are using GDPR compliance and SOC 2 compliance for the application. So, with respect to GDPR compliance, that application should have monitoring in place, logging in place, backup and recovery of the databases should be in place, and security of the application should be in place, and everything will be monitored and controlled through audits of the application. The audits should be conducted with a proper auditing organization. These are the things we need to consider while developing any application from end to end. In the day of life cycle, we will have continuous integration and continuous deployment and delivery. In that delivery part, we will have a life cycle, and in that whole part, we are using a life cycle policy and that life cycle with respect to GDPR. So, we need to follow, like we generally do in our organization, we call some agreements, such as SLAs and SLOs, and whether those agreements are followed or not, that should be documented, and that document will be available through audits and our company's processes. Yeah, that's it.

What approaches would you take to build a code to production pipeline for AI driven applications using Kubernetes? We would take a modular approach to building the pipeline, breaking it down into smaller components that can be easily managed and maintained. First, we would use a CI/CD tool like Jenkins to trigger the pipeline when new code is committed to the repository. The Jenkins pipeline would then use a combination of Ansible and Terraform to provision the infrastructure and configure the containerized environment. The Ansible code would be used to configure the infrastructure, while the Terraform code would provision the necessary resources, such as compute and storage. Once the infrastructure is ready, the pipeline would use Docker or Podman to create images of the AI application, which would then be stored in an ECR repository. The pipeline would then use Kubernetes to deploy the application to a production-ready environment. This would involve creating a deployment configuration, which would specify the number of replicas, resource requests, and other settings. To ensure that the pipeline is efficient and scalable, we would use a combination of containerization and orchestration tools, such as Docker and Kubernetes. This would allow us to quickly spin up and down environments as needed, and ensure that the application is always running in a consistent and reliable state. In terms of specific tools and technologies, we would use: * Jenkins as the CI/CD tool * Ansible for infrastructure configuration * Terraform for infrastructure provisioning * Docker or Podman for containerization * Kubernetes for orchestration * ECR for image storage We would also use a combination of automation and scripting to simplify the pipeline and make it easier to manage. This would involve using tools like Ansible and Terraform to automate the provisioning and configuration of the infrastructure, and using scripts to automate the deployment of the application. Overall, our approach would be to use a modular and scalable pipeline that leverages a combination of containerization, orchestration, and automation tools to quickly and reliably deploy AI-driven applications to production.