AWS Lambda Layers

Serverless developers frequently import libraries and dependencies into their AWS Lambda functions. While you can zip these dependencies as part of the build and deployment process, in many cases it’s easier to use layers instead. You can configure your Lambda function to pull in additional code and content in the form of layers. A layer is a .zip file archive that contains libraries, a custom runtime, or other dependencies. With layers, you can use libraries in your function without needing to include them in your deployment package. Layers let you keep your deployment package small, which makes development easier. You can avoid errors that can occur when you install and package dependencies with your function code. You can create layers, or use layers that AWS or an AWS customer has published. Layers support resource-based policies for granting layer usage permissions to specific AWS accounts, AWS Organizations, or all accounts.

Layers are extracted to the /opt directory in the function execution environment. Each runtime looks for libraries in a different location under /opt, depending on the language. Structure your layer so that function code can access libraries without additional configuration. You can also use the AWS Serverless Application Model (AWS SAM) to manage layers and your function's layer configuration.

New Year Greetings 2021

AWS CloudShell

AWS CloudShell is a browser-based shell that makes it easy to securely manage, explore, and interact with your AWS resources. CloudShell is pre-authenticated with your console credentials. Common development and operations tools are pre-installed, so no local installation or configuration is required. With CloudShell, you can quickly run scripts with the AWS Command Line Interface (AWS CLI), experiment with AWS service APIs using the AWS SDKs, or use a range of other tools to be productive. You can use CloudShell right from your browser and at no additional cost.

Benefits

No extra credentials to manage
CloudShell inherits the credentials of the user signed in to the AWS Management Console, so there's no need to spend extra effort managing credentials locally.

Always up to date
CloudShell provides a fully managed Amazon Linux 2 environment that has the latest versions of popular tools already installed and updated. You don't need to patch the environment or update the pre-installed tools.

No cost
CloudShell provides you with a browser-based shell to run scripts and commands. It includes 1 GB of persistent storage per Region at no extra cost to you. You only pay for the AWS resources you use with CloudShell to create and run your applications.

Customizable
With 1 GB of persistent storage per Region, you can store scripts, files, configuration preferences, and additional tools in your home directory. You can begin working immediately, without customizing your environment every time you use the shell.

Link: https://aws.amazon.com/cloudshell/

Snowflake - Tasks

User-defined tasks allow scheduled execution of SQL statements. Tasks run according to a specified execution configuration, using any combination of a set interval and/or a flexible schedule using a subset of familiar cron utility syntax. Tasks currently run in user-specified warehouses but will eventually run in a serverless environment using Snowflake-supplied compute resources. Currently, a task can execute a single SQL statement, including a call to a stored procedure. Tasks can be combined with table streams for continuous ELT workflows to process recently changed table rows. Streams ensure exactly once semantics for new or changed data in a table. Tasks can also be used independently to generate periodic reports by inserting or merging rows into a report table or perform other periodic work.

Task Scheduling
There is no event source that can trigger a task; instead, a task runs on a schedule, which can be defined when creating a task (using CREATE TASK) or later (using ALTER TASK). Snowflake ensures only one instance of a task with a schedule (i.e. a standalone task or the root task in a tree of tasks) is executed at a given time. If a task is still running when the next scheduled execution time occurs, then that scheduled time is skipped.

Task History
Query the TASK_HISTORY table function to verify the task did not run. It is possible that the task ran successfully but the SQL statement in the task definition failed. In particular, note the scheduled and completed times, as well as any error code and message. If the task has a parent task (in a tree of tasks), verify whether the parent task completed successfully.

There is a 60 minute default limit on a single run of a task. This limitation was implemented as a safeguard against non-terminating tasks.

Link: https://docs.snowflake.com/en/user-guide/tasks-intro.html

Snowflake - Stored Procedures

Unlike MS SQL server, Snowflake's stored procedures are written in JavaScript. A stored procedure returns a single value. Although you can run SELECT statements inside a stored procedure, the results must be used within the stored procedure, or be narrowed to a single value to be returned.

