As I gone over the AWS Lambda documentation, there are references on triggering services based on AWS events. I do not see references on hosting services in Lambda.
Would like to understand whether is it possible to create RESTful services using AWS Lambda for web sites to consume or not?
I can use NodeJs to develop the service.
As of the last month, the answer has changed. AWS Lambda functions can now return a synchronous response and AWS is now encouraging the use of Lambda as a mobile backend or potentially a full REST API.
Documentation is a bit sparse at the moment, but you can start reading about it here for now:
http://aws.amazon.com/lambda/whatsnew/
Amazon now supports this directly with the API Gateway service. This post is a great rundown of how to get started.
Correction :
Amazon has launched - Amazon API Gateway which used Lambda
What Is Amazon API Gateway?
API Gateway helps developers deliver
robust, secure, and scalable mobile and web application back ends. API
Gateway allows developers to securely connect mobile and web
applications to business logic hosted on AWS Lambda, APIs hosted on
Amazon EC2, or other publicly addressable web services hosted inside
or outside of AWS. With API Gateway, developers can create and operate
APIs for their back-end services without developing and maintaining
infrastructure to handle authorization and access control, traffic
management, monitoring and analytics, version management, and software
development kit (SDK) generation.
API Gateway is designed for web and mobile developers who are looking
to provide secure, reliable access to back-end APIs for access from
mobile apps, web apps, and server apps that are built internally or by
third-party ecosystem partners. The business logic behind the APIs can
either be provided by a publicly accessible endpoint API Gateway
proxies call to, or it can be entirely run as a Lambda function.
https://aws.amazon.com/api-gateway
As of today; AWS Lambda is focused on working out / responding to events like S3 put, DynamoDB Streams and also custom events [ there could be more event sources expected from Amazon ] - with heavily leveraging the STATELESSNESS style of programming.
To build out a complete RESTful Service backend using AWS Lambda wouldn't be possible or in other words AWS Lambda would be a bad choice to build the RESTful Service. You can continue to use the NodeJS and make it run on top of EC2 or ElasticBeanstalk.
The answer is Yes it is possible to build RESTful services using AWS lambda for websites to consume.
Your question has been answered by Tim Wagner of Amazon at a conference presentation where an audience member asks a very similar question to yours.
Question
"If you want to trigger a lambda function based on a regular old web request coming in from a user on the internet ... they hit an address and they sent in a bunch of query parameters ... So theres just this one stateless kind of thing that comes in with a bunch of data and then you want to trigger a lambda function off of that? ... what are the options there? ... to fire off that node.js workload?"
Answer 1
"... use something like beanstalk to create a web app. And then inside that webapp invoke the lambda functions for the portions of your workload or scenario that make sense to do"
Answer 2
"... If you're able to ... constrain your calls to match lambda's request model then you can skip that (beanstak webapp) and simply call us as if we were a web service proxy for you"
https://youtu.be/copO_JQQsBs?t=50m53s
As for the node part of your question.
The answer is yes you can develop your Lambda function using node.js
Please refer to the Webinar from Amazon below.
"The language that we have support for today is node.js"
https://youtu.be/YEWtQsqIYsk?t=25m22s
You can do almost anything (also very easily) with AWS Lambda. You can check out the below Serverless Framework: http://docs.serverless.com/v0.5.0/docs
For JAVA you can use Lambada Framework: https://github.com/lambadaframework/lambadaframework
Related
I have 7 APIs (API Apps) hosted in Azure App Service and I have a client app (SPA) which consumes all these APIs currently. For better maintainability at the client side, i would like to have a single entry point for all these APIs. Therefore, the APIs wouldn't be exposed to the client directly.
With the single entry point i can validate the authenticity (AD B2C token) of the client call and then route the request to respective API. In this case, the response from any API would return through the entry point to the client app.
I have couple of thoughts to implement this flow as below:
Azure API management would be a fit for my use case. However, the cost of the service looks little high for me.
Create one more API which would sit in-front of all the existing APIs, then it would act as an entry point of each request which comes from web app client. Here, for 'App Service Plan' a high end tier should be chosen to process thousands of request per second. I am expecting one thousand requests/second.
As i just started with Azure, i would like to take suggestions from you on achieving my use case. Please let me know your thoughts on suitable solution.
p.s, All the APIs are .net core web api (3.1)
Since you've already crossed out API Management, I would say creating a API "traffic router" is your best solution. You could use something like Application Gateway and use url routing to direct to a pool but you'll have to check the pricing to see if that works for you.
I would however, if it's not too difficult, place your 7 APIs into on one API project and just have the various controllers for your API endpoint. I certainly get if that's not possible. Should that be the case, I would place all API app services inside a VNet and restrict access so that only app services on that VNet could talk to it. That way, your "traffic router" API app can do the authorization and be able to talk to the other 7 API apps.
I am trying to build Serverless Microservice Architecture
Azure services used by me are:
Azure CDN
Azure Active Directory
Azure Logic Apps
Azure Functions
Azure Event Grid
Azure SignalR Service
Which below tools do I need mange and secure my API in Azure Serverless Microservice Architecture?
Azure Traffic Manager
Azure Application Gateway
Azure API Management
Azure Function Proxy
Links Referred by me are :
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/serverless/web-app
https://learn.microsoft.com/en-us/dotnet/standard/serverless-architecture/serverless-design-examples
Please help
Edit:
I understand above tools and it purpose but what I can't understand is do I require them, if yes in what order, all I am developing is an Angular 2+ app, post a Command Event to Azure Functions/Logic Apps using REST api returning RequestId (and triggering chain of events) and subscribing to that RequestId to listen for Domain Event.
This is very broad Architecture question. All the services you mentioned have specific purpose. You can even secure your functions without using any of them by simply turning on authentication on functions.
I would suggest reading all of them in details can help you identify which service may suit your needs in this case. e.g. Traffic manager is used for cross region traffic distribution and may not be required in your case. Function proxies and Api management overlap in few cases and really depends on what you are trying to achieve. To get better idea you may need to share your architecture diagram.
I see that I can either connect directly (through Rest HTTP requests) to Google Firebase API but I can also connect it to Azure Notification Hub. I also understand that Firebase is free while Azure isn't.
Can you kindly describe what is the benefit of connecting Firebase to Azure rather than directly connecting to Google's API (if any)?
I'm using ASP.Net Core MVC as my backend.
Thank you
If you are doing one push platform only (Firebase in your case) and only considering basic scenarios, then there's not much difference between using it directly or via Notification Hubs (NH).
However, NH provides you with a set of really powerful features:
Cross-platform SDKs to allow device registrations from all major OSes and a unified way of sending pushes no matter which platform they are on
A feature that is unique across similar services is tagging and routing
Templating
Basic or extended telemetry
And some other features.
So, in short, yes you can do everything that NH does by yourself. It's just you'll spend a lot of time (and money on resources required to run it) while doing it. And this is an out of the box solution that has been tested through years and is used by some of the largest products on the market.
I have an existing Web API 2 project that I'm looking to move over to Azure Service Fabric. I'm planning on creating a single stateless service within Fabric as detailed here (mainly as I don't understand actors/services at the moment!) and move the API across.
My API uses Entity Framework for it's backend and the built in Individual Accounts using OWIN.
Is there anything I need to consider when moving the service over (I mainly thought the the DB and authentication might be an issue) or is it just a case of putting a Service Fabric layer on top?
Thanks
EDIT
I've had a bit more of a thought about this and have some more questions (based on #Mihail's comment)!
So I'm going to have many stateless services (so I'm splitting my Web API project up) which will be exposed via a Web API project (based on this)
So two questions really:
I need to authenticate users based on Individual Accounts. I think I should do this on the Web API frontend so only authenticated users get through to the Fabric services but that means that the API has access to the DB and it's not just a pass through anymore. Is this OK? Should the API call a microservice to authenticate and then call the service it requires or is this overkill?
Entity Framework. If I have many services (and API frontend) accessing the same DB do I have to worry about concurrent connections/locking or will Entity Framework handle this for me?
As Mihail said, the questions around Entity Framework and authentication shouldn't be a problem, or at least not a Service Fabric specific problem.
One thing to consider though is whether Service Fabric is appropriate here if the only thing you'll have is a simple API, or whether an Azure API app would be a better fit for you.
If you went with Service Fabric, you'd have to have at least 5 VMs so you'll need to consider whether your app requires 5 VMs or whether that would be an overkill. Also remember that you'll need to manage those VMs - you don't get the magic that a PaaS solution would give you. You'd also have to deal with certain things that you'd get out of the box from an API app like auto-scale, authentication, rate limiting, integration with SaaS applications, etc. Might be worth having a look at this SO question for a comparison between Service Fabric and the App Service.
What i am trying to do:
i am planning to write my mobile back-end api using aws lambda. From the recent releases i got the info, that all events can triggered via aws-sdk on any platform including (android and iOS).
i have done POC for that, and its working fine. But how to manage all those events for metrics? security (OAuth)? Metering?. I know all these can be done via an api management tool. So i planned and chose CA API Management Gateway for doing these.
Where i am struck:
How can i integrate those lambda events in CA API Management Gateway or Any other API Management Gateway?
Extra Question's i have:
Can this be Done?
Will the api scale?
Is it a good idea of building all api in lambda?
There is no easy solution for this, I'm encountering a similar problem. It would be great if Amazon could provide an API gateway functionality for Lambda but they don't seem to at present. It feels like a big hole in their service.
If your CA API gateway has the ability to execute code you could write an intermediary that utilizes the Amazon mobile SDKs as detailed here, otherwise you might need to develop an intermediary application that performs a similar role.
The problem with developing an intermediary application however is then you will need to utilize EC2 compute resources and configure auto scaling mechanisms yourself. It would be much better if Amazon could provide this as a managed service.
Update
Amazon has just announced an API Gateway service.