Once we understand all three of these activities we're ready to implement our solution, and often that will take less than a day to complete.
Typically we use AWS Lambda to perform this transformation but occasionally Lambda is not necessary, and we'll see an example of that later in this article. The transformation step requires taking the event from the source system, querying its value, and updating the target system accordingly. The target system may be another AWS service, it may be a non AWS service within our AWS account (perhaps one of our own applications), or a remote service.
Lambda event sources are a good source of inspiration here.
When we're building Serverless glue apps that run in Amazon Web Services (AWS) the source system is most often an AWS service, perhaps as a proxy for an external system. Understand the transformation that needs to happen between (1) and (2).When we build Serverless glue apps we typically perform at least the following activities: I haven't come up with a suitably satisfying alternative description at this point! Building Serverless Glue Apps That product is relatively recent, and I was using ‘glue’ before the service came along. I want to make it clear that when I say ‘glue’ I'm not referring to the AWS Glue service. Alerting security engineers when certain AWS Account actions are performed.Forwarding log events to an external log visualizer.Providing a proxy / facade over an existing service, with customizations for a specific external partner.The low, and precise, infrastructure cost of Serverless makes creating small, one-off, highly specific services a very attractive option. This last category is one of the most popular usages of Serverless that we see at present. When John and I give our introductory presentations about Serverless we list 3 typical use-cases:
0 kommentar(er)
