I'm learning how to design and implement microservices using serverless technologies. I'm trying to create autonomous microservices and am having difficulty understanding how to communicate data across/between microservices. I'm using .Net Core for my microservices and am wanting each microservice to be a AWS lambda function exposed via API Gateway.
I have the following scenario:
Institution microservice - returns a list of institutions within a radius (25 miles) of a zipcode.
ROI Calculator microservice - receives a zip code as input and calls institution microservice receiving a list of institutions. For each institution returned, perform a series of calculations yielding a ROI value.
How should ROI Calculator microservice make a call to institution microservice?
ASP.NET core web api application can be published as it is on AWS Lambda as Serverless function. You get everything that regular .NET core application provides like controllers , models etc. Amazon API gateway proxy is integrated directly into .NET Core api routing system. So your AWS lambda function will be serving your .Net core web api. You should watch this tutorial for starters to get better understanding.
Create .NET Core AWS lambda function
.NET core AWS Lambda Microservices
If you go by template provided by AWS SDK (ASP.NET core web api template) and you publish .Net core web api on AWS it will configure everything for you including AWS Lambda function and API gateway. So if you have create 2 .net core web api projects you will have 2 web api gateways. The problem is if we have 10 microservices mean we will have 10 api gateways , so we should ideally have 1 api gateway for multiple microservices.
I have worked on POC recently that has one API gateway and all microservices AWS lambda functions are behind this. Each microservice has base path e.g. shopping or users setup in their startup.cs that will identify them individually behind apigateway. so microservice 1 will be apigateway/shopping/{anything} , another microservice will be apigateway/users/{anything} and they both are configured behind api gateway. API Gateway will send request to AWS lambda function (.Net core web api) and this request will be resolved by .Net core routing system. Even multiple controller can be used this way in a single web api project without problem.
I have modified serverless.template so we can only publish aws lambda function and configure apigateway seperatley. You can find code sample and details on my github blog here .NET Core Web API AWS Lambda Microservices Sample .
There are two ways of doing this depending on your independance of the microservices is probably the best answer:
Make a internal HTTP call from the ROI -> Institution which would be okay. The problem with this is that if the service is down the data will not be available.
Store the data needed to make the calculation inside the ROI service as well. This seems strange but the data once created in say the Institution service it could be sent via a message bus to the ROI service which then uses the data when needed. (this however may not suit your domain, it depends what information it needs).
However it seems that the calculation and the storage of the Institutions could be within the same microservice therefore eleminating the problem.
Related
We have an application which has set of APIs developed in .NET CORE and UI which consume these APIs developed in Angular(both are independent projects) . Both are hosted on azure app service.
WebAPI integrates with 3rd Party APIs. Some of those transactional
APIs are very time consuming, so we want to have fire and forget way
of calling those and have them notified when they end.
Once our API receives the response from 3rd party, we want that be notified to UI
So we want some messaging or Pub-Sub mechanism to achieve this
I am in consideration of SignalR and Kafka.
From the documents that I red about SignalR it seems that it can be used between API -client, so I can use this for 2nd scenario.
Can SignalR be used between 2 APIs?
Coming to Kakfa , it seems to be good one for high end data streaming which I consider as over-engineering for our requirement.
Our application will be on both Azure and on-prem so we also went through Azure service bus but there is limit on Message length and cost seem to be problem for us.
So I want to know if there are any ways I can have this communication eased between 2 WebAPIs application?
We are doing a POC with SuperTokens for authentication. We require Passwordless, Email/Password, and Social Login functionality. With that functionality required, is the SuperTokens Core Api layer scalable? If so, what is the recommended approach for scaling?
SuperTokens has two sets of APIs:
Core driver interface (CDI): The API exposed via the SuperTokens Core microservice.
Frontend driver interface (FDI): The API exposed via our backend SDK.
Your app's frontend only calls the FDI APIs and in turn, our backend SDK calls the CDI APIs. So your backend is a proxy between the frontend and the SuperTokens core service.
The scalability of the FDI APIs (which is called by your frontend) is dependent on the scalability of your API layer - which is completely controlled by you.
The scalability of the CDI APIs (exposed via the SuperTokens core service) depends on:
The number of instances of the core that have been deployed.
How "far" away is the core from your backend.
The scalability of the underlying database that the core connects to.
Each SuperTokens core instance is stateless and can be scaled up / down easily. However, all of them need to connect to the same instance of a db and therefore the limiting factor here becomes the scalability of the db itself.
Since only your backend API layer queries the SuperTokens core, it is recommended to host the core in the same region as your backend.
That being said, one instance of the core can handle several hundred requests per second comfortably. You can further improve it's performance by setting:
The max number of parallel requests to server
The max number of parallel db connections.
Finally, if we consider the different types of auth operations, session verification is by far the most common operation (as compared to signing in / out or changing a password...). By default, SuperTokens verifies a user's session in a stateless manner. This means that your backend API layer doesn't need to query the core at all for session verification.
This in turn implies that you can easily scale SuperTokens to handle millions of users with hundreds of thousands of concurrent sessions with a fairly low number of core instances.
We started our planning phase on a new project and we settled on a ASP.NET REST API which should be hosted on Azure. Since none of us has any experience on deployment on Azure (or any other cloud service), I have two questions.
Do you need separate Azure Services for the Database and the API, or might there be a combined "package" for the prototype, which later can be changed easily?
Is there any documentation or are there any examples of the entire deployment process of a simple dummy API and the DB? I have spent the last few hours reading the official documentation and searching around, but I would really love to see some sort of reference, just to ensure I don't miss something.
For now, the best I have found is this and this. This seems rather shallow, so I really hope, that there might be more.
If you're looking for in-depth design an implementation details then I would suggest that the Azure Architecture Center would be an excellent place to start, for hands on experience there are hundreds of free courses available on Microsoft Learn.
Specifically there are sections on API design and API implementation. From the Serverless web application page is:
If you don't need all of the functionality provided by API Management, another option is to use Functions Proxies. This feature of Azure Functions lets you define a single API surface for multiple function apps, by creating routes to back-end functions. Function proxies can also perform limited transformations on the HTTP request and response. However, they don't provide the same rich policy-based capabilities of API Management.
Function Proxies
I would suggest starting with using Azure Functions for your API (you only pay for the number of calls + a combination of CPU, memory, and runtime, but the first 1,000,000 calls per month are free (consumption plan), rather than paying for an Azure App Service to host your API and run all the time but only be utilized some of the time.
Some links that might help:
Build Serverless APIs with Azure Functions
Customize an HTTP endpoint in Azure Functions
There is an excellent summary in this article that states:
For the heavy workloads.
Private(enterprise) API - API Management with a Premium plan.
Public API - Functions Proxy with the Premium plan.
For light/moderate workloads.
Private API -Functions Proxy with the Premium plan.
Public API -Functions Proxy with a Consumption plan and custom warm-up solution.
Then from here you can use a connection string to an Azure SQL DB inside your functions to write to the DB or something like Azure Managed Identity (yes the link is for Azure PostgreSQL but the process will be much the same for Azure SQL).
In terms of deployment you should be looking at using Azure DevOps (or GitHub Actions):
Setting up a CI/CD pipeline for Azure functions (old way - GUI pipelines)
Deploy an Azure Functions app to Azure (new way - YAML pipelines)
Continuous Delivery for Azure SQL DB using Azure DevOps
Another helpful tool to get a gauge of costs is the Azure Pricing Calculator.
I'm searching for a solution to get data from the Azure IoT Hub to the backend of a Web App also hosted in Azure which is written in ASP.NET 4.6.
It would be best to just receive the raw Json string as fast as possible.
I found others suggesting using Webhooks or Azure functions for a similar purpose but the delay these solutions bring aren't really acceptable.
It would be best to just connect directly to the IoT endpoint and get every message as it comes in. Can anybode please point me to the right direction?
You can simply use the EventHub .NET SDK in your web app, connect to the EventHub-compatible endpoint of the IoT Hub and directly consume the events in your app. This has minimal delay and involves no extra components.
How to guide (.NET core but same applies to .NET Framework): https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-dotnet-standard-getstarted-send#receive-events
var eventProcessorHost = new EventProcessorHost(
EventHubName,
PartitionReceiver.DefaultConsumerGroupName,
EventHubConnectionString,
StorageConnectionString,
StorageContainerName);
// Registers the Event Processor Host and starts receiving messages
await eventProcessorHost.RegisterEventProcessorAsync<SimpleEventProcessor>();
The Azure SignalR Service can help to broadcast messages to the Web App instances.
There are no direct integration between the Azure IoT Hub and Azure SignalR Service. Basically you can use two patterns for this integration such as PULL-PUSH and PUSH-PUSH.
The following screen shows these integration patterns:
Note, that the PUSH-PUSH pattern with the Azure Event Grid is suitable for solution when the subscriber (consumer) is not critical for processing events in the order.
I am developing a mobile application using Telerik Platform. The services consumed by the app are ASP.NET Web API RESTful services which are hosted on Azure. I'd like to build some resilience into the app by adding a service bus and have been looking at Azure Service Bus which seems to be what I'm looking for.
It's fairly new to me and I have a few questions.
Can Azure Service Bus be used for RESTful services that return data or are they fire-and-forget only?
For simple RESTful services is Azure Service Bus the way to go or Azure Storage Queue? When would you use one vs the other?
When would I use a Queue vs Topic / Subscription?
ASB is about messaging. You use messaging for communication between parts of your system/services. RESTful services can leverage ASB by translating a request into a message to perform some work. Emphasis on converting the intent into a message, to instruct about work that needs to take place, not execute the work itself.
ASB or ASQ is your choice. This is where you need to choose between the features and capabilities each provides. There's a good MSFT comparison documentation on it.
Queues vs Topics/Subscriptions - if you need to send a message to a single destination (a command) then queue is simpler. In case a message needs to be broadcasted to multiple receivers (events), topics/subscriptions are your friends.