Showing posts with label .NET. Show all posts
Showing posts with label .NET. Show all posts

Thursday 26 January 2023

Serverless computing

Serverless computing is a cloud-based computing execution model in which the cloud provider dynamically manages the allocation of machine resources. With serverless computing, the cloud provider is responsible for provisioning, scaling, and managing the servers that run the code, rather than the user. This allows developers to focus on writing code and deploying their applications, without the need to worry about the underlying infrastructure. 



In serverless computing, the code is run in stateless compute containers that are triggered by events and automatically scaled to match the rate of incoming requests. This eliminates the need for provisioning, scaling, and maintaining servers, resulting in lower costs and increased scalability. 

Examples of serverless computing include AWS Lambda, Azure Functions, and Google Cloud Functions. These services allow developers to create and deploy their code as small, single-purpose functions, which are automatically triggered by events such as an HTTP request or a database update. 

Serverless computing is commonly used for building web and mobile backends, real-time data processing, and event-driven architectures. 

It's important to note that despite the name, there are servers still running behind the scene, the difference is that the provider manages the servers and the user only pays for the resources used (compute, storage, etc) and not for the servers.

Here are a few common use cases for serverless computing: 

  • Event-driven computing: Serverless architectures are well-suited for processing events, such as changes to a database or new files being uploaded to a storage service. This allows for real-time data processing and efficient scaling. 
  • APIs and Microservices: Serverless computing is often used to build and deploy APIs, as well as to run microservices. This allows for better scalability and cost management, as resources are only allocated when an API request is made or a microservice is invoked. 
  • Background tasks and cron jobs: Serverless computing can be used to run background tasks, such as image processing or data analysis, which can be triggered by a schedule or a specific event. 
  • Web and mobile apps: Serverless architectures can be used to build and deploy web and mobile applications, allowing for faster development, lower costs, and better scalability. 
  • IoT and edge computing: Serverless computing can be used to build and deploy applications for Internet of Things (IoT) devices and for edge computing, where compute resources are located at or near the edge of a network. 
  • Chatbot and voice assistants: Serverless function can be used to handle the logic of chatbot and voice assistants, this way only the necessary compute power is used when a user interacts with the chatbot or assistant.

Advantages of using serverless applications in .NET Core :

  • Cost-effective: serverless architecture eliminates the need for provisioning and maintaining servers, resulting in lower costs. 
  • Scalability: serverless applications can automatically scale in response to increased traffic, without the need for manual intervention. 
  • Flexibility: serverless architecture allows for the deployment of small, single-purpose functions, making it easier to build and maintain a microservices-based architecture. 
  • Reduced operational complexity: serverless applications are abstracted away from the underlying infrastructure, reducing the operational complexity of deploying and managing applications. 
  • Improved availability: serverless applications can be designed to automatically failover to other instances in the case of a failure, improving the overall availability of the application.
Disadvantages of using serverless applications:
  • Cold start: serverless applications may experience a delay in response time when they first receive a request after a period of inactivity, known as a "cold start." 
  • Limited control over the underlying infrastructure: serverless applications do not provide the same level of control over the underlying infrastructure as traditional server-based applications. 
  • Concurrency limitations: serverless applications may be subject to concurrency limitations, depending on the platform and the number of instances available. 
  • Limited support for long-running tasks: serverless architecture is best suited for short-lived, stateless tasks, and may not be the best choice for long-running, stateful tasks. 
  • Higher latency: serverless applications may experience higher latency because of the need to spin up new instances to handle incoming requests.
Here are the general steps to build a Serverless application: 
  • Choose a cloud provider: There are several popular cloud providers that offer serverless computing services, such as AWS Lambda, Azure Functions, and Google Cloud Functions. Choose the one that best fits your needs and has good Java support. 
  • Set up the development environment: Before you start building your serverless application, you will need to set up your development environment. This typically involves installing the necessary software and configuring your development environment. 
  • Create a new function: Once your development environment is set up, you can create a new function. This typically involves specifying the function's name, the trigger that will invoke the function, and the code that will be executed when the function is invoked. 
  • Write the code: Write the code for your function using Java. The code should handle the input and output of the function. Test the function: 
  • Test the function locally before deploying it to the cloud. This can be done using the cloud provider's command-line tools or SDK. 
  • Deploy the function: Once your function is tested and working, deploy it to the cloud provider's serverless computing service. 
  • Monitor and maintain: After deploying your function, monitor and maintain it. This includes monitoring the function's performance and error logs, and making updates and fixes as necessary.

Steps to build serverless application in .NET Core
  • Install the .NET Core SDK and the AWS SDK for .NET on your local machine. 
  • Create a new .NET Core project using the "dotnet new" command. 
  • Add the AWS Lambda NuGet package to the project. 
  • Create a new class that will serve as the entry point for the Lambda function. This class should implement Amazon.Lambda.Core.ILambda function interface. 
  • Add the necessary code to handle the input and output of the Lambda function in the class created in the previous step. 
  • Create an AWS profile and configure the AWS SDK for .NET with the appropriate credentials. 
  • Use the "dotnet lambda deploy-function" command to deploy the Lambda function to AWS. 
  • Test the deployed Lambda function using the AWS Lambda console or the AWS CLI. 
  • Add any other functionality, such as connecting to a database or invoking other AWS services, as needed for your application. 
  • Continuously monitor and update your serverless application to ensure optimal performance and stability.

