Lerin muthuraj

Do you help me understand more about your background by giving brief introduction of yourself? okay. So, my name is Lauren. I am a DevOps engineer and a cloud solution architect, who a solution provider for any cloud solution needed for many on premise to cloud migration stuff. So that area is of my core specialty and, involving into CACD progress of any infrastructure and architecture, and maintaining databases and providing application support to troubleshooting, and maintaining, like, a highly available and a highly scalable environments, for the client, it's my sole, like, my main duty here, as my as a engineer. Yeah. That's it.

Secure AWS. To outline a secure AWS architecture for a new application. There are multiple ways to create a secure architecture. The first one is to go with a public and private subnet. We should have both public and private subnets. In the private subnet, we should have the servers and any Kubernetes clusters. Whatever we are hosting, the application should be in a private subnet, and the public subnet should have a bastion instance or a load balancer, and all other stuff should be in the public subnet. It should have an application load balancer as well as a network load balancer to use WAF rules. We can also use CloudFront to provide additional support from DDoS attacks and other threats. So, this is the main architecture I can use, the main thing is to use public and private subnet concepts, so that the private subnet will be accessible only to specific people who have access to it, and it will be exposed to the world only through the load balancer.

In what scenarios would you suggest using Terraform instead of AWS CloudFormation? Okay, Terraform is a tool. CloudFormation is primarily used for AWS related resources. So, in any case, we are using some other resources like RabbitMQ or other things, apart from AWS that we need for our projects. Right? So that may be some dependencies that we need to do an infrastructure that may not be inside the AWS provider services. For that, I would go along with the Terraform. Terraform has more than 100 service providers. So, we can use that. It has providers for Kubernetes as well as OpenSearch, Grafana, and everything else.

Application monitoring for Kubernetes can be done two ways. We can use the Kubernetes dashboard to look at the metrics, and I can also install a CloudWatch agent in my Kubernetes cluster. So, that will give a detailed analysis of the metrics of the parts and what CPU utilization other parts are taking, and I can direct the logs to CloudWatch. And, the logs, I can take them to CloudWatch, and I can check if there are any part failures. By checking the logs, I can get to know how the part failed. So, why is the part getting restarted again and again?

Do you ensure the back-end compatibility of a Java application in the CACD process? And a new version is getting okay. How did you ensure back-end compatibility of a Java location? I'm not sure how to do a patent compatibility check, but what I would do is, So when a new version of Java that we are using is being released, it needs to be supported while starting the application. And it needs to be started without any errors. The API calls that we send to the back end should provide a proper response that we can use. Once the CACD process is completed, we can start the site and then use Postman to check the API calls. If the API calls are properly working, we can ensure that the front end is properly connecting to the back end. We can also integrate SonarQube and other tools to check if the proper versioning is there within the front end and the back end.

My experience implementing high-level system design with an emphasis on lean agile principles has led to fewer production errors. In agile methods, we're neglecting production errors by eradicating them in the staging environment itself. So, when moving into the production environment, we can minimize errors and reduce downtimes. To maintain less downtime, we should have a highly available and highly elastic environment, which has multiple servers in multiple regions under load balances, with automatic failovers. Once one server fails, we can reroute traffic to another server. This is the best solution for maintaining fewer production errors.

Public class Test { private static String isPublic static void main(String[] args) { String public static wide String asArgument = System.out.println("Hello"); } } But they have not passed any variables or they have not set the starting point for the string that may cause an error. Corrected Transcript: Public class Test { private static void main(String[] args) { String asArgument = System.out.println("Hello"); } }

Replica smudge labels, app, engineering's template. Okay, that is a labeler. You have mentioned an NGINX and an NGINX one label. The label should be similar. We cannot mention two different labels in an application. Corrected label should be: - app: engineering This will prevent the confusion and inconsistency in the labels.

Version control and deployments in multi cloud environments. For version control, we'll be using Git. Any branching strategies will be using proper branching strategies across multi cloud environments. We'll have one GitLab repository that we can use to store the code. For multi cloud deployments, we'll use a CICD architecture, and we'll maintain centralized repositories for the images. From the code repository, we'll get the code, and we should have the Dockerfile or something that shows how to build the code, in case of Kubernetes. There might be monolithic builds for Kubernetes while building the image. We should have the Dockerfile inside the version control. Jenkins will build the image and push it to a centralized repository, which should be used by the multi cloud architecture. By this, one image will be shared across the entire multi cloud, regardless of the cloud - Azure, AWS, EKS, AKS, GKE, or any other. They will fetch the image from the same container repository. So, the version will be handled the same across all the environments in all the multi clouds. This also applies to lower environments, such as staging, testing, or development servers.

What steps do you take to perform root cause analysis when your application experiences issues? How will we prevent it from happening in the future? Okay, the basic thing for us to do to troubleshoot the root cause is to check the logs for any errors or exceptions that have been passed to the log side. We can check it from any monitoring tool, or take it from the application logs or the pod logs, or the container logs. This will help us understand the kind of error that occurred. Is it an application-level error? Is there any functional error? Or is there any application downtime error or network error? We can separate the errors in this way, and then proceed with the troubleshooting. If there is a network error, we can check the network. If the part is not exposed correctly, or if there's anything wrong with the load balance, or if there's an issue with certificate renewal, we can check that too. From the application side, if the API call is not getting properly, or if any put request is not being posted properly, we can check that too. And in case of any deployment failures, if there's any file missing, or if the image pool might be missing, the part may fail to pull the image from the container. So this is what we can check from the logs and other monitoring tools.