Ramesh Verma

I have been doing dotnet development for 7 plus years. I graduated from computer science and engineering in BTech in 2016. First, I joined Tata Consultancy Services as an assistant system engineer. There I worked for around 1 year, and my main responsibilities were mainly SQL and C related. There were two parts of the job. One was related to an AWS MVC application, which I had to manage, and the other was related to data warehousing in which I had to use SQL. So after 1 year, I switched to a product-based company in Nirvana Solutions, and I started working as a software developer in C# technology. So I have been working there for the past 6 plus years. During these years, I worked on their core enterprise module, which is a desktop application built in WPF and WinForms. In terms of domain, the main domain is finance. Mostly, the enterprise module is for hedge funds to manage their portfolio, order management system, general ledger, allocation, closing, and all of that. So I have worked on all of these modules throughout my career. I have been promoted twice, once from software developer to senior software developer, and after that, I am currently working on technical lead. So I am managing around 5 people under me, and my day-to-day tasks basically involve a 3-week sprint, so I do the initial analysis of the requirements, creating different users, creating different tasks and user stories, calculating the story points, all of that. After that, there is development and basic dev testing for these requirements. And other than that, I also have to do code reviews for all of the people working under me. So these are the main day-to-day tasks. In terms of my main skill sets, I have been since I worked for 6 plus years in C#, that is my main skill set. I have not worked that much on web applications, but I have worked on web APIs. In terms of cloud, I have mostly worked on AWS, not much on Azure or Google Cloud. So, that is all about me.

When it comes to optimizing any SQL query, first, you have to go through that query and find out if there is any bottleneck in it. If there is any view being used in that SQL query or any join, which is the root cause of the performance issue. Just trying to use standard ways to optimize a query might not yield great results because you will not be targeting the core problem in that SQL query. So whenever you have to optimize the SQL query, I first try to go through that entire query, check which part is taking longer time, and how we can optimize that part. For example, you can replace a direct join to a large table with a temp table. Maybe you are using a WHERE clause on a column multiple times, but there is no indexing on that. You can add indexing to the table. After that, you can check the execution plan of the query to see how it is being generated because you might find some things that you can optimize to have a better execution plan, which will result in a more optimized query and better performance for your SQL query, which is being used in a.NET application.

In my career, I have not actually implemented a CICD pipeline through AWS. I have done it through Jenkins and, as a DevOps, I have experience with it. So, the steps cannot be that far off. Mainly, what we have to do is go through the manual process. If you have to do it manually, how will you do it? You have to go through those exact steps and create a documentation or list down all of the steps you have to do. Then you have to go through each of those steps one by one. For example, if you have to move data to a particular file or build a particular project. All of these steps can be found in any application. These steps were available in Jenkins, when I had to build that pipeline. After that, we switched to Azure pipeline and all of these steps were there. So, the crux of implementing a CICD pipeline is to come down to the manual process first. If you don't have any automation, how would you do it manually? You have to list down all the steps. And once all of those steps are listed, you can start creating your pipeline in AWS or any other tool. Then, you have to go through those steps one by one and find the task or extension available to actually do those steps. Usually, if you can't find anything to replace, batch files work really well in that case. We can perform lots of things from there. In terms of a dot net application, most of the steps like MS build, rebuild, or clean solution are fairly easily available in all of those different pipelines. So, if I had to implement the CICD pipeline for a dot net application in AWS services, the steps I would take are to do the MS build and generate the EXE file, which should be fairly easy in any available tool.

So, basically, how Docker works is that if your.NET application has any dependencies, it is helpful to provide a container that contains all of those dependencies. Sometimes, testers and developers have issues, like it works fine on the developer's machine, but not on the testing machine. Even after spending multiple hours on that, we find out that a particular software or tool was not installed on the testing machine. Docker kind of minimizes these issues because you can ship your application along with all of the dependencies. So, when providing your application for testing to the QA team, you can provide an isolated testing container with all of the dependencies. So, we can be sure if they face any bugs. We can just get a copy of the entire Docker container and run it on our system, and we will know exactly what is happening instead of trying to find out the exact steps they were doing. If anything was missing, we can debug again and again, and if we're still facing a scenario where we're not able to reproduce the issue, even after QA is helping us. These kinds of issues get minimized by Docker, so that you can be sure, at least environment-wise, there is nothing missing on the testing machine. When shipping a.NET application inside a Docker container, you know that all of the dependencies are available there. So, whatever the bug is, it should be related to the code, and you should be able to reproduce it easily.