Happy Coding and Keep Sharing !!

Sunday 8 January 2023

Microservice Architecture in .NET

In my previous blog we already discussed Microservice Architecture using Java but today we are going to develop and understand how we can leverage the Microservice architecture using .NET core API, and what all tools we can use to make it Resilience, observability, Fault-tolerance, Monitoring, and Rate-limiting and all other components which are necessary for any Microservice driven architecture.   

Before we move forward let's review some PROS and CONS of having Microservice and Monolithic architecture.




To start with let's build an example, where we are going to create a Catalog and Inventory APIs and build our Microservice architecture around it. So the big question comes when to use Microservices?

  • It's fine to start with a monolith and then move to Microservices 
  • And We should start looking at Microservice when:
    • The code base size is more than what a small team can maintain
    • A team can't move fast anymore
    • Build because too slow due to large code base
    • Time to market is compromised due to infrequent deployments and long testing times.
  • It's all about team autonomy.

In our previous Microservice architecture in JAVA, we build Microservice which communicates synchronously but today we are going to build an asynchronous Microservice, and will also understand its benefits.



Synchronous Communication 

  • The client sends a request and waits for a response from the service which is exactly happening in our Mircorservice example in JAVA
  • The client cannot process without the response.
  • The client thread may use blocking or non-blocking callbacks.
  • REST+HTTP protocol is the traditional approach
  • Partial failures will happen.
  • In a distributed system whenever a service makes a synchronous request to another service, there is a risk of partial failure.
  • So, We must design our services to be resilient 
  • Timeouts, for more response experience and to ensure resources are never tied up 
  • Implement a Circuit breaker pattern to prevent our service from reaching resource exhaustion 

Asynchronous Communication

  • The client does not wait for a response in a timely manner
  • There might be no response at all
  • Usually involves the use of a lightweight message broker
  • Message broker has high availability 
  • Messages are sent to the broker and could be received by a single receiver or multiple receivers 

In the Asynchronous Microservice, which I build. 

  • For resilience and transient-fault handling capabilities, Retry, and Circuit Breaker.  I have used Polly.NET libraries.
  • For API Gateway, Caching, and Rate Limiting, I have used Ocelot .NET libraries. 
  • For Monitoring, I have used Prometheus and Grafana.
  • RabbitMQ is used for messaging.
  • MongoDB is used to store the data.

The Code is available on GitHub

Happy coding and keep sharing!!

Monday 13 March 2017

Mircoservice over SDL WEB 8 Coreservice


Self Hosted REST Microservice using OWIN and ASP.NET Web API 2

Open Web Interface for .NET (OWIN) defines an abstraction between .NET web servers and web applications. OWIN decouples the web application from the server, which makes OWIN ideal for self-hosting a web application in your own process, outside of IIS.

ASP.NET Web API - CORS Support in ASP.NET Web API 2. Cross-origin resource sharing (CORS) is a World Wide Web Consortium (W3C) specification (commonly considered part of HTML5) that lets JavaScript overcome the same-origin policy security restriction imposed by browsers.

For more details on how to setup and create Microservice read it here.

This service is used to get the data from SDL WEB 8 CM Database

Methods which are available 
  1. GetComponentByTcmUri
    • http://127.0.0.1:8080/Coreservice/getComponentByTcm/{tcmuri}
  2. GetSchemaByTcmUri
    • http://127.0.0.1:8080/Coreservice/getSchemaByTcm/{tcmuri}
  3. GetAllCategoriesWithInPubByTcmUri
    • http://127.0.0.1:8080/Coreservice/GetAllCategoriesWithInPubByTcmUri/{tcmuri}
  4. GetKeywordByCategoryID
    • http://127.0.0.1:8080/Coreservice/GetKeywordByCategory/{tcmuri}
  5. GetPageTempletByPubID
    • http://127.0.0.1:8080/Coreservice/GetPageTempletByPubID/{tcmuri}
  6. GetComponentTemplateByPubID
    • http://127.0.0.1:8080/Coreservice/GetComponentTemplateByPubID/{tcmuri}
  7. GetTemplateBuildingBlockByPubID
    • http://127.0.0.1:8080/Coreservice/GetTemplateBuildingBlockByPubID/{tcmuri}
  8. GetPageByPubID
    • http://127.0.0.1:8080/Coreservice/GetPageByPubID/{tcmuri}
  9. GetStructureGroupByPubID
    • http://127.0.0.1:8080/Coreservice/GetStructureGroupByPubID/{tcmuri}
  10. GetMultimediaComponentByPubID
    • http://127.0.0.1:8080/Coreservice/GetMultimediaComponentByPubID/{tcmuri}
  11. GetPublicationList
    • http://127.0.0.1:8080/Coreservice/GetPublicationList
  12. GetUserList 
    • http://127.0.0.1:8080/Coreservice/GetUserList
You can download code from here.

Happy Codeing and keep Sharing !!!1