Snowflake stored procedures use JavaScript and, in most cases, SQL:

• JavaScript provides the control structures (branching and looping).
• SQL is executed by calling functions in a JavaScript API.

Stored procedures allow:

• Procedural logic (branching and looping), which straight SQL does not support.
• Error handling.
• Dynamically creating a SQL statement and execute it.
• Writing code that executes with the privileges of the role that owns the procedure, rather than with the privileges of the role that runs the procedure. This allows the stored procedure owner to delegate the power to perform specified operations to users who otherwise could not do so. However, there are limitations on these owner’s rights stored procedures.

One common use for stored procedures is to automate a task that requires multiple SQL statements and is performed frequently.

Snowflake API consists of JavaScript objects and the methods in those objects.

Link: https://docs.snowflake.com/en/sql-reference/stored-procedures-api.html

Multi-tenant Application

According to the definition available online is "Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers". The term "software multitenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. Systems designed in such manner are often called shared (in contrast to dedicated or isolated). A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance - including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.

Types of multi-tenant architecture:

There are three main multi-tenancy model types, all with varying levels of complexity and costs. A single, shared database schema is a multi-tenancy model with a multi-tenant database. This is the simplest form out of the three and is a relatively low cost for tenants because of the use of shared resources. This form uses a single application and database instance to host tenants and store data. Using a single, shared database schema allows for easier scaling; however, operational costs can be higher.

Another multi-tenant architecture includes the use of a single database with multiple schemas. This tenant system uses a single application instance with individual databases for each tenant. In addition, this architecture has a higher cost with more overhead with each database. It is a valuable architecture when data from different tenants need to be treated differently -- such as if they had to go through different geographic regulations.

The third type of multi-tenant architecture hosts data in multiple databases. This model is relatively complex in terms of management and maintenance, but tenants can be separated by a chosen criterion.

In cloud computing, the meaning of multi-tenant architecture has broadened because of new service models that take advantage of virtualization and remote access. A software-as-a-service (SaaS) provider, for example, can run one instance of its application on one instance of a database and provide web access to multiple customers. In such a scenario, each tenant's data is isolated and remains invisible to other tenants. Multi-tenancy can also be implemented in multi-tier systems such as an SAP system.

ASP.NET Core Middleware

ASP.NET Core introduced a new concept called Middleware. Middleware is software that's assembled into an app pipeline to handle requests and responses. Each component:

• Chooses whether to pass the request to the next component in the pipeline.
• Can perform work before and after the next component in the pipeline.

Request delegates are used to build the request pipeline. The request delegates handle each HTTP request. Request delegates are configured using Run, Map, and Use extension methods. An individual request delegate can be specified in-line as an anonymous method (called in-line middleware), or it can be defined in a reusable class. These reusable classes and in-line anonymous methods are middleware, also called middleware components. Each middleware component in the request pipeline is responsible for invoking the next component in the pipeline or short-circuiting the pipeline. When a middleware short-circuits, it's called a terminal middleware because it prevents further middleware from processing the request.

In the classic ASP.NET, HttpHandlers and HttpModules were part of request pipeline. Middleware is similar to HttpHandlers and HttpModules where both needs to be configured and executed in each request.

Typically, there will be multiple middleware in ASP.NET Core web application. It can be either framework provided middleware, added via NuGet or your own custom middleware. We can set the order of middleware execution in the request pipeline. Each middleware adds or modifies http request and optionally passes control to the next middleware component.

1. Use: chain multiple request delegates together. The next parameter represents the next delegate in the pipeline. You can short-circuit the pipeline by not calling the next parameter.

2. Run: delegates don't receive a next parameter. The first Run delegate is always terminal and terminates the pipeline.

3. Map: extensions are used as a convention for branching the pipeline. Map branches the request pipeline based on matches of the given request path. If the request path starts with the given path, the branch is executed.