As per AWS documentation on Layers, a Layer needs to have a compatible runtime defined in order to be used with a Lambda function. A quick test confirms that I cannot assign a Layer that has 0 runtimes selected.
Why is it so, and why is the Layer runtime setting optional? Arguably there are usecases where the Layer is runtime-agnostic (e.g. statically compiled executable, like imagemagick or ffmpeg). The limitation on 'compatible runtime' layer selection in Lambda function forces managing multiple standalone versions of (otherwise identical) Layers.
Related
AWS Lambda suggests using ADOT(AWS Distro for OpenTelemetry) over the AWS x-ray SDK to instrument python code in AWS Lambda. The documentation that suggests this can be found here:
https://docs.aws.amazon.com/lambda/latest/dg/python-tracing.html
However, the issue is the ADOT documentation does not speak about how to properly instrument container image based lambda functions.
How can this be achieved using Lambda container images?
ADOT is provides this solution as a Lambda Layer. Since Lambda functions packaged as container images do not support adding Lambda layers, us developers take on the responsibility for packaging the preferred runtimes and dependencies as a part of the container image during the build process.
My understanding is that in order for ADOT to instrument the code, ADOT needs to be invoked to wrap the subsequent network calls to ensure they are traced. My understanding is that the lambda python base container image uses a shell script as its entrypoint. How will copying the layer data to /opt ensure that the ADOT wrappers get called when the lambda gets invoked?
I am trying to deploy a binary utility along with my Python-based lambda to a Greengrass group.
Using a layer seemed like a natural way to accomplish this. No errors are encountered during the deployment, but I cannot find any evidence that the layer exists on the edge device (Ubuntu 18.04).
I have also been unable to find any documentation that confirms or denies layers work with Greengrass.
To move forward, I am bundling the utility within the Lambda deployment package itself. This seems workable, but a layer seems more flexible...
Any clarification would be appreciated.
Just from my experience, no, Layers do not get pushed to the Greengrass host, so if your lambda function depends on libraries in a layer, it will fail to run, even though deployments will go through without issue.
AWS I believe is no longer updating Greengrass V1, as they're focused on Greengrass V2. So I doubt this issue will get addressed. As a workaround, package everything within the lambda function and don't use layers for those functions getting pushed to Greengrass.
Would it be technically possible to build a general purpose XSLT transform service (using the Saxon XSLT engine) delivered as an Amazon AWS Lambda function? How would you go about implementing it? Would there be a way to avoid initialising the Java VM each time the lambda function was called?
This is more of a brain-storming question. I am unlikely to attempt to implement it.
How would licensing work? There is no way for the developer to know on how many machines Saxon XSLT is installed. Probably, that is something that has to be negotiated with the vendor?
I can't see any intrinsic reason why it shouldn't work, but I have no idea about the implementation details.
Since Amazon support Java as the implementation language, one assumes they have a mechanism to avoid JVM initialization costs.
There's a distinction between having a Lambda that supports one particular defined transformation, and having one that executes an arbitrary user-defined stylesheet. I'm not sure that providing a service to execute untrusted code is ever a particularly good idea even if it's heavily sandboxed in terms of resource access.
As regards licensing, our general approach in Saxonica is that we try to ensure that licensing doesn't get in the way of doing something that makes technical sense. If there's value in doing it, we'll find a way of sharing the value that works for all parties.
If this is about executing one predefined stylesheet, as a spin-off from the Saxon-JS development we already have mechanisms that allow a developer to acquire a license that can be redistributed with the compiled stylesheet, meaning essentially that if you acquire the right kind of development license, the run-time is free.
What is the difference between a Win32 or DirectX wrapper and a Win32 or DirectX framework?
A wrapper is typically a family of functions that contain the function calls for a library or API like win32, DirectX, etc., in some sort of abstracted way to the end-user. Many times they are customized so that the functions you call in the wrapper is not exactly the same as the original API, or some default parameters have been setup for you to make working with the API a bit easier. Also in the specific instance of a language wrapper, the functionality has been embedded in the language's run-time API, and then exposed to the end-user. For example, one could expose the win32 calls to a Python user by creating a C-library plug-in for python with the win32 API calls, and then creating a python library that may have customized python functions that call the win32 functions exposed by the C-library plugin. In this case the Python library "wraps" the native C-based win32 library.
A framework is like a wrapper, but in its most-typically used definition, it's a little different in that it works by creating some type of run-time environment that you create callbacks to plug into, so that when the frame-work wants to-do some task, you've written a function that is called for that task. This is called the "Hollywood Principal" of programming, which basically says, "don't call us, we'll call you". So in working with this model, you create functions, register them with the frame-work, and your function is called when the frame-work needs to call it, and the framework passes its own internal parameters as your function arguments. A good example is a GUI-framework, where you create callbacks for buttons and other events, and the GUI-framework calls those functions as it processes its runtime event-loop.
So I guess one way to think of the primary differentiation between the two is that wrappers tend to be static (i.e. exposing libraries and functions with customized function calls either that fill-in default values for you or translate them to a different language), whereas a framework tends to be dynamic (i.e. its a runtime system that you create callbacks for, and register it with the framework that are then called during some time of runtime event loop or kernel, etc., like a GUI toolkit).
Wrappers tend to make it possible (oftentimes easier) to access complex systems, complex code or combinations of calls from multiple classes and so forth. For example, you may create a Facebook wrapper in C# or Java to interact with getting user data from the Facebook API, which has many REST-based functions which return JSON. A framework is a set of related objects, functions, and so forth to provide a particular functionality, or enhance a particular functionality, so you wouldn't use either a wrapper or framework. Oftentimes you'll use a both, using a wrapper to access a framework. This is especially true with legacy systems :)
I need to call a RPC client which is implemented in C from a Java class.
The interaction is one way only(i.e) Java has to invoke specific functions in C, while C need not return anything to the calling Java code.
Can someone explain me the pros & cons in using either of the types (JNI/Runtime.exec)?? and which is the best option for my case?
Runtime.exec() will launch a separate process for each call. Your Java caller needs to consume the output of each process.
JNI would require a native, dynamically linked library. Depending on your operating system, you may need to explicitly export functions. You would define a Java class with "native" methods, generate a C header/stub file with javah, and implement the native methods by calling your C client functions.
Runtime.exec() probably consumes the most resources. I personally would use an in-process call to native code.
Instead of JNI, consider using JNA, which makes it easy to call C functions from Java without an ad hoc native glue layer. Your C functions would need to be in a native, dynamically linked library. In Java, you declare their signatures, load the library, and call the functions.
For Windows DLLs, be aware that you need to export functions for them to be available from outside the DLL.