In.NET, SQL transactions work the same as the transactions that are inside a SQL procedure. So whenever you have two separate databases or multiple databases storing different data, and based on one update or insert, you have to update inside a different database, it is very good to use SQL transactions. I will definitely use SQL transactions in such a case because you want to roll back the earlier transaction as well in case the second one fails. For example, let's say there is an online ordering portal, kind of like Amazon. So there are two parts. One is posting that particular customer has ordered this project. And second is updating two databases in which we display the amount of product we have in our warehouse. So if a particular order is placed, but the count is not updated, it will create an issue later on when you will be showing that you have that product, but it will be missing in your inventory. So to prevent these kinds of issues, SQL transactions are very good because you need to roll back in case of any bugs in the second transaction so that the first transaction also gets rolled back. Or if I go with the second example, if you are doing a generalizer kind of thing, there are multiple things where you have to update two things at the same time. If you are updating a transaction for an equity purchase, you have to do, like, I purchased 10 units of equity. And another case, this cash gets reduced. So if you don't implement SQL transactions or rollbacks for the first change, then there will be a discrepancy in the two details, and your final tally will not match up, which is very bad. So in those cases, you have to use SQL transactions and implement a rollback in case the second transaction fails or you can say the second update or insertion fails. So that the first one is not added. So that at least you have a matching scenario, and you can do the transaction again to match up finally.

So, if you want to run a.NET application in AWS with high availability and disaster recovery, there are multiple system design concepts that can be used there. Most of them are related to scalability. But in terms of availability, you should have multiple backup applications hosted so that if one of them goes down, you can shift to another. So, this was the main one. Other than that, there are creating database backups as well so that in case anything happens to your primary database, you should have a backup available to restore and make your application highly available. So, in terms of making your application highly available to your customers, you have to check where your customers are. And in case your customers are available on different continents or different countries, you should try to get servers on those locations as well to improve the performance of your application. Other than that, I think, yeah, these are the main points that you can do to make your application highly available in case of any kind of disaster recovery. Having database backups, having those on separate continents so that any kind of disaster does not impact your data. And even if you're having an AWS.NET application, it's always a good idea to have a local copy of your database and your application so that in case of an AWS downtime, you can use your local service for a temporary basis to keep your application available to your customers.

Given the sequel code snippet, I would manage getting an audio with Okay. So this is an update statement. Update employees set salary equal to this where employee ID equals this. Select * from employees where employee ID equals this ID. So I'm not sure what kind of issue could be faced when executing this statement. I mean, as long as all of the column names are fine and the end goal of this statement is not mentioned, so I am not sure how what could be the issue with this statement if we were given an error. I mean, select * from employees where employee ID could do this. I mean, if the employee ID is unique, we are just incrementing the salary by 5,000. So I am not sure what could be the possible issues other than I mean, there can be SQL injection into the ID. So if this query is actually being directly used in your.NET application or somewhere else, there can be a chance of a SQL injection. If that is the case, I would definitely move to use a SQL procedure or something like that to ensure that there is no SQL injection being done on the actual query. Other than that, I don't think I can see any kind of issues here. And then one more issue I can notice is that the 5,000 is a hard-coded value. I mean, depending on currency, one candidate might be getting paid in USD, another might be getting paid in GBP. In those cases, I think it should be better to pass some kind of check to know the current currency and conversion so that can be updated accordingly.

This is a very well known problem. Whenever you try to get a particular instance, it's possible that if two threads are trying to access your instance for the first time, what will happen is both will check if the instance is null, and the instance will be null. Then both will go inside and create a new instance. So one of those two instances gets lost. So it's not purely a singleton because two instances are getting created, although one is being used. That's the kind of problem that usually is faced when doing this type of singleton implementation. If you have to make it thread-safe without using the.NET lazy infrastructure, the straightforward answer is using double locking. In that case, first, you check if the instance is null. If the instance is null, then you create a lock on a private object. So, first, you check if the instance is null. If the instance is null, then you create a lock. And inside that lock, you again check if the instance is null. Using that implementation, you will be sure that you are locking, so only one instance will be created, and you are again checking inside so that you don't face any situation where both check if the instance is null and key. Secondly, this is waiting for the lock, and when it goes inside, it creates another instance. Because once it will get inside the lock, it will again check if the instance is null. If it's inside the lock and the instance is still null, it means it's the first thread there, and it will create the instance. The second thread, which gets inside the lock, will again check if the instance is null. But the instance, this time, will not be null because the previous thread has created an instance. So, in any risk condition, you will always be sure that only one instance is created.

We have a.NET application on AWS experiencing latency issues with Docker configuration code, potentially minimizing latency. I will have to read up on that.

Real-time data analytics platform. So, when we're doing data analytics, the first step is always about creating a data warehouse with your historical data. If we have to do data analytics for a.NET application, I first have to create an ETL architecture inside AWS services, where we extract the entire data from our main transaction DB because we can't do real-time analytics directly on our transaction DB as it will be used in day-to-day operations. So, first, we have to set up an extraction service. After that, you have to transform the data into the needed format for warehousing and data analytics, say, converting daily data to combined data or union data so that you can do performance analysis or different kinds of data analysis on your data. Finally, when all of this conversion is done, you can use AWS Lambda to query your data into different kinds of formats or use Elasticsearch to do another kind of extraction for more data. And I'm not sure what kind of visualization tool AWS provides or if there might be other visualization tools that we can link to our AWS data quickly to create a data analytics platform for our application.

So I am not worked a lot with Azure Cloud, so I don't have any idea what is Azure Cognitive services.