Load data incrementally from transactional data lakes to data warehouses

Post Syndicated from Noritaka Sekiyama original https://aws.amazon.com/blogs/big-data/load-data-incrementally-from-transactional-data-lakes-to-data-warehouses/

Data lakes and data warehouses are two of the most important data storage and management technologies in a modern data architecture. Data lakes store all of an organization’s data, regardless of its format or structure. An open table format such as Apache Hudi, Delta Lake, or Apache Iceberg is widely used to build data lakes on Amazon Simple Storage Service (Amazon S3) in a transactionally consistent manner for use cases including record-level upserts and deletes, change data capture (CDC), time travel queries, and more. Data warehouses, on the other hand, store data that has been cleaned, organized, and structured for analysis. Depending on your use case, it’s common to have a copy of the data between your data lake and data warehouse to support different access patterns.

When the data becomes very large and unwieldy, it can be difficult to keep the copy of the data between data lakes and data warehouses in sync and up to date in an efficient manner.

In this post, we discuss different architecture patterns to keep data in sync and up to date between data lakes built on open table formats and data warehouses such as Amazon Redshift. We also discuss the benefits of incremental loading and the techniques for implementing the architecture using AWS Glue, which is a serverless, scalable data integration service that helps you discover, prepare, move, and integrate data from multiple sources. Various data stores are supported in AWS Glue; for example, AWS Glue 4.0 supports an enhanced Amazon Redshift connector to read from and write to Amazon Redshift, and also supports a built-in Snowflake connector to read from and write to Snowflake. Moreover, Apache Hudi, Delta Lake, and Apache Iceberg are natively supported in AWS Glue.

Architecture patterns

Generally, there are three major architecture patterns to keep your copy of data between data lakes and data warehouses in sync and up to date:

  • Dual writes
  • Incremental queries
  • Change data capture

Let’s discuss each of the architecture patterns and the techniques to achieve them.

Dual writes

When initially ingesting data from its raw source into the data lake and data warehouse, a single batch process is configured to write to both. We call this pattern dual writes. Although this architecture pattern (see the following diagram) is straightforward and easy to implement, it can become error-prone because there are two separate transactions threads, and each can have its own errors, causing inconsistencies between the data lake and data warehouse when a write fails in one but not both.

Incremental queries

An incremental query architectural pattern is designed to ingest data first into the data lake with an open table format, and then load the newly written data from the data lake into the data warehouse. Open table formats such as Apache Hudi and Apache Iceberg support incremental queries based on their respective transaction logs. You can capture records inserted or updated with the incremental queries, and then merge the captured records into the destination data warehouses.

Apache Hudi supports incremental query, which allows you to retrieve all records written during specific time range.

Delta Lake doesn’t have a specific concept for incremental queries. It’s covered in a change data feed, which is explained in the next section.

Apache Iceberg supports incremental read, which allows you to read appended data incrementally. As of this writing, Iceberg gets incremental data only from the append operation; other operations such as replace, overwrite, and delete aren’t supported by incremental read.

For merging the records into Amazon Redshift, you can use the MERGE SQL command, which was released in April 2023. AWS Glue supports the Redshift MERGE SQL command within its data integration jobs. To learn more, refer to Exploring new ETL and ELT capabilities for Amazon Redshift from the AWS Glue Studio visual editor.

Incremental queries are useful to capture changed records; however, incremental queries can’t handle the deletes and just send the latest version of each record. If you need to handle delete operations in the source data lake, you will need to use a CDC-based approach.

The following diagram illustrates an incremental query architectural pattern.

Change data capture

Change data capture (CDC) is a well-known technique to capture all mutating operations in a source database system and relay those operations to another system. CDC keeps all the intermediate changes, including the deletes. With this architecture pattern, you capture not only inserts and updates, but also deletes committed to the data lake, and then merge those captured changes into the data warehouses.

Apache Hudi 0.13.0 or later supports change data capture as an experimental feature, which is only available for Copy-on-Write (CoW) tables. Merge-on-Read tables (MoR) do not support CDC as of this writing.

Delta Lake 2.0.0 or later supports a change data feed, which allows Delta tables to track record-level changes between table versions.

Apache Iceberg 1.2.1 or later supports change data capture through its create_changelog_view procedure. When you run this procedure, a new view that contains the changes from a given table is created.

The following diagram illustrates a CDC architecture.

Example scenario

To demonstrate the end-to-end experience, this post uses the Global Historical Climatology Network Daily (GHCN-D) dataset. The data is publicly accessible through an S3 bucket. For more information, see the Registry of Open Data on AWS. You can also learn more in Visualize over 200 years of global climate data using Amazon Athena and Amazon QuickSight.

The Amazon S3 location s3://noaa-ghcn-pds/csv/by_year/ has all of the observations from 1763 to the present organized in CSV files, one file for each year. The following block shows an example of what the records look like:

ID,DATE,ELEMENT,DATA_VALUE,M_FLAG,Q_FLAG,S_FLAG,OBS_TIME
AE000041196,20220101,TAVG,204,H,,S,
AEM00041194,20220101,TAVG,211,H,,S,
AEM00041217,20220101,TAVG,209,H,,S,
AEM00041218,20220101,TAVG,207,H,,S,
AE000041196,20220102,TAVG,226,H,,S,
...
AE000041196,20221231,TMAX,243,,,S,
AE000041196,20221231,PRCP,0,D,,S,
AE000041196,20221231,TAVG,202,H,,S,

The records have fields including ID, DATE, ELEMENT, and more. Each combination of ID, DATE, and ELEMENT represents a unique record in this dataset. For example, the record with ID as AE000041196, ELEMENT as TAVG, and DATE as 20220101 is unique. We use this dataset in the following examples and simulate record-level updates and deletes as sample operations.

Prerequisites

To continue with the examples in this post, you need to create (or already have) the following AWS resources:

For the first tutorial (loading from Apache Hudi to Amazon Redshift), you also need the following:

For the second tutorial (loading from Delta Lake to Snowflake), you need the following:

  • A Snowflake account.
  • An AWS Glue connection named snowflake for Snowflake access. For more information, refer to Configuring Snowflake connections.
  • An AWS Secrets Manager secret named snowflake_credentials with the following key pairs:
    • Key sfUser with value <Your Snowflake username>
    • Key sfPassword with value <Your Snowflake password>

These tutorials are inter-changeable, so you can easily apply the same pattern for any combination of source and destination, for example, Hudi to Snowflake, or Delta to Amazon Redshift.

Load data incrementally from Apache Hudi table to Amazon Redshift using a Hudi incremental query

This tutorial uses Hudi incremental queries to load data from a Hudi table and then merge the changes to Amazon Redshift.

Ingest initial data to a Hudi table

Complete the following steps:

  1. Open AWS Glue Studio.
  2. Choose ETL jobs.
  3. Choose Visual with a source and target.
  4. For Source and Target, choose Amazon S3, then choose Create.

A new visual job configuration appears. The next step is to configure the data source to read an example dataset.

  1. Name this new job hudi-data-ingestion.
  2. Under Visual, choose Data source – S3 bucket.
  3. Under Node properties, for S3 source type, select S3 location.
  4. For S3 URL, enter s3://noaa-ghcn-pds/csv/by_year/2022.csv.

The data source is configured. The next step is to configure the data target to ingest data in Apache Hudi on your S3 bucket.

  1. Choose Data target – S3 bucket.
  2. Under Data target properties – S3, for Format, choose Apache Hudi.
  3. For Hudi Table Name, enter ghcn_hudi.
  4. For Hudi Storage Type, choose Copy on write.
  5. For Hudi Write Operation, choose Upsert.
  6. For Hudi Record Key Fields, choose ID.
  7. For Hudi Precombine Key Field, choose DATE.
  8. For Compression Type, choose GZIP.
  9. For S3 Target location, enter s3://<Your S3 bucket name>/<Your S3 bucket prefix>/hudi_incremental/ghcn/. (Provide your S3 bucket name and prefix.)
  10. For Data Catalog update options, select Do not update the Data Catalog.

Now your data integration job is authored in the visual editor completely. Let’s add one remaining setting about the IAM role, then run the job.

  1. Under Job details, for IAM Role, choose your IAM role.
  2. Choose Save, then choose Run.

You can track the progress on the Runs tab. It finishes in several minutes.

Load data from the Hudi table to a Redshift table

In this step, we assume that the files are updated with new records every day, and want to store only the latest record per the primary key (ID and ELEMENT) to make the latest snapshot data queryable. One typical approach is to do an INSERT for all the historical data, and calculate the latest records in queries; however, this can introduce additional overhead in all the queries. When you want to analyze only the latest records, it’s better to do an UPSERT (update and insert) based on the primary key and DATE field rather than just an INSERT in order to avoid duplicates and maintain a single updated row of data.

Complete the following steps to load data from the Hudi table to a Redshift table:

  1. Download the file hudi2redshift-incremental-load.ipynb.
  2. In AWS Glue Studio, choose Jupyter Notebook, then choose Create.
  3. For Job name, enter hudi-ghcn-incremental-load-notebook.
  4. For IAM Role, choose your IAM role.
  5. Choose Start notebook.

Wait for the notebook to be ready.

  1. Run the first cell to set up an AWS Glue interactive session.
  2. Replace the parameters with yours and run the cell under Configure your resource.
  3. Run the cell under Initialize SparkSession and GlueContext.
  4. Run the cell under Determine target time range for incremental query.
  5. Run the cells under Run query to load data updated during a given timeframe.
  6. Run the cells under Merge changes into destination table.

You can see the exact query immediately run right after ingesting a temp table into the Redshift table.

  1. Run the cell under Update the last query end time.

Validate initial records in the Redshift table

Complete the following steps to validate the initial records in the Redshift table:

  1. On the Amazon Redshift console, open Query Editor v2.
  2. Run the following query: 
    SELECT * FROM "dev"."public"."ghcn" WHERE ID = 'AE000041196'

The query returns the following result set.

The original source file 2022.csv has historical records for record ID='AE000041196' from 20220101 to 20221231; however, the query result shows only four records, one record per ELEMENT at the latest snapshot of the day 20221230 or 20221231. Because we used the UPSERT write option when writing data, we configured the ID field as a Hudi record key field, the DATE field as a Hudi precombine field, and the ELEMENT field as partition key field. When two records have the same key value, Hudi picks the one with the largest value for the precombine field. When the job ingested data, it compared all the values in the DATE field for each pair of ID and ELEMENT, and then picked the record with the largest value in the DATE field. We use the current state of this table as an initial state.

Ingest updates to a Hudi table

Complete the following steps to simulating ingesting more records to the Hudi table:

  1. On AWS Glue Studio, choose the job hudi-data-ingestion.
  2. On the Data target – S3 bucket node, change the S3 location from s3://noaa-ghcn-pds/csv/by_year/2022.csv to s3://noaa-ghcn-pds/csv/by_year/2023.csv.
  3. Run the job.

Because this job uses the DATE field as a Hudi precombine field, the records included in the new source file have been upserted into the Hudi table.

Load data incrementally from the Hudi table to the Redshift table

Complete the following steps to load the ingested records incrementally to the Redshift table:

  1. On AWS Glue Studio, choose the job hudi-ghcn-incremental-load-notebook.
  2. Run all the cells again.

In the cells under Run query, you will notice that the records shown this time have DATE in 2023. Only newly ingested records are shown here.

In the cells under Merge changes into destination table, the newly ingested records are merged into the Redshift table. The generated MERGE query statement in the notebook is as follows:

MERGE INTO public.ghcn USING public.ghcn_tmp ON 
    public.ghcn.ID = public.ghcn_tmp.ID AND 
    public.ghcn.ELEMENT = public.ghcn_tmp.ELEMENT
WHEN MATCHED THEN UPDATE SET 
    _hoodie_commit_time = public.ghcn_tmp._hoodie_commit_time,
    _hoodie_commit_seqno = public.ghcn_tmp._hoodie_commit_seqno,
    _hoodie_record_key = public.ghcn_tmp._hoodie_record_key,
    _hoodie_partition_path = public.ghcn_tmp._hoodie_partition_path,
    _hoodie_file_name = public.ghcn_tmp._hoodie_file_name, 
    ID = public.ghcn_tmp.ID, 
    DATE = public.ghcn_tmp.DATE, 
    ELEMENT = public.ghcn_tmp.ELEMENT, 
    DATA_VALUE = public.ghcn_tmp.DATA_VALUE, 
    M_FLAG = public.ghcn_tmp.M_FLAG, 
    Q_FLAG = public.ghcn_tmp.Q_FLAG, 
    S_FLAG = public.ghcn_tmp.S_FLAG, 
    OBS_TIME = public.ghcn_tmp.OBS_TIME 
WHEN NOT MATCHED THEN INSERT VALUES (
    public.ghcn_tmp._hoodie_commit_time, 
    public.ghcn_tmp._hoodie_commit_seqno, 
    public.ghcn_tmp._hoodie_record_key, 
    public.ghcn_tmp._hoodie_partition_path, 
    public.ghcn_tmp._hoodie_file_name, 
    public.ghcn_tmp.ID, 
    public.ghcn_tmp.DATE, 
    public.ghcn_tmp.ELEMENT, 
    public.ghcn_tmp.DATA_VALUE, 
    public.ghcn_tmp.M_FLAG, 
    public.ghcn_tmp.Q_FLAG, 
    public.ghcn_tmp.S_FLAG, 
    public.ghcn_tmp.OBS_TIME
);

The next step is to verify the result on the Redshift side.

Validate updated records in the Redshift table

Complete the following steps to validate the updated records in the Redshift table:

  1. On the Amazon Redshift console, open Query Editor v2.
  2. Run the following query: 
    SELECT * FROM "dev"."public"."ghcn" WHERE ID = 'AE000041196'

The query returns the following result set.

Now you see that the four records have been updated with the new records in 2023. If you have further future records, this approach works well to upsert new records based on the primary keys.

Load data incrementally from a Delta Lake table to Snowflake using a Delta change data feed

This tutorial uses a Delta change data feed to load data from a Delta table, and then merge the changes to Snowflake.

Ingest initial data to a Delta table

Complete the following steps:

  1. Open AWS Glue Studio.
  2. Choose ETL jobs.
  3. Choose Visual with a source and target.
  4. For Source and Target, choose Amazon S3, then choose Create.

A new visual job configuration appears. The next step is to configure the data source to read an example dataset.

  1. Name this new job delta-data-ingestion.
  2. Under Visual, choose Data source – S3 bucket.
  3. Under Node properties, for S3 source type, select S3 location.
  4. For S3 URL, enter s3://noaa-ghcn-pds/csv/by_year/2022.csv.

The data source is configured. The next step is to configure the data target to ingest data in Apache Hudi on your S3 bucket.

  1. Choose Data target – S3 bucket.
  2. Under Data target properties – S3, for Format, choose Delta Lake.
  3. For Compression Type, choose Snappy.
  4. For S3 Target location, enter s3://<Your S3 bucket name>/<Your S3 bucket prefix>/delta_incremental/ghcn/. (Provide your S3 bucket name and prefix.)
  5. For Data Catalog update options, select Do not update the Data Catalog.

Now your data integration job is authored in the visual editor completely. Let’s add an additional detail about the IAM role and job parameters, and then run the job.

  1. Under Job details, for IAM Role, choose your IAM role.
  2. Under Job parameters, for Key, enter --conf and for Value, enter spark.databricks.delta.properties.defaults.enableChangeDataFeed=true.
  3. Choose Save, then choose Run.

Load data from the Delta table to a Snowflake table

Complete the following steps to load data from the Delta table to a Snowflake table:

  1. Download the file delta2snowflake-incremental-load.ipynb.
  2. On AWS Glue Studio, choose Jupyter Notebook, then choose Create.
  3. For Job name, enter delta-ghcn-incremental-load-notebook.
  4. For IAM Role, choose your IAM role.
  5. Choose Start notebook.

Wait for the notebook to be ready.

  1. Run the first cell to start an AWS Glue interactive session.
  2. Replace the parameters with yours and run the cell under Configure your resource.
  3. Run the cell under Initialize SparkSession and GlueContext.
  4. Run the cell under Determine target time range for CDC.
  5. Run the cells under Run query to load data updated during a given timeframe.
  6. Run the cells under Merge changes into destination table.

You can see the exact query immediately run right after ingesting a temp table in the Snowflake table.

  1. Run the cell under Update the last query end time.

Validate initial records in the Snowflake warehouse

Run the following query in Snowflake:

SELECT * FROM "dev"."public"."ghcn" WHERE ID = 'AE000041196'

The query should return the following result set:

There are three records returned in this query.

Update and delete a record on the Delta table

Complete the following steps to update and delete a record on the Delta table as sample operations:

  1. Return to the AWS Glue notebook job.
  2. Run the cells under Update the record and Delete the record.

Load data incrementally from the Delta table to the Snowflake table

Complete the following steps to load the ingested records incrementally to the Redshift table:

  1. On AWS Glue Studio, choose the job delta-ghcn-incremental-load-notebook.
  2. Run all the cells again.

When you run the cells under Run query, you will notice that there are only three records, which correspond to the update and delete operation performed in the previous step.

In the cells under Merge changes into destination table, the changes are merged into the Snowflake table. The generated MERGE query statement in the notebook is as follows:

MERGE INTO public.ghcn USING public.ghcn_tmp ON 
    public.ghcn.ID = public.ghcn_tmp.ID AND 
    public.ghcn.DATE = public.ghcn_tmp.DATE AND 
    public.ghcn.ELEMENT = public.ghcn_tmp.ELEMENT 
WHEN MATCHED AND public.ghcn_tmp._change_type = 'update_postimage' THEN UPDATE SET 
    ID = public.ghcn_tmp.ID, 
    DATE = public.ghcn_tmp.DATE, 
    ELEMENT = public.ghcn_tmp.ELEMENT, 
    DATA_VALUE = public.ghcn_tmp.DATA_VALUE, 
    M_FLAG = public.ghcn_tmp.M_FLAG, 
    Q_FLAG = public.ghcn_tmp.Q_FLAG, 
    S_FLAG = public.ghcn_tmp.S_FLAG, 
    OBS_TIME = public.ghcn_tmp.OBS_TIME, 
    _change_type = public.ghcn_tmp._change_type, 
    _commit_version = public.ghcn_tmp._commit_version, 
    _commit_timestamp = public.ghcn_tmp._commit_timestamp 
WHEN MATCHED AND public.ghcn_tmp._change_type = 'delete' THEN DELETE 
WHEN NOT MATCHED THEN INSERT VALUES (
    public.ghcn_tmp.ID, 
    public.ghcn_tmp.DATE, 
    public.ghcn_tmp.ELEMENT, 
    public.ghcn_tmp.DATA_VALUE, 
    public.ghcn_tmp.M_FLAG, 
    public.ghcn_tmp.Q_FLAG, 
    public.ghcn_tmp.S_FLAG, 
    public.ghcn_tmp.OBS_TIME, 
    public.ghcn_tmp._change_type, 
    public.ghcn_tmp._commit_version, 
    public.ghcn_tmp._commit_timestamp
);

The next step is to verify the result on the Snowflake side.

Validate updated records in the Snowflake table

Complete the following steps to validate the updated and deleted records in the Snowflake table:

  1. On Snowflake, run the following query: 
    SELECT * FROM ghcn WHERE ID = 'AE000041196' AND DATE = '20221231'

The query returns the following result set:

You will notice that the query only returns two records. The value of DATA_VALUE of the record ELEMENT=PRCP has been updated from 0 to 12345. The record ELEMENT=TMAX has been deleted. This means that your update and delete operations on the source Delta table have been successfully replicated to the target Snowflake table.

Clean up

Complete the following steps to clean up your resources:

  1. Delete the following AWS Glue jobs:
    • hudi-data-ingestion
    • hudi-ghcn-incremental-load-notebook
    • delta-data-ingestion
    • delta-ghcn-incremental-load-notebook
  2. Clean up your S3 bucket.
  3. If needed, delete the Redshift cluster or the Redshift Serverless workgroup.

Conclusion

This post discussed architecture patterns to keep a copy of your data between data lakes using open table formats and data warehouses in sync and up to date. We also discussed the benefits of incremental loading and the techniques for achieving the use case using AWS Glue. We covered two use cases: incremental load from a Hudi table to Amazon Redshift, and from a Delta table to Snowflake.

About the author

Noritaka Sekiyama is a Principal Big Data Architect on the AWS Glue team. He works based in Tokyo, Japan. He is responsible for building software artifacts to help customers. In his spare time, he enjoys cycling with his road bike.

Maintaining a local copy of your data in AWS Local Zones

Post Syndicated from Macey Neff original https://aws.amazon.com/blogs/compute/maintaining-a-local-copy-of-your-data-in-aws-local-zones/

This post is written by Leonardo Solano, Senior Hybrid Cloud SA and Obed Gutierrez, Solutions Architect, Enterprise.

This post covers data replication strategies to back up your data into AWS Local Zones. These strategies include database replication, file based and object storage replication, and partner solutions for Amazon Elastic Compute Cloud (Amazon EC2).

Customers running workloads in AWS Regions are likely to require a copy of their data in their operational location for either their backup strategy or data residency requirements. To help with these requirements, you can use Local Zones.

Local Zones is an AWS infrastructure deployment that places compute, storage, database, and other select AWS services close to large population and industry centers. With Local Zones, customers can build and deploy workloads to comply with state and local data residency requirements in sectors such as healthcare, financial services, gaming, and government.

Solution overview

This post assumes the database source is Amazon Relational Database Service (Amazon RDS). To backup an Amazon RDS database to Local Zones, there are three options:

  1. AWS Database Migration Service (AWS DMS)
  2. AWS DataSync
  3. Backup to Amazon Simple Storage Service (Amazon S3)

. Amazon RDS replication to Local Zones with AWS DMS

Figure 1. Amazon RDS replication to Local Zones with AWS DMS

To replicate data, AWS DMS needs a source and a target database. The source database should be your existing Amazon RDS database. The target database is placed in an EC2 instance in the Local Zone. A replication job is created in AWS DMS, which maintains the source and target databases in sync. The replicated database in the Local Zone can be accessed through a VPN. Your database administrator can directly connect to the database engine with your preferred tool.

With this architecture, you can maintain a locally accessible copy of your databases, allowing you to comply with regulatory requirements.

Prerequisites

The following prerequisites are required before continuing:

  • An AWS Account with Administrator permissions;
  • Installation of the latest version of AWS Command Line Interface (AWS CLI v2);
  • An Amazon RDS database.

Walkthrough

1. Enabling Local Zones

First, you must enable Local Zones. Make sure that the intended Local Zone is parented to the AWS Region where the environment is running. Edit the commands to match your parameters, group-name makes reference to your local zone group and region to the region identifier to use.

aws ec2 modify-availability-zone-group \
  --region us-east-1 \
  --group-name us-east-1-qro-1\
  --opt-in-status opted-in

If you have an error when calling the ModifyAvailabilityZoneGroup operation, you must sign up for the Local Zone.

After enabling the Local Zone, you must extend the VPC to the Local Zone by creating a subnet in the Local Zone:

aws ec2 create-subnet \
  --region us-east-1 \
  --availability-zone us-east-1-qro-1a \
  --vpc-id vpc-02a3eb6585example \
  --cidr-block my-subnet-cidr

If you need a step-by-step guide, refer to Getting started with AWS Local Zones. Enabling Local Zones is free of charge. Only deployed services in the Local Zone incur billing.

2. Set up your target database

Now that you have the Local Zone enabled with a subnet, set up your target database instance in the Local Zone subnet that you just created.

You can use AWS CLI to launch it as an EC2 instance:

aws ec2 run-instances \
  --region us-east-1 \
  --subnet-id subnet-08fc749671example \
  --instance-type t3.medium \
  --image-id ami-0abcdef123example \
  --security-group-ids sg-0b0384b66dexample \
  --key-name my-key-pair

You can verify that your EC2 instance is running with the following command:

aws ec2 describe-instances --filters "Name=availability-zone,Values=us-east-1-qro-1a" --query "Reservations[].Instances[].InstanceId"

Output:

 $ ["i-0cda255374example"]

Note that not all instance types are available in Local Zones. You can verify it with the following AWS CLI command:

aws ec2 describe-instance-type-offerings --location-type "availability-zone" \
--filters Name=location,Values=us-east-1-qro-1a --region us-east-1

Once you have your instance running in the Local Zone, you can install the database engine matching your source database. Here is an example of how to install MariaDB:

  1. Updates all packages to the latest OS versionsudo yum update -y
  2. Install MySQL server on your instance, this also creates a systemd servicesudo yum install -y mariadb-server
  3. Enable the service created in previous stepsudo systemctl enable mariadb
  4. Start the MySQL server service on your Amazon Linux instancesudo systemctl start mariadb
  5. Set root user password and improve your DB securitysudo mysql_secure_installation

You can confirm successful installation with these commands:

mysql -h localhost -u root -p
SHOW DATABASES;

3. Configure databases for replication

In order for AWS DMS to replicate ongoing changes, you must use change data capture (CDC), as well as set up your source and target database accordingly before replication:

Source database:

  • Make sure that the binary logs are available to AWS DMS:

 call mysql.rds_set_configuration('binlog retention hours', 24);

  • Set the binlog_format parameter to “ROW“.
  • Set the binlog_row_image parameter to “Full“.
  • If you are using Read replica as source, then set the log_slave_updates parameter to TRUE.

For detailed information, refer to Using a MySQL-compatible database as a source for AWS DMS, or sources for your migration if your database engine is different.

Target database:

  • Create a user for AWS DMS that has read/write privileges to the MySQL-compatible database. To create the necessary privileges, run the following commands.
CREATE USER ''@'%' IDENTIFIED BY '';
GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT ON .* TO 
''@'%';
GRANT ALL PRIVILEGES ON awsdms_control.* TO ''@'%';
  • Disable foreign keys on target tables, by adding the next command in the Extra connection attributes section of the AWS DMS console for your target endpoint.

Initstmt=SET FOREIGN_KEY_CHECKS=0;

  • Set the database parameter local_infile = 1 to enable AWS DMS to load data into the target database.

4. Set up AWS DMS

Now that you have our Local Zone enabled with the target database ready and the source database configured, you can set up AWS DMS Replication instance.

Go to AWS DMS in the AWS Management Console, and under Migrate data select Replication Instances, then select the Create Replication button:

This shows the Create replication Instance, where you should fill up the parameters required:

Note that High Availability is set to Single-AZ, as this is a test workload, while Multi-AZ is recommended for Production workloads.

Refer to the AWS DMS replication instance documentation for details about how to size your replication instance.

Important note

To allow replication, make sure that you set up the replication instance in the VPC that your environment is running, and configure security groups from and to the source and target database.

Now you can create the DMS Source and Target endpoints:

5. Set up endpoints

Source endpoint:

In the AWS DMS console, select Endpoints, select the Create endpoint button, and select Source endpoint option. Then, fill the details required:

Make sure you select your RDS instance as Source by selecting the check box as show in the preceding figure. Moreover, include access to endpoint database details, such as user and password.

You can test your endpoint connectivity before creating it, as shown in the following figure:

If your test is successful, then you can select the Create endpoint button.

Target endpoint:

In the same way as the Source in the console, select Endpoints, select the Create endpoint button, and select Target endpoint option, then enter the details required, as shown in the following figure:

In the Access to endpoint database section, select Provide access information manually option, next add your Local Zone target database connection details as shown below. Notice that Server name value, should be the IP address of your target database.

Make sure you go to the bottom of the page and configure Extra connection attributes in the Endpoint settings, as described in the Configure databases for replication section of this post:

Like the source endpoint, you can test your endpoint connection before creating it.

6. Create the replication task

Once the endpoints are ready, you can create the migration task to start the replication. Under the Migrate Data section, select Database migration tasks, hit the Create task button, and configure your task:

Select Migrate existing data and replicate ongoing changes in the Migration type parameter.

Enable Task logs under Task Settings. This is recommended as it can help you with troubleshooting purposes.

In Table mappings, include the schema you want to replicate to the Local Zone database:

Once you have defined Task Configuration, Task Settings, and Table Mappings, you can proceed to create your database migration task.

This will trigger your migration task. Now wait until the migration task completes successfully.

7. Validate replicated database

After the replication job completes the Full Load, proceed to validate at your target database. Connect to your target database and run the following commands:

USE example;
SHOW TABLES;

As a result you should see the same tables as the source database.

MySQL [example]> SHOW TABLES;
+----------------------------+
| Tables_in_example          |
+----------------------------+
| actor                      |
| address                    |
| category                   |
| city                       |
| country                    |
| customer                   |
| customer_list              |
| film                       |
| film_actor                 |
| film_category              |
| film_list                  |
| film_text                  |
| inventory                  |
| language                   |
| nicer_but_slower_film_list |
| payment                    |
| rental                     |
| sales_by_film_category     |
| sales_by_store             |
| staff                      |
| staff_list                 |
| store                      |
+----------------------------+
22 rows in set (0.06 sec)

If you get the same tables from your source database, then congratulations, you’re set! Now you can maintain and navigate a live copy of database in the Local Zone for data residency purposes.

Clean up

When you have finished this tutorial, you can delete all the resources that have been deployed. You can do this in the Console or by running the following commands in the AWS CLI:

  1. Delete target DB: 
    aws ec2 terminate-instances --instance-ids i-abcd1234
  2. Decommision AWS DMS
    • Replication Task: 
      aws dms delete-replication-task --replication-task-arn arn:aws:dms:us-east-1:111111111111:task:K55IUCGBASJS5VHZJIIEXAMPLE
    • Endpoints: 
      aws dms delete-endpoint --endpoint-arn arn:aws:dms:us-east-1:111111111111:endpoint:OUJJVXO4XZ4CYTSEG5XEXAMPLE
    • Replication instance: 
      aws dms delete-replication-instance --replication-instance-arn us-east-1:111111111111:rep:T3OM7OUB5NM2LCVZF7JEXAMPLE
  3. Delete Local Zone subnet 
    aws ec2 delete-subnet --subnet-id subnet-9example

Conclusion

Local Zones is a useful tool for running applications with low latency requirements or data residency regulations. In this post, you have learned how to use AWS DMS to seamlessly replicate your data to Local Zones. With this architecture you can efficiently maintain a local copy of your data in Local Zones and access it securly.

If you are interested on how to automate your workloads deployments in Local Zones, make sure you check this workshop.

Load Balancing 2.0: What’s Changed After 7 Years?

Post Syndicated from nathaniel wagner original https://www.backblaze.com/blog/load-balancing-2-0-whats-changed-after-7-years/

A decorative image showing a file, a drive, and some servers.

What do two billion transactions a day look like? Well, the data may be invisible to the naked eye, but the math breaks down to just over 23,000 transactions every second. (Shout out to Kris Allen for burning into my memory that there are 86,400 seconds in a day and my handy calculator!) 

Part of my job as a Site Reliability Engineer (SRE) at Backblaze is making sure that greater than 99.9% of those transactions are what we consider “OK” (via status code), and part of the fun is digging for the needle in the haystack of over 7,000 production servers and over 250,000 spinning hard drives to try and understand how all of the different transactions interact with the pieces of infrastructure. 

In this blog post, I’m going to pick up where Principal SRE Elliott Sims left off in his 2016 article on load balancing. You’ll notice that the design principles we’ve employed are largely the same (cool!). So, I’ll review our stance on those principles, then talk about how the evolution of the B2 Cloud Storage platform—including the introduction of the S3 Compatible API—has changed our load balancing architecture. Read on for specifics. 

Editor’s Note

We know there are a ton of specialized networking terms flying around this article, and one of our primary goals is to make technical content accessible to all readers, regardless of their technical background. To that end, we’ve used footnotes to add some definitions and minimize the disruption to your reading experience.

What Is Load Balancing?

Load balancing is the process of distributing traffic across a network. It helps with resource utilization, prevents overloading any one server, and makes your system more reliable. Load balancers also monitor server health and redirect requests to the most suitable server.

With two billion requests per day to our servers, you can be assured that we use load balancers at Backblaze. Whenever anyone—a Backblaze Computer Backup or a B2 Cloud Storage customer—wants to upload or download data or modify or interact with their files, a load balancer will be there to direct traffic to the right server. Think of them as your trusty mail service, delivering your letters and packages to the correct destination—and using things like zip codes and addresses to interpret your request and get things to the right place.  

How Do We Do It?

We build our own load balancers using open-source tools. We use layer 4 load balancing with direct server response (DSR). Here are some of the resources that we call on to make that happen:  

  • Border gateway patrol (BGP) which is part of the Linux kernel1. It’s a standardized gateway protocol that exchanges routing and reachability information on the internet.   
  • keepalived, an open-source routing software. keepalived keeps track of all of our VIPs2 and IPs3 for each backend server. 
  • Hard disk drives (HDDs). We use the same drives that we use for other API servers and whatnot, but that’s definitely overkill—we made that choice to save the work of sourcing another type of device.  
  • A lot of hard work by a lot of really smart folks.

What We Mean by Layers

When we’re talking about layers in load balancing, it’s shorthand for how deep into the architecture your program needs to see. Here’s a great diagram that defines those layers: 

An image describing application layers.
Source.

DSR takes place at layer 4, but solves the problem presented by a full proxy4 method, having to see the original client’s IP address.

Why Do We Do It the Way We Do It?

Building our own load balancers, instead of buying an off-the-shelf solution, means that we have more control and insight, more cost-effective hardware, and more scalable architecture. In general, DSR is more complicated to set up and maintain, but this method also lets us handle lots of traffic with minimal hardware and supports our goal of keeping data encrypted, even within our own data center. 

What Hasn’t Changed

We’re still using a layer 4 DSR approach to load balancing, which we’ll explain below. For reference, other common methods of load balancing are layer 7, full proxy and layer 4, full proxy load balancing. 

First, I’ll explain how DSR works. DSR load balancing requires two things:

  1. A load balancer with the VIP address attached to an external NIC5 and ARPing6, so that the rest of the network knows it “owns” the IP.
  2. Two or more servers on the same layer 2 network that also have the VIP address attached to a NIC, either internal or external, but are not replying to ARP requests about that address. This means that no other servers on the network know that the VIP exists anywhere but on the load balancer.

A request packet will enter the network, and be routed to the load balancer. Once it arrives there, the load balancer leaves the source and destination IP addresses intact and instead modifies the destination MAC7 address to that of a server, then puts the packet back on the network. The network switch only understands MAC addresses, so it forwards the packet on to the correct server.

A diagram of how a packet moves through the network router and load balancer to reach the server, then respond to the original client request.

When the packet arrives at the server’s network interface, it checks to make sure the destination MAC address matches its own. The address matches, so the server accepts the packet. The server network interface then, separately, checks to see whether the destination IP address is one attached to it somehow. That’s a yes, even though the rest of the network doesn’t know it, so the server accepts the packet and passes it on to the application. The application then sends a response with the VIP as the source IP address and the client as the destination IP, so the request (and subsequent response) is routed directly to the client without passing back through the load balancer.

So, What’s Changed?

Lots of things. But, since we first wrote this article, we’ve expanded our offerings and platform. The biggest of these changes (as far as load balancing is concerned) is that we added the S3 Compatible API. 

We also serve a much more diverse set of clients, both in the size of files they have and their access patterns. File sizes affect how long it takes us to serve requests (larger files = more time to upload or download, which means an individual server is tied up for longer). Access patterns can vastly increase the amount of requests a server has to process on a regular, but not consistent basis (which means you might have times that your network is more or less idle, and you have to optimize appropriately). 

A definitely Photoshopped images showing a giraffe riding an elephant on a rope in the sky. The rope's anchor points disappear into clouds.
So, if we were to update this amazing image from the first article, we might have a tightrope walker with a balancing pole on top of the giraffe, plus some birds flying on a collision course with the elephant.

Where You Can See the Changes: ECMP, Volume of Data Per Month, and API Processing

DSR is how we send data to the customer—the server responds (sends data) directly to the request (client). This is the equivalent of going to the post office to mail something, but adding your home address as the return address (so that you don’t have to go back to the post office to get your reply).   

Given how our platform has evolved over the years, things might happen slightly differently. Let’s dig in to some of the details that affect how the load balancers make their decisions—what rules govern how they route traffic, and how different types of requests cause them to behave differently. We’ll look at:

  • Equal cost multipath routing (ECMP). 
  • Volume of data in petabytes (PBs) per month.
  • APIs and processing costs.

ECMP

One thing that’s not explicitly outlined above is how the load balancer determines which server should respond to a request. At Backblaze, we use stateless load balancing, which means that the load balancer doesn’t take into account most information about the servers it routes to. We use a round robin approach—i.e. the load balancers choose between one of a few hosts, in order, each time they’re assigning a request. 

We also use Maglev, so the load balancers use consistent hashing and connection tracking. This means that we’re minimizing the negative impact of unexpected faults failures from connection-oriented protocols. If a load balancer goes down, its server pool can be transferred to another, and it will make decisions in the same way, seamlessly picking up the load. When the initial load balancer comes back online, it already has a connection to its load balancer friend and can pick up where it left off. 

The upside is that it’s super rare to see a disruption, and it essentially only happens when the load balancer and the neighbor host go down in a short period of time. The downside is that the load balancer decision is static. If you have “better” servers for one reason or another—they’re newer, for instance—they don’t take that information into account. On the other hand, we do have the ability to push more traffic to specific servers through ECMP weights if we need to, which means that we have good control over a diverse fleet of hardware. 

Volume of Data

Backblaze now has over three exabytes of storage under management. Based on the scalability of the network design, that doesn’t really make a huge amount of difference when you’re scaling your infrastructure properly. What can make a difference is how people store and access their data. 

Most of the things that make managing large datasets difficult from an architecture perspective can also be silly for a client. For example: querying files individually (creating lots of requests) instead of batching or creating a range request. (There may be a business reason to do that, but usually, it makes more sense to batch requests.)

On the other hand, some things that make sense for how clients need to store data require architecture realignment. One of those is just a sheer fluctuation of data by volume—if you’re adding and deleting large amounts of data (we’re talking hundreds of terabytes or more) on a “shorter” cycle (monthly or less), then there will be a measurable impact. And, with more data stored, you have the potential for more transactions.

Similarly, if you need to retrieve data often, but not regularly, there are potential performance impacts. Most of them are related to caching, and ironically, they can actually improve performance. The more you query the same “set” of servers for the same file, the more likely that each server in the group will have cached your data locally (which means they can serve it more quickly). 

And, as with most data centers, we store our long term data on hard disk drives (HDDs), whereas our API servers are on solid state drives (SSDs). There are positives and negatives to each type of drive, but the performance impact is that data at rest takes longer to retrieve, and data in the cache is on a faster SSD drive on the API server. 

On the other hand, the more servers the data center has, the lower the chance that the servers can/will deliver cached data. And, of course, if you’re replacing large volumes of old data with new on a shorter timeline, then you won’t see the benefits. It sounds like an edge case, but industries like security camera data are a great example. While they don’t retrieve their data very frequently, they are constantly uploading and overwriting their data, often to meet different industry requirements about retention periods, which can be challenging to allocate a finite amount of input/output operations per second (IOPS) for uploads, downloads, and deletes.  

That said, the built-in benefit of our system is that adding another load balancer is (relatively) cheap. If we’re experiencing a processing chokepoint for whatever reason—typically either a CPU bottleneck or from throughput on the NIC—we can add another load balancer, and just like that, we can start to see bits flying through the new load balancer and traffic being routed amongst more hosts, alleviating the choke points. 

APIs and Processing Costs

We mentioned above that one of the biggest changes to our platform was the addition of the S3 Compatible API. When all requests were made through the B2 Native API, the Backblaze CLI tool, or the web UI, the processing cost was relatively cheap. 

That’s because of the way our upload requests to the Backblaze Vaults are structured. When you make an upload request via the Native API, there are actually two transactions, one to get an upload URL, and the second to send a request to the Vault. And, all other types of requests (besides upload) have always had to be processed through our load balancers. Since the S3 Compatible API is a single request, we knew we would have to add more processing power and load balancers. (If you want to go back to 2018 and see some of the reasons why, here’s Brian Wilson on the subject—read with the caveat that our current Tech Doc on the subject outlines how we solve the complications he points out.) 

We’re still leveraging DSR to respond directly to the client, but we’ve significantly increased the amount of transactions that hit our load balancers, both because it has to take on more of the processing during transit and because, well, lots of folks like to use the S3 Compatible API and our customer base has grown by a quite a bit since 2018. 

And, just like above, we’ve set ourselves up for a relatively painless fix: we can add another load balancer to solve most problems. 

Do We Have More Complexity?

This is the million dollar question, solved for a dollar: how could we not? Since our first load balancing article, we’ve added features, complexity, and lots of customers. Load balancing algorithms are inherently complex, but we (mostly Elliott and other smart people) have taken a lot of time and consideration to not just build a system that will scale to up and past two billion transactions a day, but that can be fairly “easily” explained and doesn’t require a graduate degree to understand what is happening.  

But, we knew it was important early on, so we prioritized building a system where we could “just” add another load balancer. The thinking is more complicated at the outset, but the tradeoff is that it’s simple once you’ve designed the system. It would take a lot for us to outgrow the usefulness of this strategy—but hey, we might get there someday. When we do, we’ll write you another article. 

Footnotes

  1. Kernel: A kernel is the computer program at the core of a computer’s operating system. It has control of the system and does things like run processes, manage hardware devices like the hard drive, and handle interrupts, as well as memory and input/output (I/O) requests from software, translating them to instructions for the central processing unit (CPU). ↩︎
  2. Virtual internet protocol (VIP): An IP address that does not correspond to a real place. ↩︎
  3. Internet protocol (IP): The global physical address of a device, used to identify devices on the internet. Can be changed.  ↩︎
  4. Proxy: In networking, a proxy is a server application that validates outside requests to a network. Think of them as a gatekeeper. There are several common types of proxies you interact with all the time—HTTPS requests on the internet, for example. ↩︎
  5. Network interface controller, or network interface card (NIC): This connects the computer to the network. ↩︎
  6. Address resolution protocol (ARP): The process by which a device or network identifies another device. There are four types. ↩︎
  7. Media access control (MAC): The local physical address of a device, used to identify devices on the same network. Hardcoded into the device. ↩︎

The post Load Balancing 2.0: What’s Changed After 7 Years? appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

Център АЛЕФ дава старт на XI Международен литературен ученически конкурс „Който спаси един човешки живот, спасява цяла вселена”

Post Syndicated from Николай Марченко original https://bivol.bg/%D1%86%D0%B5%D0%BD%D1%82%D1%8A%D1%80-%D0%B0%D0%BB%D0%B5%D1%84-%D0%B4%D0%B0%D0%B2%D0%B0-%D1%81%D1%82%D0%B0%D1%80%D1%82-%D0%BD%D0%B0-xi-%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%D0%BD%D0%B0%D1%80%D0%BE%D0%B4%D0%B5.html

четвъртък 19 октомври 2023


От днес изкушените от литературата, киното и историята млади хора могат да дадат полет на своето въображение и да участват в конкурса „Който спаси един човешки живот, спасява цяла вселена”.…

[$] Toward safer GNU C Library tunable handling

Post Syndicated from corbet original https://lwn.net/Articles/947736/

When considering the interface provided by the GNU C Library (glibc),
thoughts naturally turn to the programming interface as specified by POSIX,
along with numerous extensions added over the years. But glibc also
provides a “tunables” interface to control how the library operates; rather
than being managed by a C API, tunables are set with the
GLIBC_TUNABLES environment
variable. Glibc tunables have been a part of a few security problems
involving setuid binaries, most recently the “Looney
Tunables” bug disclosed at the beginning of October. The glibc
developers are now considering significant changes to tunable handling in
the hope of avoiding such problems in the future.

AMD Ryzen Threadripper Pro 7000WX at 96 Cores and Threadripper 7000 HEDT

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/amd-ryzen-threadripper-pro-7000wx-at-96-cores-and-threadripper-7000-hedt/

The new AMD Ryzen Threadripper Pro 7000WX and Threadripper 7000 parts are launched bringing Genoa-era CPUs to the workstation market

The post AMD Ryzen Threadripper Pro 7000WX at 96 Cores and Threadripper 7000 HEDT appeared first on ServeTheHome.

Security updates for Thursday

Post Syndicated from corbet original https://lwn.net/Articles/948246/

Security updates have been issued by Debian (node-babel), Fedora (moodle), Gentoo (mailutils), Oracle (go-toolset:ol8 and java-11-openjdk), Red Hat (ghostscript, grafana, java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, nghttp2, nodejs:16, nodejs:18, and rhc-worker-script), SUSE (cni, cni-plugins, container-suseconnect, containerd, cups, exim, grub2, helm, libeconf, nodejs18, python3, runc, slurm, supportutils, and tomcat), and Ubuntu (glib2.0, openssl, and vips).

Securing generative AI: An introduction to the Generative AI Security Scoping Matrix

Post Syndicated from Matt Saner original https://aws.amazon.com/blogs/security/securing-generative-ai-an-introduction-to-the-generative-ai-security-scoping-matrix/

Generative artificial intelligence (generative AI) has captured the imagination of organizations and is transforming the customer experience in industries of every size across the globe. This leap in AI capability, fueled by multi-billion-parameter large language models (LLMs) and transformer neural networks, has opened the door to new productivity improvements, creative capabilities, and more.

As organizations evaluate and adopt generative AI for their employees and customers, cybersecurity practitioners must assess the risks, governance, and controls for this evolving technology at a rapid pace. As security leaders working with the largest, most complex customers at Amazon Web Services (AWS), we’re regularly consulted on trends, best practices, and the rapidly evolving landscape of generative AI and the associated security and privacy implications. In that spirit, we’d like to share key strategies that you can use to accelerate your own generative AI security journey.

This post, the first in a series on securing generative AI, establishes a mental model that will help you approach the risk and security implications based on the type of generative AI workload you are deploying. We then highlight key considerations for security leaders and practitioners to prioritize when securing generative AI workloads. Follow-on posts will dive deep into developing generative AI solutions that meet customers’ security requirements, best practices for threat modeling generative AI applications, approaches for evaluating compliance and privacy considerations, and will explore ways to use generative AI to improve your own cybersecurity operations.

Where to start

As with any emerging technology, a strong grounding in the foundations of that technology is critical to helping you understand the associated scopes, risks, security, and compliance requirements. To learn more about the foundations of generative AI, we recommend that you start by reading more about what generative AI is, its unique terminologies and nuances, and exploring examples of how organizations are using it to innovate for their customers.

If you’re just starting to explore or adopt generative AI, you might imagine that an entirely new security discipline will be required. While there are unique security considerations, the good news is that generative AI workloads are, at their core, another data-driven computing workload, and they inherit much of the same security regimen. The fact is, if you’ve invested in cloud cybersecurity best practices over the years and embraced prescriptive advice from sources like Steve’s top 10, the Security Pillar of the Well-Architected Framework, and the Well-Architected Machine Learning Lens, you’re well on your way!

Core security disciplines, like identity and access management, data protection, privacy and compliance, application security, and threat modeling are still critically important for generative AI workloads, just as they are for any other workload. For example, if your generative AI application is accessing a database, you’ll need to know what the data classification of the database is, how to protect that data, how to monitor for threats, and how to manage access. But beyond emphasizing long-standing security practices, it’s crucial to understand the unique risks and additional security considerations that generative AI workloads bring. This post highlights several security factors, both new and familiar, for you to consider.

With that in mind, let’s discuss the first step: scoping.

Determine your scope

Your organization has made the decision to move forward with a generative AI solution; now what do you do as a security leader or practitioner? As with any security effort, you must understand the scope of what you’re tasked with securing. Depending on your use case, you might choose a managed service where the service provider takes more responsibility for the management of the service and model, or you might choose to build your own service and model.

Let’s look at how you might use various generative AI solutions in the AWS Cloud. At AWS, security is a top priority, and we believe providing customers with the right tool for the job is critical. For example, you can use the serverless, API-driven Amazon Bedrock with simple-to-consume, pre-trained foundation models (FMs) provided by AI21 Labs, Anthropic, Cohere, Meta, stability.ai, and Amazon Titan. Amazon SageMaker JumpStart provides you with additional flexibility while still using pre-trained FMs, helping you to accelerate your AI journey securely. You can also build and train your own models on Amazon SageMaker. Maybe you plan to use a consumer generative AI application through a web interface or API such as a chatbot or generative AI features embedded into a commercial enterprise application your organization has procured. Each of these service offerings has different infrastructure, software, access, and data models and, as such, will result in different security considerations. To establish consistency, we’ve grouped these service offerings into logical categorizations, which we’ve named scopes.

In order to help simplify your security scoping efforts, we’ve created a matrix that conveniently summarizes key security disciplines that you should consider, depending on which generative AI solution you select. We call this the Generative AI Security Scoping Matrix, shown in Figure 1.

The first step is to determine which scope your use case fits into. The scopes are numbered 1–5, representing least ownership to greatest ownership.

Buying generative AI:

  • Scope 1: Consumer app – Your business consumes a public third-party generative AI service, either at no-cost or paid. At this scope you don’t own or see the training data or the model, and you cannot modify or augment it. You invoke APIs or directly use the application according to the terms of service of the provider.
    Example: An employee interacts with a generative AI chat application to generate ideas for an upcoming marketing campaign.
  • Scope 2: Enterprise app – Your business uses a third-party enterprise application that has generative AI features embedded within, and a business relationship is established between your organization and the vendor.
    Example: You use a third-party enterprise scheduling application that has a generative AI capability embedded within to help draft meeting agendas.

Building generative AI:

  • Scope 3: Pre-trained models – Your business builds its own application using an existing third-party generative AI foundation model. You directly integrate it with your workload through an application programming interface (API).
    Example: You build an application to create a customer support chatbot that uses the Anthropic Claude foundation model through Amazon Bedrock APIs.
  • Scope 4: Fine-tuned models – Your business refines an existing third-party generative AI foundation model by fine-tuning it with data specific to your business, generating a new, enhanced model that’s specialized to your workload.
    Example: Using an API to access a foundation model, you build an application for your marketing teams that enables them to build marketing materials that are specific to your products and services.
  • Scope 5: Self-trained models – Your business builds and trains a generative AI model from scratch using data that you own or acquire. You own every aspect of the model.
    Example: Your business wants to create a model trained exclusively on deep, industry-specific data to license to companies in that industry, creating a completely novel LLM.

In the Generative AI Security Scoping Matrix, we identify five security disciplines that span the different types of generative AI solutions. The unique requirements of each security discipline can vary depending on the scope of the generative AI application. By determining which generative AI scope is being deployed, security teams can quickly prioritize focus and assess the scope of each security discipline.

Let’s explore each security discipline and consider how scoping affects security requirements.

  • Governance and compliance – The policies, procedures, and reporting needed to empower the business while minimizing risk.
  • Legal and privacy – The specific regulatory, legal, and privacy requirements for using or creating generative AI solutions.
  • Risk management – Identification of potential threats to generative AI solutions and recommended mitigations.
  • Controls – The implementation of security controls that are used to mitigate risk.
  • Resilience – How to architect generative AI solutions to maintain availability and meet business SLAs.

Throughout our Securing Generative AI blog series, we’ll be referring to the Generative AI Security Scoping Matrix to help you understand how various security requirements and recommendations can change depending on the scope of your AI deployment. We encourage you to adopt and reference the Generative AI Security Scoping Matrix in your own internal processes, such as procurement, evaluation, and security architecture scoping.

What to prioritize

Your workload is scoped and now you need to enable your business to move forward fast, yet securely. Let’s explore a few examples of opportunities you should prioritize.

Governance and compliance plus Legal and privacy

With consumer off-the-shelf apps (Scope 1) and enterprise off-the-shelf apps (Scope 2), you must pay special attention to the terms of service, licensing, data sovereignty, and other legal disclosures. Outline important considerations regarding your organization’s data management requirements, and if your organization has legal and procurement departments, be sure to work closely with them. Assess how these requirements apply to a Scope 1 or 2 application. Data governance is critical, and an existing strong data governance strategy can be leveraged and extended to generative AI workloads. Outline your organization’s risk appetite and the security posture you want to achieve for Scope 1 and 2 applications and implement policies that specify that only appropriate data types and data classifications should be used. For example, you might choose to create a policy that prohibits the use of personal identifiable information (PII), confidential, or proprietary data when using Scope 1 applications.

If a third-party model has all the data and functionality that you need, Scope 1 and Scope 2 applications might fit your requirements. However, if it’s important to summarize, correlate, and parse through your own business data, generate new insights, or automate repetitive tasks, you’ll need to deploy an application from Scope 3, 4, or 5. For example, your organization might choose to use a pre-trained model (Scope 3). Maybe you want to take it a step further and create a version of a third-party model such as Amazon Titan with your organization’s data included, known as fine-tuning (Scope 4). Or you might create an entirely new first-party model from scratch, trained with data you supply (Scope 5).

In Scopes 3, 4, and 5, your data can be used in the training or fine-tuning of the model, or as part of the output. You must understand the data classification and data type of the assets the solution will have access to. Scope 3 solutions might use a filtering mechanism on data provided through Retrieval Augmented Generation (RAG) with the help from Agents for Amazon Bedrock, for example, as an input to a prompt. RAG offers you an alternative to training or fine-tuning by querying your data as part of the prompt. This then augments the context for the LLM to provide a completion and response that can use your business data as part of the response, rather than directly embedding your data in the model itself through fine-tuning or training. See Figure 3 for an example data flow diagram demonstrating how customer data could be used in a generative AI prompt and response through RAG.

In scopes 4 and 5, on the other hand, you must classify the modified model for the most sensitive level of data classification used to fine-tune or train the model. Your model would then mirror the data classification on the data it was trained against. For example, if you supply PII in the fine-tuning or training of a model, then the new model will contain PII. Currently, there are no mechanisms for easily filtering the model’s output based on authorization, and a user could potentially retrieve data they wouldn’t otherwise be authorized to see. Consider this a key takeaway; your application can be built around your model to implement filtering controls on your business data as part of a RAG data flow, which can provide additional data security granularity without placing your sensitive data directly within the model.

From a legal perspective, it’s important to understand both the service provider’s end-user license agreement (EULA), terms of services (TOS), and any other contractual agreements necessary to use their service across Scopes 1 through 4. For Scope 5, your legal teams should provide their own contractual terms of service for any external use of your models. Also, for Scope 3 and Scope 4, be sure to validate both the service provider’s legal terms for the use of their service, as well as the model provider’s legal terms for the use of their model within that service.

Additionally, consider the privacy concerns if the European Union’s General Data Protection Regulation (GDPR) “right to erasure” or “right to be forgotten” requirements are applicable to your business. Carefully consider the impact of training or fine-tuning your models with data that you might need to delete upon request. The only fully effective way to remove data from a model is to delete the data from the training set and train a new version of the model. This isn’t practical when the data deletion is a fraction of the total training data and can be very costly depending on the size of your model.

Risk management

While AI-enabled applications can act, look, and feel like non-AI-enabled applications, the free-form nature of interacting with an LLM mandates additional scrutiny and guardrails. It is important to identify what risks apply to your generative AI workloads, and how to begin to mitigate them.

There are many ways to identify risks, but two common mechanisms are risk assessments and threat modeling. For Scopes 1 and 2, you’re assessing the risk of the third-party providers to understand the risks that might originate in their service, and how they mitigate or manage the risks they’re responsible for. Likewise, you must understand what your risk management responsibilities are as a consumer of that service.

For Scopes 3, 4, and 5—implement threat modeling—while we will dive deep into specific threats and how to threat-model generative AI applications in a future blog post, let’s give an example of a threat unique to LLMs. Threat actors might use a technique such as prompt injection: a carefully crafted input that causes an LLM to respond in unexpected or undesired ways. This threat can be used to extract features (features are characteristics or properties of data used to train a machine learning (ML) model), defame, gain access to internal systems, and more. In recent months, NIST, MITRE, and OWASP have published guidance for securing AI and LLM solutions. In both the MITRE and OWASP published approaches, prompt injection (model evasion) is the first threat listed. Prompt injection threats might sound new, but will be familiar to many cybersecurity professionals. It’s essentially an evolution of injection attacks, such as SQL injection, JSON or XML injection, or command-line injection, that many practitioners are accustomed to addressing.

Emerging threat vectors for generative AI workloads create a new frontier for threat modeling and overall risk management practices. As mentioned, your existing cybersecurity practices will apply here as well, but you must adapt to account for unique threats in this space. Partnering deeply with development teams and other key stakeholders who are creating generative AI applications within your organization will be required to understand the nuances, adequately model the threats, and define best practices.

Controls

Controls help us enforce compliance, policy, and security requirements in order to mitigate risk. Let’s dive into an example of a prioritized security control: identity and access management. To set some context, during inference (the process of a model generating an output, based on an input) first- or third-party foundation models (Scopes 3–5) are immutable. The API to a model accepts an input and returns an output. Models are versioned and, after release, are static. On its own, the model itself is incapable of storing new data, adjusting results over time, or incorporating external data sources directly. Without the intervention of data processing capabilities that reside outside of the model, the model will not store new data or mutate.

Both modern databases and foundation models have a notion of using the identity of the entity making a query. Traditional databases can have table-level, row-level, column-level, or even element-level security controls. Foundation models, on the other hand, don’t currently allow for fine-grained access to specific embeddings they might contain. In LLMs, embeddings are the mathematical representations created by the model during training to represent each object—such as words, sounds, and graphics—and help describe an object’s context and relationship to other objects. An entity is either permitted to access the full model and the inference it produces or nothing at all. It cannot restrict access at the level of specific embeddings in a vector database. In other words, with today’s technology, when you grant an entity access directly to a model, you are granting it permission to all the data that model was trained on. When accessed, information flows in two directions: prompts and contexts flow from the user through the application to the model, and a completion returns from the model back through the application providing an inference response to the user. When you authorize access to a model, you’re implicitly authorizing both of these data flows to occur, and either or both of these data flows might contain confidential data.

For example, imagine your business has built an application on top of Amazon Bedrock at Scope 4, where you’ve fine-tuned a foundation model, or Scope 5 where you’ve trained a model on your own business data. An AWS Identity and Access Management (IAM) policy grants your application permissions to invoke a specific model. The policy cannot limit access to subsets of data within the model. For IAM, when interacting with a model directly, you’re limited to model access.

{
	"Version": "2012-10-17",
	"Statement": {
		"Sid": "AllowInference",
		"Effect": "Allow",
		"Action": [
			"bedrock:InvokeModel"
		],
		"Resource": "arn:aws:bedrock:*::<foundation-model>/<model-id-of-model-to-allow>
	}
}

What could you do to implement least privilege in this case? In most scenarios, an application layer will invoke the Amazon Bedrock endpoint to interact with a model. This front-end application can use an identity solution, such as Amazon Cognito or AWS IAM Identity Center, to authenticate and authorize users, and limit specific actions and access to certain data accordingly based on roles, attributes, and user communities. For example, the application could select a model based on the authorization of the user. Or perhaps your application uses RAG by querying external data sources to provide just-in-time data for generative AI responses, using services such as Amazon Kendra or Amazon OpenSearch Serverless. In that case, you would use an authorization layer to filter access to specific content based on the role and entitlements of the user. As you can see, identity and access management principles are the same as any other application your organization develops, but you must account for the unique capabilities and architectural considerations of your generative AI workloads.

Resilience

Finally, availability is a key component of security as called out in the C.I.A. triad. Building resilient applications is critical to meeting your organization’s availability and business continuity requirements. For Scope 1 and 2, you should understand how the provider’s availability aligns to your organization’s needs and expectations. Carefully consider how disruptions might impact your business should the underlying model, API, or presentation layer become unavailable. Additionally, consider how complex prompts and completions might impact usage quotas, or what billing impacts the application might have.

For Scopes 3, 4, and 5, make sure that you set appropriate timeouts to account for complex prompts and completions. You might also want to look at prompt input size for allocated character limits defined by your model. Also consider existing best practices for resilient designs such as backoff and retries and circuit breaker patterns to achieve the desired user experience. When using vector databases, having a high availability configuration and disaster recovery plan is recommended to be resilient against different failure modes.

Instance flexibility for both inference and training model pipelines are important architectural considerations in addition to potentially reserving or pre-provisioning compute for highly critical workloads. When using managed services like Amazon Bedrock or SageMaker, you must validate AWS Region availability and feature parity when implementing a multi-Region deployment strategy. Similarly, for multi-Region support of Scope 4 and 5 workloads, you must account for the availability of your fine-tuning or training data across Regions. If you use SageMaker to train a model in Scope 5, use checkpoints to save progress as you train your model. This will allow you to resume training from the last saved checkpoint if necessary.

Be sure to review and implement existing application resilience best practices established in the AWS Resilience Hub and within the Reliability Pillar and Operational Excellence Pillar of the Well Architected Framework.

Conclusion

In this post, we outlined how well-established cloud security principles provide a solid foundation for securing generative AI solutions. While you will use many existing security practices and patterns, you must also learn the fundamentals of generative AI and the unique threats and security considerations that must be addressed. Use the Generative AI Security Scoping Matrix to help determine the scope of your generative AI workloads and the associated security dimensions that apply. With your scope determined, you can then prioritize solving for your critical security requirements to enable the secure use of generative AI workloads by your business.

Please join us as we continue to explore these and additional security topics in our upcoming posts in the Securing Generative AI series.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Matt Saner

Matt Saner

Matt is a Senior Manager leading security specialists at AWS. He and his team help the world’s largest and most complex organizations solve critical security challenges, and help security teams become enablers for their business. Before joining AWS, Matt spent nearly two decades working in the financial services industry, solving various technology, security, risk, and compliance challenges. He highly values life-long learning (security is never static) and holds a Masters in Cybersecurity from NYU. For fun, he’s a pilot who enjoys flying general aviation airplanes.

Mike Lapidakis

Mike Lapidakis

Mike leads the AWS Industries Specialist SA team, comprised of the Security and Compliance, Migration and Modernization, Networking, and Resilience domains. The team helps the largest customers on earth establish a strong foundation to transform their businesses through technical enablement, education, customer advocacy, and executive alignment. Mike has helped organizations modernize on the cloud for over a decade in various architecture and consulting roles.

Technical Support: The Zabbix Advantage

Post Syndicated from Michael Kammer original https://blog.zabbix.com/technical-support-the-zabbix-advantage/26709/

If you’ve ever been part of a technical support team (or dealt with technical support as a customer, for that matter) you’re aware that there are as many different types of technical support teams as there are types of businesses.

However, there are a few best practices that all technical support teams share, no matter what industry they’re in. Read on to learn a bit more about them and see how our technical support team at Zabbix embodies each one.

Offer omnichannel technical support

Omnichannel support is the practice of providing support across every touchpoint that a customer uses to interact with your business. It’s not to be confused with multi-channel support, where teams work in silos and have little or no interaction.

Omnichannel support provides a unified experience across different channels, including email, phone, live chat, in-app chat, etc. Customers can start a conversation on any channel, at any time, and pick it up from where they left off on any other channel, any other time. Businesses can keep all customer data in the form of contacts inside a single platform, so that their support representatives can address issues with the proper context.

The goal of our technical support service at Zabbix has always been to provide responsive, dependable, quality support to resolve any issues regarding the installation, operation, and use of Zabbix.

Our specialists also leverage their skills, experience, and proximity to the design and development teams pass along the kind of helpful hints, tips, and tricks that help customers get the most out of their Zabbix installation.

The backbone of our support delivery is the Zabbix Support System. Available to every Zabbix customer, it guarantees swift and easy communication between customers and our technical specialists.

Email and remote sessions can be used to communicate with Zabbix support at any time.  Customers with our Global or Enterprise support tiers can access support services by phone or take advantage of on-site visits anywhere in the world by lead technical engineers.

No matter the channel, there’s no guesswork involved – all information is automatically entered into the support system to keep track of issues and resolutions.

Set realistic SLAs and stick to them

Service level agreements (SLAs) are critical to technical support performance. They help set clear expectations for both the service provider and the customer by outlining what services will be provided, how they will be delivered, and the expected level of performance. This gives everyone involved a clear understanding of what to expect, prevents any misunderstandings, and makes sure that the customer’s needs are being met.

SLAs also provide a way to measure the performance of the service provider. By defining metrics and targets, both parties can track the provider’s performance and make sure that they’re meeting the agreed-upon standards. This can help identify areas for improvement and provide a way to hold the service provider accountable if they don’t meet their obligations.

Here at Zabbix, we don’t just meet our SLAs – we exceed them by getting to the root cause of customer issues and providing extensive documentation with the aim of making sure they don’t happen again.

Our support goes far beyond the support of Zabbix as software – we do our best to support the whole monitoring infrastructure, which in some cases can even mean troubleshooting issues that are only tangentially connected to Zabbix as a monitoring system.

That might involve architecture questions, best practices in gathering data from one or another data source, or helping a customer understand and optimize some third-party scripts. No matter what the case may be, we do our best to help.

Listen to what customers need and communicate effectively

As anyone who’s ever contacted technical support knows, the best support isn’t necessarily provided by someone with genius level knowledge who understands every function of a product in minute detail.

For efficient technical support, communication skills are just as vital as technical knowledge. Specialists need to listen first, ask questions to confirm that they understand the problem, and restate what they’ve heard to give the customer the opportunity to provide more information. Above all, they need to speak to the customer’s level of understanding, avoiding jargon and needless details.

Our technical support team sees itself as a bridge between the customer’s needs and the solutions we provide. A key principle of technical support at Zabbix is the notion that the information our customers are sharing with us is precious. The way we see it, our customers give us valuable insights into what’s working in our product and what isn’t.

Listening carefully to the different support queries that we get allows us to form a complete feedback loop between our users and our solutions. For example, if our support team notices issues with collecting specific types of data or monitoring particular endpoints, they can prevent further queries by including a link to our FAQ section while our developers work to fix the issue.

Help customers help themselves

In technical support as in life, self-help is often the best help. It may seem illogical, but the best technical support is usually when the customer is either not asking for help or is able to help themselves.

Allowing customers to perform self-service saves them the time needed to call in or submit an online ticket, and it also improves turnaround time and serves them in the channel they prefer.

Giving customers the tools to be self-sufficient has been a part of our technical support philosophy at Zabbix from day one, and we’re fortunate to have a dedicated and devoted user community to help us do it.

Our users regularly post troubleshooting articles on our blog, and all official product documentation (including an extensive FAQ section) is available on our website. What’s more, our employees make a habit of sharing their knowledge on community Telegram channels, on-site and virtual meetups, and free webinars.

The official Zabbix forum is also a great place to go for support. Customers can interact with each other and get their problems solved easily. No matter what the issue, there’s a good chance that somebody somewhere has experienced it as well and may have a clever workaround or trick to share.

Self-help has limits, however. Your data and infrastructure are the core of your business, and some things are simply best left to experts. That’s why it’s a good idea to add to your knowledge via our official training sessions and have your most urgent issues taken care of by the skilled professionals on our support team. 

Embrace automation where it makes sense to do so

Not all technical support tasks can or should be automated. Most require complex problem-solving, creativity, and emotional intelligence. Others are repetitive, simple, or predictable. It’s important to identify the best use cases for automation based on what the customer expects, the nature and value of the task, and what resources are available.

Our philosophy at Zabbix has always been that there’s no substitute for the human element when it comes to technical support. Our customers trust us to handle complicated, urgent, and sensitive issues, and there’s no substitute for the hands-on assistance that our support team can provide. It’s why we take great pains to make sure that all our team members display soft skills like interpersonal communication, personality traits, and social awareness.

However, we also harness the power of automation to assist with lower-level and more menial tasks, such as ticket assignment and processing counts. Thanks to automation, our specialists don’t need to manually grab tickets from a pool. Instead, everything is automated based on the calendar and who is working on a particular shift.

The ultimate goal is always the same – choosing the best automation path for the particular task at hand so that the customer’s issue gets resolved as quickly as possible with a minimum of disruption.

Conclusion

At Zabbix, we see our role as solving problems, not questions. 95.7% of our resolved support tickets receive positive reviews, and it’s because of the hard work, dedication, knowledge, and soft skills of our support team, as well as their goal of providing sustainable growth, long-term success, and measurable outcomes.

Our support team is a truly global entity that can provide round-the-clock support, and it’s made up of highly skilled Zabbix professionals, experts, and trainers who can boast years or even decades of Zabbix experience. 

We offer multiple support tiers at a variety of price points, so you can be sure that no matter what the support needs of your organization happen to be, we have a plan that will fit perfectly.
Contact us to learn more and find the support tier that’s right for you.

The post Technical Support: The Zabbix Advantage appeared first on Zabbix Blog.

Former Uber CISO Appealing His Conviction

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/10/former-uber-ciso-appealing-his-conviction.html

Joe Sullivan, Uber’s CEO during their 2016 data breach, is appealing his conviction.

Prosecutors charged Sullivan, whom Uber hired as CISO after the 2014 breach, of withholding information about the 2016 incident from the FTC even as its investigators were scrutinizing the company’s data security and privacy practices. The government argued that Sullivan should have informed the FTC of the 2016 incident, but instead went out of his way to conceal it from them.

Prosecutors also accused Sullivan of attempting to conceal the breach itself by paying $100,000 to buy the silence of the two hackers behind the compromise. Sullivan had characterized the payment as a bug bounty similar to ones that other companies routinely make to researchers who report vulnerabilities and other security issues to them. His lawyers pointed out that Sullivan had made the payment with the full knowledge and blessing of Travis Kalanick, Uber’s CEO at the time, and other members of the ride-sharing giant’s legal team.

But prosecutors described the payment and an associated nondisclosure agreement that Sullivan’s team wanted the hackers to sign as an attempt to cover up what was in effect a felony breach of Uber’s network.

[…]

Sullivan’s fate struck a nerve with many peers and others in the industry who perceived CISOs as becoming scapegoats for broader security failures at their companies. Many argued ­ and continue to argue ­ that Sullivan acted with the full knowledge of his supervisors but in the end became the sole culprit for the breach and the associated failures for which he was charged. They believed that if Sullivan could be held culpable for his failure to report the 2016 breach to the FTC ­- and for the alleged hush payment—then so should Kalanick at the very least, and probably others as well.

It’s an argument that Sullivan’s lawyers once again raised in their appeal of the obstruction conviction this week. “Despite the fact that Mr. Sullivan was not responsible at Uber for the FTC’s investigation, including the drafting or signing any of the submissions to the FTC, the government singled him out among over 30 of his co-employees who all had information that Mr. Sullivan is alleged to have hidden from the FTC,” Swaminathan said.

I have some sympathy for that view. Sullivan was almost certainly scapegoated here. But I do want executives personally liable for what their company does. I don’t know enough about the details to have an opinion in this particular case.

Да покажеш, че наистина те е грижа. Разговор с д-р Десислава Иванова

Post Syndicated from Надежда Цекулова original https://www.toest.bg/da-pokazhesh-che-naistina-te-e-grizha/

Да покажеш, че наистина те е грижа. Разговор с д-р Десислава Иванова

Срещаме се с д-р Десислава Иванова в дните между Международния ден на анестезиолога – 16 октомври, и Деня на българския лекар – 19 октомври, пред УМБАЛ „Св. Анна“ в София. В момента д-р Иванова е част от анестезиологичния екип на болницата, известна на столичани като „Окръжна“. Всеки ден тя идва на работа от кв. „Надежда“ на колело. В свободното си време обича да „рестартира“ мозъка си с планинско колоездене и скално катерене. Смята, че хората, които искат да променят здравеопазването, трябва да са компетентни и да работят за общото благо.

Представете се.

Вече съм на почти 42. Работя в поредната държавна болница. Не мога да се откъсна от държавите болници.

Защо сменяте болниците?

Според мен е правилно човек да смени, когато отношенията се изчерпят, независимо дали става дума за лични, или професионални отношения. И в двата случая става въпрос за взаимодействие между хората. Даваш, вземаш, когато тези отношения се изчерпят, трябва да освободиш място за някой друг, а ти да намериш ново място, за да продължиш да се развиваш.

Публичният имидж на здравеопазването създава впечатление, че хората си плащат, за да отидат в частна болница и да получат по-любезно отношение, уважение на правата и желанията им. Любопитно е защо през очите Ви на анестезиолог изглежда обратното…

Не знам, може би в държавните болници са се съхранили медицината и отношението към пациента. Работила съм в „Александровска болница“ 6–7 години, в „Пирогов“ още толкова и една година в частна болница. Мисля, че там видях дъното. Дъното на човека в отношението му към човек. В момента работя в УМБАЛ „Св. Анна“, бившата Окръжна болница.

Това, че някъде пациентът получава любезно отношение, не означава, че получава най-добрата медицина. Аз го видях по този начин, не твърдя, че винаги и навсякъде е така. Всички се стараем да бъдем съпричастни към пациентите. На някои колеги им се удава повече, на други по-малко, но това не изчерпва грижата за пациента.

Съпричастността обаче е важна за пациентите. Според Вас дали лекарите биха я изразявали по-добре, ако получават подкрепа за това?

Подкрепа от кого?

Вие от кого бихте искали да получите подкрепа?

Според мен всичко е въпрос на възпитание в семейството. Ако там сте изразявали емоциите си и сте се научили да ги уважавате, това остава за цял живот.

А според Вас няма ли място за отношенията лекар–пациент в медицинското образование? Българското медицинско образование обръща по-малко внимание на този въпрос в сравнение с други системи. Дали трябва да разчитаме само на семейното възпитание, или общуването е инструмент, който един бъдещ лекар трябва да изучи?

Да, и аз съм чувала от колеги, че в други държави се държи много повече на това. При нас общуването е умение, което се добива по-скоро неформално. Аз имах късмета да случа на прекрасни учители. Те ме научиха, че това не го пише в книгите ни, но то е не по-малко важно за пациента и определящо за работата, която можем да свършим. Покрай тях свикнах как да общувам с пациентите, как да стигам до информацията, която ми е нужна, по начин, който да създаде доверие и спокойствие у пациента. Пациентът трябва да усеща твоята подкрепа, да бъде сигурен, че наистина желаеш той да се подобри. И както вербалната, така и невербалната комуникация са пътят да му покажеш това – че наистина те е грижа.

Вие как решихте да станете лекар?

Съседите ни бяха семейство лекари. Може би от тях съм се запалила, но не съм убедена, продължавам понякога да се чудя защо. Майка ми и баща ми са учители – по математика и по руски. Наглед нищо общо! Но всъщност анестезиологията и реанимацията си е чиста физика – ние работим с флуиди, налягане, с електричество, ако щете. А на мен това е голямата ми страст.

Когато едно дете мечтае да се развие в някаква професия, очакванията му понякога катастрофират в реалността. Какво беше за едно момиче от малък град, дете на учители, да стане български лекар?

Преди да стана български лекар, бях български студент по медицина от бедно семейство. В ония години имаше повече кандидати и всеобщото мнение беше, че за да влезеш в Медицинския университет в София, трябва да изкараш едни курсове, които струват хиляди левове. Родителите ми нямаше откъде да ги вземат. Съответно мен ме приеха на третата година без курсове и помня как на първите упражнения ни разпитваха: „Вие при кого ходихте на курсове?“ Като кажех, че идвам от Математическата гимназия в Казанлък, реагираха с огромно учудване: „Е как така влязохте?!“ Все ми се искаше да им кажа: не знам, пуснахте ме, явно ви е писнало да ми гледате почерка.

После трябваше да работя, за да се издържам. Една сутрин след нощна смяна закъснях за упражнения и асистентът ме посрещна с репликата: „Колежке, вие не знаете ли, че медицината не е за бедни хора.“

Така че първите шест години бяха тежка тренировка.

Но попаднах и на много добри учители, които много ме подкрепяха. Помня как д-р Станчев казваше: „Детенце, някой ден пациентът няма да те пита на коя година си приета и с каква диплома си завършила. Ще иска да му помогнеш.“ И то е така.

Как изглежда развитието Ви сега, през прозореца на Окръжна болница? Успявате ли да сте в крак със съвременната анестезиология и интензивно лечение, да настигате амбицията си?

Да. Тук, ако човек иска да работи, му се дава възможност, като се гледа на първо място интересът на пациента. За да си добър в нашата работа – то във всяка професия е така, – трябва да се чете непрекъснато. Нещо, което много ме вдъхновява, са младите колеги в екипа – има млади колеги, специалисти и специализанти, които много четат. Непрекъснато си говорим, обсъждаме статии, случаи. Това е уау!

Та, да се върна на въпроса как изглежда – четеш, прилагаш това, за което ти дава възможност държавата, и хубавото е, че тук ти се отваря поле да работиш.

Това какво означава? Може ли да обясните, защото на мен ми е малко трудно да си представя при недостиг на анестезиолози какво означава да не им се дава да работят.

Стигало се е до такива ситуации, затова и аз съм си тръгвала… Явно има все пак достатъчно колеги, които приемат някой друг да им казва как да си вършат работата. Когато изискванията към теб нарушават принципите ти, просто си тръгваш, това е. И продължаваш да даваш всичко, на което смяташ, че си способен, на друго място.

Мислите ли, че Ви ограничава това, че сте имено български лекар, а не френски или германски, примерно?

Самият факт, че все още съм български лекар, а не френски или германски, означава, че се чувствам удовлетворена. Към момента е така. Не ме мъчи въпросът щастлива ли съм от това, че живея и работя тук – напълно наясно съм.

Вълнувате ли се от здравеопазването като система, от политиките в здравеопазването, от политиката в здравеопазването?

Не. Нямам сили, за съжаление може би. Мисля, че не ми е в компетенциите да се ангажирам.

А аз понякога си мисля, че ако повече редови лекари се вълнуват от политиките в здравеопазването, тези политики може да станат по-качествени и за лекарите, и за пациентите им. Вие явно не мислите така, чудя се защо се разминаваме. Вие как си го обяснявате?

Да се вълнуваш и да имаш идеи не е достатъчно, трябва да можеш и да ги осъществяваш. Според мен хората, които искат да променят средата, завършват „Здравен мениджмънт“, отиват и се борят за общото благо. Аз мисля за себе си, че мога да допринеса за лечебния процес на пациента в болницата. Не мисля, че притежавам качества да променям точно тази система.

Това значи ли, че в други системи се чувствате по-уверена да променяте и да бъдете активист?

Да. Защитата на животните е това, в което съм по-активна – работя с институции, общини, доброволци. Това, което правя всъщност, е да сигнализирам на институциите – най-често общините – да си изпълнят задълженията по Закона за защита на животните. Има програма, която се нарича „Кастрирай и върни“ и нейната цел е по хуманен начин да се намали популацията на бездомни животни – кучета основно, но и котки. Тя обаче не се изпълнява достатъчно добре навсякъде, немалко общини се освобождават от животните по нехуманен начин. Това е нетрайно решение, но на някои общини явно не им пречи. Фактът, че причиняват страдания на гръбначно животно, явно също не им пречи… В случая моята работа е да подавам сигнали, да питам защо така се случва, какво става с парите, които по бюджет са предвидени за кастриране – и така бавно-бавно колелото се завърта.

Явно правите всичко това, без да сте завършили „Мениджмънт на защитата на животни“, примерно.

Добра аналогия, хванахте ме!

Целта не беше да Ви „хващам“. По-скоро да си представим заедно каква е ролята на хилядите редови лекари в това здравеопазването да стане по-хуманно и да причинява по-малко страдание – както на пациентите, така и на всички медици, които се грижат за тях. Защото не можем да разчитаме само на политиците.

Не мога да кажа за всички лекари. Но за себе си мисля, че може би не съм се сблъсквала с толкова остро усещане за несправедливост в работата си, колкото виждам в отношението към животните. Разбира се, че в здравеопазването също има несправедливости. Но като че ли се опитваме да ги компенсираме. Някак въпреки тях да успеем да си свършим работата. Или може би защото все още не съм усетила даден закон, примерно, да ми пречи да си върша работата, или да имам нужда от някакъв закон, за да си я свърша. В нашата професия, ако си чел достатъчно, ако си разбираш от работата и имаш достатъчно опит – професионален и житейски – може да се справиш със ситуацията, така че да се направи нужното за благополучието на пациента.

Казахте „ако имаш достатъчно опит“. Това значи ли, че смятате медицината за изкуство?

Изкуство? Не, това твърдение никога не съм го разбирала. Тази фраза идва много отдалеч във времето, вече сме отишли напред в развитието си. Изкуство ли е?

Министърът на здравеопазването така смята.

Не знаех. Според мен е много повече логика, математика, физика… Наука, отговорност и рационални решения. Протоколи.

Вие по протоколи ли работите?

Да. Имахме такива и в „Пирогов“, имаме и в „Св. Анна“, в клиниките, в които работя. Те са разписани на база международни протоколи и консенсуси, не е нещо, което сме измислили. Просто се адаптира за съответното отделение. В някои държави има национални, но при нас са на ниво болница.

Говорим много за анестезиологията. Някои Ваши колеги казват, че това е най-тежката специалност. На Вас тежка ли ви се струва?

Знаете ли, днес давах една анестезия в Очна клиника. И се замислих как още от университета съществува тоя предразсъдък, че очните болести и дерматологията са елементарни специалности. Но не е така. Ако човек загуби зрението си вследствие на твое неправилно решение, е сериозна отговорност – кое е елементарното? Или например в дерматологията има много заболявания, които са хронични – в момента няма лечение за тях, най-много временно облекчение. Това може да доведе след време до поведенчески и психични промени. И пациентът се надява на теб, а ти трябва да му обясниш, че такова е положението, такова е нивото на науката в момента – това да не би да е лесно? Във всяка специалност има специфики и трудности.

Може би убеждението за леките и тежките специалности идва оттам, че един анестезиолог трудно може да реши, че вече не му се работи в болница, и да стане амбулаторен лекар.

Всичко е въпрос на мотивация! Познавам лекари, които са били анестезиолози и после са станали фармацевтични представители.

Но е много важно да можеш да слагаш граници между професията и личния живот. За да си адекватен лекар, мозъкът ти трябва да е отпочинал. Това важи за всяка професия.

Вие успявате ли да имате личен живот?

Успявам донякъде. Родителството се оказа доста трудна работа. Може би когато синът ми стане на около 30 години, може да го питам как съм се справила, успяла ли съм, или не.

Изглежда като да сменяте една трудна работа с друга трудна работа. Нали казахте, че мозъкът трябва да е отпочинал, как става това?

С хобита. Много ми е любимо скалното катерене, защото само мислиш как да продължиш, без да паднеш. На мен най-големият ми страх не е да не умра, а да не се инвалидизирам. И когато се катеря, умът ми е съсредоточен в това и в нищо друго. Така на другия ден нямам търпение да отида на работа.

Нямате търпение?

Да. Много е хубаво човек да си обича професията! И затова според мен е голям проблем, че хората избират професия по задължение или поне по някакви външни причини, а не защото им е страст. За мен лично лекарската професия е най-важна, защото съм я избрала. Но всъщност всички професии са важни посвоему. Най-важно е да се чувстваш добре с това, което правиш, и да ти е чиста съвестта в края на деня.

В рубриката „Разговори за здравеопазването" Надежда Цекулова кани своите събеседници да поговорят без клишета и празнодумие за проблемите и решенията, болката и оздравяването, медицината и политиката.

На второ четене: „Идва събота“

Post Syndicated from Стефан Иванов original https://www.toest.bg/na-vtoro-chetene-idva-sabota/

„Идва събота“ от Лусия Бърлин

На второ четене: „Идва събота“

Превод от английски Василена Мирчева, изд. „Кръг“, 2021

Симон Вейл пише писмо на Жое Буске на 13 април 1942 г., година преди смъртта си, в което му казва, че „вниманието е най-рядката и чиста форма на щедрост“. Вниманието като разбиране на себе си и на другия. Жое Буске е поет, тежко ранен в края на Първата световна война, парализиран е и прекарва голяма част от остатъка от живота си на легло и в постоянна болка, за която взима опиум.

Разказите на Лусия Бърлин са едни от най-добрите, които някога съм чел.

Заслуга за това до голяма степен има и образцовият превод на Василена Мирчева. Сравненията с Чехов, Реймънд Карвър, Кларис Лиспектор или Буковски са колкото уместни, толкова и не са. В писането ѝ има искрен и щедър поглед и още по-щедро разбиране на парализирани от страх, любов или болест хора, а не просто персонажи или герои, които са чисто нейни. Не са плод на интелектуално или литературно влияние, а идват от живота и опита ѝ. Тя ги преувеличава и трансформира. Превръща ги в проза, която е като среща и откровен разговор с приятел, когото познаваш в цялост. Познаваш го в истината и сложността му.

Като си мисля за тези разкази, най-лесно ми е да опиша прочита ми с цитат от един от тях:

… когато после мислеше за това, не беше по начина, по който си спомняш човек или сексуален акт, а като природно явление, лек земетръс, повей на вятъра в летен ден.

Бърлин е като отделен сезон в читателската ми година. Израснала е в Чили и е живяла в Мексико, Ню Йорк и на дузина места в Америка. Има множество любовници и съпрузи, майка е на четири деца. Красива е като Елизабет Тейлър, но е била с тежка форма на сколиоза и ѝ е отнело дълго време да се пребори с алкохолизма. Разказите ѝ са за семейството ѝ, за превод на стихотворение, за престои в изтрезвително, арест и реанимация, за индианците, които среща в обществените перални, за миньори, гмуркачи, музиканти и жокеи, за дядо ѝ – зъболекар и насилник, за работата ѝ – като секретарка в болница, учителка и чистачка, за затворници, които посещават курса ѝ по творческо писане.

Разказите ѝ са за полудялото време на влюбването, секса и скръбта, покоя на помирението и стоицизма на остаряването.

Писането на Бърлин е белязано от сурова откровеност, хумор, безпощадна и топла прецизност, изчерпателен реализъм и детайли, чието събиране и концентрация карат няколко фрази, един параграф или разказ да се усещат като поема, новела или роман. Няма празни приказки в писането ѝ.

На второ четене: „Идва събота“

Трудно ми е да избера какво да цитирам. Отбелязах си дузини параграфи. Но се връщах към един и същ. Нейно е едно от най-интензивните описания на еуфорията и екстаза от първия стадий на влюбване:

Хранеха животните по едно и също време всеки ден, но останалото от дните и нощите се обърка. Оставаха в леглото целия ден, закусваха, когато се стъмваше, разхождаха се из горите на лунна светлина. Гледаха „Мистър Лъки“ с Кари Грант в три посред нощ. Лениви от жаркото слънце, гребяха с дървена лодка в езерото, ловяха риба, четяха Джон Дън, Уилям Блейк. Лежаха на влажната трева, гледайки пиленцата, говореха си за детството си, за децата си. Гледаха как Нолан Райън отбелязва точки, спяха часове наред в спални чували край езерото. Любеха се във ваната на лъвски крака, в лодката, в гората, но най-вече сред искрящата зеленина на верандата, докато валеше. Какво е любовта? Мария се питаше, гледайки чистите линии на лицето му, докато той спеше.

Това описание вече е редом в паметта ми до едно на Анита Брукнър от „Хотелът край езерото“.

Не мога да разбера как толкова добра писателка не е получила приживе безспорното признание, което е заслужавала? В момента на Бърлин не ѝ липсват читатели, награди и включвания във всевъзможни списъци за най-добри книги. Това е следствие от настоящия сборник, съставен от Стивън Емерсън, Бари Гифърд и Майкъл Улф, нейни приятели и ценители. Той е първият, публикуван от голямо американско издателство. Може би и безкомпромисната ѝ независимост, страненето от литературни и академични кръгове също са сред причините за пренебрегването ѝ, за не особената ѝ видимост. 

А Лусия Бърлин винаги е била толкова добра писателка. Може би чувствителността и културата на публиката се променят. Може би е и въпрос на вкусове, тенденции или мода. На подходящ момент. Няма да спра да се удивявам как има хора, които са по-талантливи, по-интересни и по-умни от преподаватели и писатели, а не преподават и не пишат. Да, нужно е и его, амбиция и последователност, но понякога на притежаващите тези качества им липсват други.

За успелите се случва да има един свят и той е приветлив, боядисан, ремонтиран и уреден. Но под него има и друг. И за него пише Бърлин. Прозаичният ѝ свят е за това, което е прикрито. За раните, болката и травмата. Може да ги направиш приемливи. Върху тях може да сложиш грим, дрехи, аксесоари, автомобил, но това отдолу остава и даже и да се заглушава, то постоянно избива на повърхността. Прекомерната близост с реалността предизвиква изтласкване и недоверие. Човешката и артистична смелост може да предизвика завист, несправедливост или унижение.

В България има преизобилие от болка и за нея се говори недостатъчно. Маркира се, очертава се, загатва се, но за нея главно се мълчи.

Колкото е по-болен пациентът, толкова по-малко шум вдига,

пише американската писателка. За болката често се казва, че е битова, че е излишно драматизиране да се говори за нея, че не е достоен обект на изкуството. Защо пък да се пише за това; да не създаваме излишни грижи на читателя; той си има достатъчно. Да го утешим с плацебо. И без това няма какво да се направи, проблемите са нерешими, няма смисъл да пишем за тях.

Четейки разказите на Бърлин, бих искал да чета разкази за българските касиерки, за медицинските сестри, за лекарките, сервитьорките и готвачките, за учителките, за чистачките, за жените в офисите, но и за т.нар. лелички в държавната администрация. За жените, които са гръбнакът и на тази държава.

Бих искал да чета за тях, но не калкулирани, полирани или сантиментални измишльотини, а истината. Тяхната истина. Те, както и героините на Бърлин, както и самата тя, не са жертви на средата или обстоятелствата. Тяхната истина не е за шокиране или умиление, а е свидетелство за една забележителна страна на живота и на достойнството в него. Просто, колкото и да не е за вярване, все още има и истина, и реалност. И в нея има красота, за която често сме склонни да си затваряме очите. Има и смелост.

Тя е нужна във времена на реклама и борба за внимание и харесване в социалните мрежи. Във времена на лесни суперлативи и копнеж по вписване, по приемливост и загладеност без остри ръбове или риск.

Във времена на обидчивост и лицемерие това са жестоки разкази. Необходими са.

Както за Бърлин е нямало начин да не ги напише, така и читателите имат нужда да ги прочетат. Възможни са и днес, стига писателят, който ги пише, да знае, че може и да не излезе начело в класациите с тях. Може да си позволи написването им автор, който не иска да е на първо място. Който е поне малко лишен от пресметливост, който не слага филтри на снимките и на писането си, не е зает непрекъснато с проекти, грантове, резиденции, телевизионни или радиоучастия. Има ли място такова писане днес? Желано ли е? Пазарът и медиите предпоставят ли го? Не съм съвсем сигурен.

Отговорът е сложен. Писане като това на Бърлин поставя под въпрос контекст и установени клишета. С лекота може да бъде пренебрегнато, зачеркнато и отречено като грубо, грозно или безсрамно. И в Америка, а не само в България има еснафски, угоднически, консервативни и конформистки ценности. Творчеството на всеки писател, без значение колко е добър, може да бъде заметено под килима, а писателят – овъртолен в килима, нарамен и изхвърлен.

Но от всеки писател зависи дали ще бъде свидетел, или лъжесвидетел на времето си. Въпрос на внимание и избор е.

Дали ще иска да е успешен, готин и куул, или ще избере свой собствен път, който неизбежно е и трънлив. По този път успех и провал може да са синоними. Може рождената дата да е и ден на смърт, каквато е 12 ноември за Лусия Бърлин.

Активните дарители на „Тоест“ получават постоянна отстъпка в размер на 20% от коричната цена на всички заглавия от каталога на издателство „Кръг“, както и на няколко други български издателства в рамките на партньорската програма Читателски клуб „Тоест“. За повече информация прочетете на toest.bg/club.

Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. Рубриката е част от партньорската програма Читателски клуб „Тоест“. Изборът на заглавия обаче е единствено на авторите – Стефан Иванов и Севда Семер, които биха ви препоръчали тези книги и ако имаше как веднъж на две седмици да се разходите с тях в книжарницата.

Намерени в превода

Post Syndicated from original https://www.toest.bg/namereni-v-prevoda/

Намерени в превода

Последния път завършихме със свети Йероним, сега ще започнем с него. Познат и като Йероним Блажени, светецът е най-известен с превода си на Библията от гръцки и еврейски на латински език, наречен Вулгата (Vulgata), с придружаващите го преводачески коментари, както и с множеството си други писания по преводачески теми. Заради тези свои дейности свети Йероним се смята за патрон и покровител на преводачите, а на 30 септември (деня на смъртта му през 420 г.) се чества Международният ден на превода.

И въпреки че септември вече е зад нас,

за превода – и преводачите! – си заслужава да се говори по-често, а не само по официални поводи.

В този текст, поне първоначално, ще подходим към превода съвсем буквално в опит да проследим етимологията на думата в различни езици. А сякаш като олицетворение на дейността, която обозначава, самото проследяване се оказва доста сложно и главозамайващо оплетено.

Освен чисто езиково, вглеждането в разнопосочните етимологии на думата „превод“ е любопитно и защото разкрива широкия спектър от разбирания за това в какво всъщност се състои дейността на преводачите. С други думи,

самите понятия, които обозначават превода, може да се разглеждат като метафори – преводът като пре-веждане, пре-местване, пре-насяне, пре-обръщане, а дори и като бродиране и чеверме.

По някаква причина иначе доста обширният Български етимологичен речник на БАН не включва думата „превод“, а другите речници, с които се консултирах, не съдържат етимологичните ѝ тълкувания. Затова не ни остава друго, освен да предположим, че българската дума споделя сходна етимология с руския си еквивалент. Той („перевод“) е образуван от глагола „переводѝть“, чийто корен произлиза от праславянската *voditi, а тя на свой ред – от праиндоевропейската *wodʰéyeti, с корен *wedʰ- (‘водя’)¹.

Макар и с различен корен, идеята за превода като „водене през“ съществува и в еквивалентните думи на романските езици – френската traduction, испанската traducción, италианската traduzione произлизат от латинската transducere: от trans (‘през’) + ducere (‘водя’).

Отделна теория, която освен леко съмнителна е и доста изкушаваща – особено за преводачи, които смятат заниманията си за ювелирно изкуство, – обяснява етимологията на думата „превод“ в сърбохърватския като свързана с „превести“, чийто праславянски корен *vęzti означава „везам, бродирам, шия“.

На други славянски езици, например украински и чешки, думата за „превод“ – съответно „переклад“ и překlad – е съставена от корен, произлизащ от праславянската дума *ložiti, която пък идва от праиндоевропейската *logʰ-éye-ti, тоест „слагам, полагам, поставям“.

Идеята за формирането на немската Übersetzung и скандинавските översättning, oversættelse, oversettelse (съответно на шведки, датски и норвежки) е подобна, макар че всички те произлизат от прагерманския корен *satjaną, който също означава „поставям“.

На унгарски преводът е известен като fordítás, което се смята, че произлиза от прауралския корен *pürke- (*pᴕrγɜ-), тоест „въртя, обръщам”. Идеята за въртене се открива и в турския, където – както научих от едно интервю с преводача Азиз Шакир-Таш – думата за „превод“ (çeviri) споделя общ корен с „чеверме“.

В различните начини на формиране на думата на различните езици, разбира се, няма нищо необичайно. Тези различия обаче създават сериозни предизвикателства за същинския процес на превод, особено когато е важно смисловият заряд на корена от оригинала да се съхрани.

Преди време например, докато работех по текст на преводачката Василена Мирчева, посветен на баща ѝ Красимир Мирчев и озаглавен „Баща ми преводачът“, ми се наложи да преведа следните две изречения: „Баща ми е преводач, така пише на визитката му. Баща ми е от хората, които ще те преведат през пяната на дните, без да те лъжат, че ще излезеш оттам окъпан, но ще те научи да се гмуркаш за съкровища по дъното.“

В моя превод на английски, за съжаление, връзката между „преводач“ и „ще те преведат“ – които аз съм превела като translator и will carry you through – става почти изцяло незабележима. Загубата е налице, въпреки че английският превод също отразява етимологията на думата, формирана чрез представката trans (‘през’) и корен, произлизащ от латинското latus (минало причастие на ferre, тоест „нося, понасям”).

Заниманието с художествен превод постоянно води до такъв тип загуби, поради което преводачите често биват обвинявани в предателство.

Понякога обаче боговете на превода (или може би самият свети Йероним) са благосклонни и се случва така, че определен израз или фраза съвсем гладко и без усилия преминават от един език в друг – дори и когато тези езици не са близки.

Крилатата фраза „traduttore, traditore“ е идеален пример за това: първоначално появила се като определение от гневни италианци за (според тях нескопосаните) френски преводачи на Данте, тя – благодарение на споделения префикс между двете думи – в голяма степен запазва благозвучието си и на други, дори и далечни на италианския езици.

Английската „translator, traitor“ например е почти толкова алитеративна колкото италианската, а даже и българската „преводач, предател“ притежава известна доза мелодичност. На унгарски, в опит да се запази алитерацията, фразата понякога се предава по-свободно като „fordítás: ferdítés“, тоест „превод: изкривяване“.

Нещата стават още по-оплетени, когато вземем предвид и различните видове превод, които на български обикновено се обозначават доста прозаично като „писмен“ и „устен“, но в много други езици за тези дейности – както и за преводачите, които ги извършват – съществуват съвсем отделни думи.

Два примера ни разкриват любопитни етимологии: на немски писменият преводач се нарича Übersetzer, а устният – Dolmetscher, докато на шведски тези думи са съответно översättare и tolk. Както вече споменах, и в двата случая думите за писмен превод имат общ корен, означаващ „поставям“. Думите за устния обаче се различават. За немската Dolmetscher се смята, че е заимствана от праславянската *tъlmačь (оцеляла и на български като остарялата „тълмач“), която на свой ред произлиза от пратюркската *til, означаващ „език“ и в двата смисъла на думата. (Полската дума за преводач – tłumacz, споделя същия произход.)

Скандинавската дума за устен преводач – tolk, също – доста изненадващо! – има праславянски произход: думата *tъlkъ (това е коренът и на съвременния глагол „тълкувам“), а тя от своя страна произлиза от праиндоевропейската *telkʷ- и е сродна със санскритската तर्क (tarka, ‘предположение’), латинскaта loquor (‘говоря’) и староирландскиите do·tluchethar (‘питам’) и ad·tluchedar (‘благодаря’).

На английски и френски, докато писменият преводач се нарича translator/traducteur, устният е познат като interpreter/interprète. Втората двойка думи произлиза от латинската interpres ‘агент, брокер, обяснител, посредник’, която от своя страна е формирана от inter (‘между’) и pres, смята се, за корен на pretium (‘цена’) и се предполага, че е свързана със старогръцката φράζειν (phrázein ‘посочвам, показвам, обяснявам, декларирам, говоря’), от която произлизат и φραδή (phradḗ ‘разбиране, знание’) и φράσις (phrásis ‘фраза, израз, говор’).

Думата φράσις (phrásis) служи и като корен на гръцката дума за „(писмен) превод“: μετάφραση (metáfrasi). Както е известно, този термин е навлязъл и в други езици с леко изменено значение².

Сега се замислям, че ако гръцката дума за „превод“ беше формирана по модела на английската – на базата на корена „нося, понасям“ – тя щеше да звучи като μεταφορά (metaforá).

Освен като познатото ни стилистично средство в реториката, μεταφορά на гръцки също така означава чисто и просто „транспорт“. A етимологично погледнато, думата „транспорт“ – от латински, trans (‘през’) + portare (‘нося’) – се оказва нещо като калка, тоест буквален превод на „превод“.

Ето как в края на краищата се оказва, че преводът неизбежно е и пренос(ен). И въпреки първоначалните ми намерения да пиша по темата съвсем буквално, все пак достигнахме метафоричното – и то буквално.

Като голям застъпник на духа пред буквата свети Йероним със сигурност би одобрил.

1 Смята се, че праиндоевропейската *wedʰ-, освен на думата „водя“ и нейните сродни думи на другите славянски езици, е първоизточникът и на английските wed (‘венчавам’) и wage (‘водя, провеждам’, обикновено в комбинация с „война“).

2 Терминът „метафраза“ е навлязъл и в други езици, в които се използва като обозначение на буквален превод, тоест пренасяне на текста дума по дума и ред по ред, а също така и на превода на поезия в проза. Tова, с други думи, е вид превод, който свети Йероним не би одобрил. С право той се запитва: „Каква е ползата да се гони буквата, да се спори за грешките на пишещия или за хронологията, когато много ясно е казано, че буквата убива, а духът животвори.“

В рубриката „От дума на дума“ Екатерина Петрова търси актуални, интересни или новопоявили се думи от нашето ежедневие и проследява често изненадващия им произход, развитието на значенията им във времето и взаимовръзките им с близки и далечни езици.

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити

Post Syndicated from Атанас Шиников original https://www.toest.bg/mashallah-i-banksi-ne-se-e-poiavil-v-arabskiya-svyat/

Наско, имам нужда от твоята помощ,

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити

получавам преди време съобщение в служебната си поща. Поглеждам кой ми пише, и изтръпвам. Регионалният мениджър по сигурността за Източна Европа и Близкия изток. Никой не обича да си има вземане-даване със сигурността, дори и в ИТ сектора. Имат си репутация, подобна на отдел „Човешки ресурси“. Не е добре да те търсят просто ей така. 

Моля те, виж приложените снимки и ми кажи какво пише на тях. На арабски е и е от служебния паркинг. Ако може днес, че пътувам в командировка и ми е важно да знам. 

Аха, добре. Отварям снимката в приложението. Определено е на арабски. Графит с много несръчен, тромав и грозен почерк, ъгловати, удебелени букви, издраскан с нещо твърдо върху бетонната стена на паркинга. Много лоша снимка, с ниска осветеност. Увеличавам я и веднага прочитам. Не пише „Хамас“, особено актуално с оглед на последните събития около Израел, или „Освободете Палестина“, нито пише „Джихад“. Не е „Аллах“, нито пък нещо романтично, например „Али обича Фатима“. 

[Една определена анатомична част] на майка ти. 

Това пише. Толкоз. Ако трябва да перифразирам любим разказ за мухата в писоара, тук няма да видите снимките и да разберете какво точно казва надписът, защото на гнусливите читатели ще им прилошее. Напълно професионално отговарям на колегата. Натраквам „Привет“, следва буквален превод на надписа.

Пише това и това. Бъди здрав и пътувай спокойно! 

Но историята зад надписа ще остане загадка. Дали е бил някой като мен? Може да е носител на езика от ИТ тълпата, примерно агент от колцентъра, обслужващ Близкия изток. За кого е адресиран графитът? За чия майка става въпрос? Може пък да е просто спонтанен израз на порив към вандалство. Като българските надписи по Колизея. 

С графитите винаги е така – имат нужда от много контекст. И той обикновено липсва.

Ревниво крият историята си отвъд непосредственото впечатление. Нещо като фотографията, която паметува твърде малко отвъд непосредственото улавяне на образа. 

Та какво ви говори например този графит от Женския пазар в София? 

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити
„Жена. Живот. Свобода.“ Надпис на арабски в района на Женския пазар © Личен архив

От кофите за боклук около Централните хали и синагогата е. Сигурно забелязвате червенобразни знаци с маркер, които говорят за екзотичността на района. Аз пък чета уверен, акуратен, окръглен, жив почерк с широк филцов маркер, около 10 мм. Пише три думи. 

Зан. Зендеги. Азади. Жена. Живот. Свобода. 

Лозунг от иранските протести през 2022 г. в знак за солидарност с жените там. Един от моментите, когато се усещаш въвлечен в много по-голяма картина от пазаруването на сок от нар, агнешко или дюнер от тази част на града.

Но отвъд това какво? Почти нищо. Като че ли идеята какво точно са графитите и какво ти казват, се изплъзва. Навсякъде са, предизвикват непосредствена реакция („Много грозно!“, „Вандализъм!“, „Виж колко интересно!“, „Леле, виж колко красиво!“, „Адски готин, суперсмарт“), но какво точно представляват? Малко като нещата, за които всички говорят, все едно се подразбират, но не успяват да определят същността им. Според общата ми култура „графити“ идвало от гръцкия корен на всичко, свързано с „писане“. Графити. Графеми. Графит. Графика. Калиграфия. Графология. Графомания. Сграфито. Нещо написано. 

Та не е ли същото и с арабския корен на всичко около писането – к-т-б?

Оттам идва и познатото ни арабско китаб, преминало в турския като китап. Книга, писание, документ, написано. И то като графитите е колкото устойчиво, толкова и изплъзващо се.

Конрад Хиршлер, един от любимите ми изследователи на арабската ръкописна традиция, сравнява понятието за книга при арабите с метафора, използвана от самия Мартин Лутер. Бащата на протестантската Реформация, твърди той, сравнявал Еразъм със „змиорка, която само Бог може да улови“. Е, такова, твърди Хиршлер, било и разбирането за книга при арабите. Дали е текстът, който върви под определено заглавие, или подвързаният между две корици кодекс от страници, остава напълно неясно.

Като гледаме графитите, оставаме със сходно впечатление за флуидност и преходност. Графити културата се движи от сенчестите пространства, в които се пръква, към помилваните от властта пространства на художествена себеизява. Присъщата маргиналност на графитите първоначално изглежда аксиоматична. Важи както за драсканиците на бандите в Ню Йорк през 70-те години на миналия век, така и за парижките графити, снимани от Брасай, този близък приятел на Пикасо. Издраскани лица, сърца, надписи, кръстове по улиците на Париж, променящи се с времето изображения – всичко това няма как да намери място в Лувъра, нито пък да бъде финансирано от някоя община. Не принадлежи към този пласт от художествената реалност. 

Но графитите лека-полека изпълзяват на светло. Катерят стълбицата от ниския, маргинален пласт на градското пространство до по-високите му етажи. Този преход бива капитализиран от градските управи, които усвояват досега пренебрегвани пространства и правят живота там малко по-поносим визуално. Но в момента, в който биват насила придърпани под прожекторите, губят част от характера си. „Благословията“ на публичната санкция лесно може да се превърне в „проклятие“. 

В природата на графитите е заложено тяхното спотайване в кьошетата на града. 

Приличат на маргиналните илюстрации в средновековните ръкописи на Запад или спираловидно завихрените бележки в арабските ръкописи, по Бринкли Месик и неговата „Калиграфска държава“. В момента, в който занаятът се официализира, той загубва същностен аспект. Престава да бъде част от културата на протеста, която го осмисля. Защото обезсилва оттласкването му от статуквото, чрез което той се определя. Уличната рисунка, обект на туризъм, може да привлича посетители, но именно заради комфорта, който предлага, тя престава да бъде „графит“.

Отделно съществуват и противоречията във връзката между художествено и политическо. „Смятам, че графитите се политизират твърде много, за мен е важно изкуството“, споделя с мен един от известните софийски артисти по време на уъркшоп в ателието си в София сред тълпа дечурлига. Но много негови колеги не мислят така. Всъщност мислят точно обратното. И политическите размирици около Арабската пролет, и протестите в Иран го показват. Както и случаят на местна почва с един Симон Варсано през 1989 г.

В рамките на тези спорни отношения гуруто на модерните графитъри, популярният (направо популистки) Банкси, някак арогантно е наседнал прехода между маргиналното и показно комерсиалното, между чисто художественото и политическото. Ако гледате Exit Through the Gift Shop, много лесно може да съзрете проблематичността в творци, за които протестът е част от внимателно граден и поддържан имидж. Банкси е колкото шампион на добре режисирани политически изяви, толкова и на комерсиални начинания като „Зазидания хотел“ в Газа, срещу стената, която отделя Израел от гетото. 

Възникват също въпроси около формата и жанра. Добре, наред с разнообразните тагове, бомбене, throw-ups, които се въртят около буквите, имаме и свързаните с тях, но отделни форми на улично изкуство. Лепене на плакати, стикери с изображения, шаблони. Големи пана със спрейове. Накрая идват и най-монументалните, обикновено създавани по поръчка градски стенописи върху фабрики, фасади на сгради. „Графити“ може да е всичко, стига да е върху стена.

Наложете върху тези противоречивости около графитите и контекста на непривично за нас общество, например Турция, Израел, Египет, Мароко. Добавете върху него и близкоизточен език, който не говорим. Резултатът е възел, пред чието теоретично разплитане човек лесно избира по-непосредствени удоволствия. Затова и вместо мъчителното бъхтене по потискащи интелектуални питания около дефинициите,

тук предлагам два напълно различни, но допълващи се погледа към арабските улични надписи. 

Първото е сблъсък със стар арабски текст. С изненада ще откриете, че в Близкия изток темата за графитите се проблематизира отпреди Банкси. Писането по стените вълнува литературното въображение на древните араби. Поне така личи по съчинения като „Книга за странниците“ от IX в. Приписвали я на големия Ал-Исфахани, повече известен чрез поетичния сборник „Книга на песните“. Пък дали е негова, знае само онзи, който можел да улови плъзгавия Еразъм. Обаче ето, казва авторът на книгата, събрал съм неща, чути или видени, поезия от хора, които пътуват, пришълци, които изповядват мъката по родните места или по възлюбените, като пишат за страданията си по стените на местата, през които минават. Звучи едновременно загадъчно и вандалско, екзотично някак, хем напудрено, хем извън общоприетата норма, почти като приказка от „Хиляда и една нощ“. 

И какво представляват драсканиците по стените от арабския IX век?

Представете си ги на вид почти като драсканиците на арабица по колоните на църквата „Св. Четиридесет мъченици“ във Велико Търново (да, такива има), но поетични. Защото човекът от онова време не се задоволява с простото изписване на пословичното трибуквие или вечното „Аз бях тук“. Няма надписи срещу властта. Не следват стилистиката и съдържанието на тоалетния надпис от „Дома на киното“ в София, където анонимен активист е оставил следа, подканваща към социален дебат.

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити
© Личен архив

Като че ли вечната тема на този архив от надписи по манастири, кръчми, джамии, пазари е самотата и загубеното щастие. Пътуването по време на Абасидския халифат може да е нещо обичайно – хората пътуват „в търсене на религиозното знание“ (талаб ал-‘илм), по търговски дела, в дирене на препитание, на религиозни поклонения из светите места – Мека, Медина, Йерусалим. Но усещането за отчуждение не изчезва.

Времето, за което арабският език използва различни думи – най-разпространеното заман, но също и „дните“ (ал-аййам), „нощите“ (ал-лайали), „съдбата“ (дахр, ал-кадар), – неумолимо изтича и завлича със себе си и пътешественика. То е и главният виновник за носталгията човешка. Eто, разказвал Ал-Асмаи, известен филолог и поет, минах покрай една скала, докато пътешествах, и на нея беше надраскано следното:

Всяка страна е страна на човека, но той не е на никоя ближен,

та възкликнал: авторът на тоя стих със сигурност ще си умре пришълец! 

Около надписите се разгръщат цели истории, понякога на ръба на общоприетия морал, че направо и отвъд него. В манастирите девойки оставят надписи по стените, прелюдия към съблазняване на мюсюлманските пътешественици. Араби драскат меланхолични стихове по портите на християнски олтари. Благочестиви поклонници пишат имената си и набожни стихове не къде да е, а по минаретата. Халифът Ал-Мутауаккил пиянства с черковно вино в компанията на красавица. А пък самият Ал-Исфахани изповядва хомосексуална афера, в която поетични графити, надраскани по врати и стени, играят ролята на сантиментално обяснение в любов. 

Не мога да пропусна и историята за някой си Абу ал-Хинди, който влязъл при винопродавец в място, наречено Куи Заян, което пък значело „Улица на покварата“. Уж бил в компания, разказва старият арабски текст, ама подранил и от сабахлем наченал да винопийства. Както казваше баща ми, „направил главата“ без време и заспал. Приятелите му разбрали какво е сторил, и решили да го последват. Пили, пили, докато и те не заспали. Абу ал-Хинди се събудил, видял ги и на свой ред попитал какво става. Разбрал и си рекъл: дай и аз да направя същото. И така минали десет дни. Дошло време Абу ал-Хинди да си тръгне и поканил приятелите си най-после да пият заедно. „Желаем го повече и от теб!“, та пили заедно един последен ден. Накрая, като си тръгнал, надраскал върху стената на мястото, където били отседнали, поема в чест на паметното преживяване. 

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити
Илюстрация от „Макамите“ на Ал-Харири (поч. 1122)

Без съмнение, от подобни разкази лъха на известен литературен произвол. Скептикът в мен, който винаги изхожда от позицията „Да бе, верно ли!“, може да си каже: „Добре де, отгде да знам, че Ал-Исфахани не си го е измислил?“. Та не е ли вярно, че арабските историци постоянно си измислят истории? Измислят си всичко, дори и доказателства за казаното от Пророка Мохамед. И все пак винаги стои възможността поне част от историите в „Странниците“ да бъдат основани на реални събития, разкази, наблюдения. Периодът е запазил подобни надписи и откъм техника, и откъм жанр, ако вярваме на изследователската литература. Както обичат да обобщават мюфтиите след всяко отсъждане, „Аллах знае най-добре“. Но със сигурност можем да твърдим, че преходната природа на написаното по стените влиза в полезрението на арабите поне от десетото столетие насам. 

(Следва продължение.)

В рубриката „Ориент кафе“ Атанас Шиников поднася любопитни теми, свързани не толкова с горещата политика, колкото с историята и културата на Близкия изток. А той, древен и днешен, е по-близко до нас и съвремието ни, отколкото си представяме.

What does AI mean for computing education?

Post Syndicated from Philip Colligan original https://www.raspberrypi.org/blog/what-does-ai-mean-for-computing-education/

It’s been less than a year since ChatGPT catapulted generative artificial intelligence (AI) into mainstream public consciousness, reigniting the debate about the role that these powerful new technologies will play in all of our futures.

A person in front of a cloudy sky, seen through a refractive glass grid. Parts of the image are overlaid with a diagram of a neural network.
Image: Alan Warburton / © BBC / Better Images of AI / Quantified Human / CC-BY 4.0

‘Will AI save or destroy humanity?’ might seem like an extreme title for a podcast, particularly if you’ve played with these products and enjoyed some of their obvious limitations. The reality is that we are still at the foothills of what AI technology can achieve (think World Wide Web in the 1990s), and lots of credible people are predicting an astonishing pace of progress over the next few years, promising the radical transformation of almost every aspect of our lives. Comparisons with the Industrial Revolution abound.

At the same time, there are those saying it’s all moving too fast; that regulation isn’t keeping pace with innovation. One of the UK’s leading AI entrepreneurs, Mustafa Suleyman, said recently: “If you don’t start from a position of fear, you probably aren’t paying attention.”

In a computing classroom, a girl looks at a computer screen.
What is AI literacy for young people?

What does all this mean for education, and particularly for computing education? Is there any point trying to teach children about AI when it is all changing so fast? Does anyone need to learn to code anymore? Will teachers be replaced by chatbots? Is assessment as we know it broken?

If we’re going to seriously engage with these questions, we need to understand that we’re talking about three different things:

  1. AI literacy: What it is and how we teach it
  2. Rethinking computer science (and possibly some other subjects)
  3. Enhancing teaching and learning through AI-powered technologies

AI literacy: What it is and how we teach it

For young people to thrive in a world that is being transformed by AI systems, they need to understand these technologies and the role they could play in their lives.

In a computing classroom, a smiling girl raises her hand.
Our SEAME model articulates the concepts, knowledge, and skills that are essential ingredients of any AI literacy curriculum.

The first problem is defining what AI literacy actually means. What are the concepts, knowledge, and skills that it would be useful for a young person to learn?

The reality is that — with a few notable exceptions — the vast majority of AI literacy resources available today are probably doing more harm than good.

In the past couple of years there has been a huge explosion in resources that claim to help young people develop AI literacy. Our research team mapped and categorised over 500 resources, and undertaken a systematic literature review to understand what research has been done on K–12 AI classroom interventions (spoiler: not much). 

The reality is that — with a few notable exceptions — the vast majority of AI literacy resources available today are probably doing more harm than good. For example, in an attempt to be accessible and fun, many materials anthropomorphise AI systems, using human terms to describe them and their functions and thereby perpetuating misconceptions about what AI systems are and how they work.

A real banana and an image of a banana shown on the screen of a laptop are both labelled "Banana".
Image: Max Gruber / Better Images of AI / Ceci n’est pas une banane / CC-BY 4.0

What emerged from this work at the Raspberry Pi Foundation is the SEAME model, which articulates the concepts, knowledge, and skills that are essential ingredients of any AI literacy curriculum. It separates out the social and ethical, application, model, and engine levels of AI systems — all of which are important — and gets specific about age-appropriate learning outcomes for each. 

This research has formed the basis of Experience AI (experience-ai.org), a suite of resources, lessons plans, videos, and interactive learning experiences created by the Raspberry Pi Foundation in partnership with Google DeepMind, which is already being used in thousands of classrooms.

If we’re serious about AI literacy for young people, we have to get serious about AI literacy for teachers.

Defining AI literacy and developing resources is part of the challenge, but that doesn’t solve the problem of how we get them into the hands and minds of every young person. This will require policy change. We need governments and education system leaders to grasp that a foundational understanding of AI technologies is essential for creating economic opportunity, ensuring that young people have the mindsets to engage positively with technological change, and avoiding a widening of the digital divide. We’ve messed this up before with digital skills. Let’s not do it again.

Two smiling adults learn about computing at desktop computers.
Teacher professional development is key to AI literacy for young people.

More than anything, we need to invest in teachers and their professional development. While there are some fantastic computing teachers with computer science qualifications, the reality is that most of the computing lessons taught anywhere on the planet are taught by a non-specialist teacher. That is even more so the case for anything related to AI. If we’re serious about AI literacy for young people, we have to get serious about AI literacy for teachers. 

Rethinking computer science 

Alongside introducing AI literacy, we also need to take a hard look at computer science. At the very least, we need to make sure that computer science curricula include machine learning models, explaining how they constitute a new paradigm for computing, and give more emphasis to the role that data will play in the future of computing. Adding anything new to an already packed computer science curriculum means tough choices about what to deprioritise to make space.

Elephants in the Serengeti.
One of our Experience AI Lessons revolves around the us of AI technology to study the Serengeti ecosystem.

And, while we’re reviewing curricula, what about biology, geography, or any of the other subjects that are just as likely to be revolutionised by big data and AI? As part of Experience AI, we are launching some of the first lessons focusing on ecosystems and AI, which we think should be at the heart of any modern biology curriculum. 

Some are saying young people don’t need to learn how to code. It’s an easy political soundbite, but it just doesn’t stand up to serious scrutiny.

There is already a lively debate about the extent to which the new generation of AI technologies will make programming as we know it obsolete. In January, the prestigious ACM journal ran an opinion piece from Matt Welsh, founder of an AI-powered programming start-up, in which he said: “I believe the conventional idea of ‘writing a program’ is headed for extinction, and indeed, for all but very specialised applications, most software, as we know it, will be replaced by AI systems that are trained rather than programmed.”

Computer science students at a desktop computer in a classroom.
Writing computer programs is an essential part of learning how to analyse problems in computational terms.

With GitHub (now part of Microsoft) claiming that their pair programming technology, Copilot, is now writing 46 percent of developers’ code, it’s perhaps not surprising that some are saying young people don’t need to learn how to code. It’s an easy political soundbite, but it just doesn’t stand up to serious scrutiny. 

Even if AI systems can improve to the point where they generate consistently reliable code, it seems to me that it is just as likely that this will increase the demand for more complex software, leading to greater demand for more programmers. There is historical precedent for this: the invention of abstract programming languages such as Python dramatically simplified the act of humans providing instructions to computers, leading to more complex software and a much greater demand for developers. 

A child codes a Spiderman project at a laptop during a Code Club session.
Learning to program will help young people understand how the world around them is being transformed by AI systems.

However these AI-powered tools develop, it will still be essential for young people to learn the fundamentals of programming and to get hands-on experience of writing code as part of any credible computer science course. Practical experience of writing computer programs is an essential part of learning how to analyse problems in computational terms; it brings the subject to life; it will help young people understand how the world around them is being transformed by AI systems; and it will ensure that they are able to shape that future, rather than it being something that is done to them.

Enhancing teaching and learning through AI-powered technologies

Technology has already transformed learning. YouTube is probably the most important educational innovation of the past 20 years, democratising both the creation and consumption of learning resources. Khan Academy, meanwhile, integrated video instruction into a learning experience that gamified formative assessment. Our own edtech platform, Ada Computer Science, combines comprehensive instructional materials, a huge bank of questions designed to help learning, and automated marking and feedback to make computer science easier to teach and learn. Brilliant though these are, none of them have even begun to harness the potential of AI systems like large language models (LLMs).

The challenge for all of us working in education is how we ensure that ethics and privacy are at the centre of the development of [AI-powered edtech].

One area where I think we’ll see huge progress is feedback. It’s well-established that good-quality feedback makes a huge difference to learning, but a teacher’s ability to provide feedback is limited by their time. No one is seriously claiming that chatbots will replace teachers, but — if we can get the quality right — LLM applications could provide every child with unlimited, on-demand feedback. AI-powered feedback — not giving students the answers, but coaching, suggesting, and encouraging in the way that great teachers already do — could be transformational.

Two adults learn about computing at desktop computers.
The challenge for all of us working in education is how we ensure that ethics and privacy are at the centre of the development of AI-powered edtech.

We are already seeing edtech companies racing to bring new products and features to market that leverage LLMs, and my prediction is that the pace of that innovation is going to increase exponentially over the coming years. The challenge for all of us working in education is how we ensure that ethics and privacy are at the centre of the development of these technologies. That’s important for all applications of AI, but especially so in education, where these systems will be unleashed directly on young people. How much data from students will an AI system need to access? Can that data — aggregated from millions of students — be used to train new models? How can we communicate transparently the limitations of the information provided back to students?

Ultimately, we need to think about how parents, teachers, and education systems (the purchasers of edtech products) will be able to make informed choices about what to put in front of students. Standards will have an important role to play here, and I think we should be exploring ideas such as an AI kitemark for edtech products that communicate whether they meet a set of standards around bias, transparency, and privacy. 

Realising potential in a brave new world

We may very well be entering an era in which AI systems dramatically enhance the creativity and productivity of humanity as a species. Whether the reality lives up to the hype or not, AI systems are undoubtedly going to be a big part of all of our futures, and we urgently need to figure out what that means for education, and what skills, knowledge, and mindsets young people need to develop in order to realise their full potential in that brave new world. 

That’s the work we’re engaged in at the Raspberry Pi Foundation, working in partnership with individuals and organisations from across industry, government, education, and civil society.

If you have ideas and want to get involved in shaping the future of computing education, we’d love to hear from you.

This article will also appear in issue 22 of Hello World magazine, which focuses on teaching and AI. We are publishing this new issue on Monday 23 October. Sign up for a free digital subscription to get the PDF straight to your inbox on the day.

The post What does AI mean for computing education? appeared first on Raspberry Pi Foundation.

Откъси от Украйна: Тогава тихичко се появи страхът…

Post Syndicated from original https://www.toest.bg/otkusi-ot-ukrayna-togava-tihichko-se-poyavi-strahut/

<< Към втора част

Откъси от Украйна: Тогава тихичко се появи страхът...

Дулото на танка сочи точно срещу изхода на метрото. Залива го пелена от проливен дъжд. Майданът и булевардът до него са притихнали под тежестта на сиви облаци и военна техника. Подготовката за парада на пленени руски бойни машини от сегашната война на Русия срещу Украйна започва ден преди 24 август, Деня на независимостта на Украйна. Дъждът в Киев полека-лека спира и мога да разгледам всичко по-отблизо.

Много от военните машини са обгорели, някои са без покриви, на трети има надписи: „Азов“, „Зарубежна“ (Чуждестранен), „ За Харкiв“ – с нарисувано до надписа сърце, „Никополь не бьi забуди“ (Никога не забравяйте Никопол), „Слава Україні“, „Дніпро“, „Руский иди на хуй“. Някои надписи са върху бетонни плочи, закрепени на танка. Вероятно са част от сграда или от нещо друго, взето от мястото, където танкът е рушил и убивал. Буквите са изкривени, набързо надраскани, задъхани и разтреперени.

Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...

© Николета Атанасова

Опитвам се да си представя ръцете, писали по тези танкове. Трескавия поглед. Страха, примесен с радостта от малката победа. Как изглеждат мъжете, пленили танка и изписали думи върху грозното му тяло.

Какъв мирис само има на фронта, направо воня! Но как да е другояче? Можехме да перем дрехите си само в някоя река. Нямахме вода за къпане, а беше лято. Къде ти сапун – търкаш си дрехите с камъни. Обличаш ги мокри, а наоколо всичко гори – каучук от гуми, човешки тела, поляните, горите. Навсякъде има пожари от стрелбата. Всичко гори. Миризмата е ужасна и прониква в дрехите ти, в тялото ти. Смърдиш целият на риба и огън.

Саша е ранен на фронта през лятото тази година. Очите му се движат бързо наляво-надясно. Прилича на тик. Пристъпва от крак на крак и ясно личи, че единият е по-къс от другия. Костта му е раздробена от куршум по време на бой. Сега на мястото на липсващата кост има метална пластина.

Представата ми за ветеран винаги е била за възрастен мъж със спомени от далечни времена, които никога няма да се върнат. Саша е висок, едър, с рехава черна брада.

Ветеран от настоящата война в Украйна, само на двайсет и четири години.

Володимир е на трийсет и пет. Запознахме се във Виница. И той е ветеран.

Въпросът за войната е много сложен. Как се чувства човек? Първо е страх и неразбиране. Когато тръгнахме, на една улица тлъст полицай ни отдаваше чест, докато колоната ни, километри дълга, преминаваше покрай него. В същото време ни махаха и жени с леко поведение. Горди бяхме, че щом и полицаят, и проститутките разбират къде отиваме, значи, ето ни! Но колкото повече се приближаваш към фронтовата линия и виждаш разрушенията, започваш да разбираш, че тук не е, както си си го представял, докато ти махат и отдават чест. Тогава тихичко, лично в мен, се появи страхът – какво ще бъде, как ще бъде…

Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...

Володимир Скосогоренко © Николета Атанасова

Саша се сражава в Купянска, Миколаевска и Харкивска област. Губи най-близките си приятели на фронта. Те също са били момчета като него. Най-младият – на двайсет и една, най-възрастният – на двайсет и осем. Всички са убити по време на сраженията.

Единият загина от куршум и излезе късметлия, защото другия го разкъса мина и половин месец правиха ДНК експертиза, за да се разбере той ли е, или не е той. Просто нямаше достатъчно от тялото му, за да се направи експертизата, събирахме го на парчета. Друг мой приятел пък изгоря и също едва установиха кой е, защото беше сирак и нямаше от кого да се вземе ДНК. Едва намериха някакъв роднина, за да сравнят пробите и да разберат…

Според Саша двамата му приятели, разкъсани на фронта, са едва ли не щастливци, защото са успели да ги идентифицират. Тези, които не могат да бъдат разпознати, се водят безследно изчезнали в боя и семействата им не получават компенсация.

Пазим остатъците от вещите им и само си спомняме за тях. Толкоз.

Откъси от Украйна: Тогава тихичко се появи страхът...

© Николета Атанасова

Столът лекичко изскърцва, Володимир се намества в него и издишва дима от цигарата си. Изучава ме внимателно, сякаш се опитва да прозре колко от разказа му мога наистина да разбера. Започва бавно:

Пристигнахме на местоназначението. Момчетата, които сменихме, бързо-бързо си събраха нещата и си тръгнаха. И ние: „А..? Какво става..?“ Тези, които останаха, ни разказаха, че преди дни е имало няколко силни обстрела точно на нашите позиции. Бяха ни инструктирали, че веднага щом започнат взривове, трябва да се скрием, и затова ние постоянно тичахме. Щом чуехме непознат звук, падахме по очи. Пристигна втората група момчета. Имаше тревога „въздух“. След отбоя усетихме силна миризма на фекалии. Не разбрахме откъде идва. Излязохме от окопа и видяхме как едно момче седи до кръста във фекалии. Питаме го: какво правиш, какво е това? Той отговаря: аз току-що пристигнах и ми казаха, че при команда „нападение от въздуха“ трябва незабавно да скоча в някоя дълбока дупка, но никой не ми каза, че тази дупка е тоалетна. Смяхме се много, но това беше защитна реакция, защото след малко пак започна обстрел и усетихме какво е в действителност към теб да летят мини. Мой приятел го събрахме на части, в торба, защото върху него падна мина. В този момент разбираш, че истинската война не е като във филмите с Рамбо. В съзнанието ти изплува, че във всеки един момент би могло да…

Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...

© Макс Левин / Украински център за сигурност и сътрудничество / Володя Юрченко

Саша лекичко докосва крака си с ръка. Убеден е, че най-голямата трагедия е за тези момчета, които остават осакатени за цял живот, с откъснати от мините крака и ръце.

Да, живи са, но какъв живот е за човек на двайсет години това да е осакатен по този начин. Без крака, без ръце. Как ще си намери момиче, как ще живее, кой би се грижил за него?

Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...

© Макс Левин / Украински център за сигурност и сътрудничество / Володя Юрченко

На фронта постоянно те връхлитат черни мисли,

казва ми Володимир, докато поглежда телефона си. Изключва го и продължава:

Нашата част беше обкръжена. Тогава, за да преодолеем страха, започваме да правим различни полезни неща. Копаем окопи, почистваме оръжията, пишем писма, разговаряме с неправителствени организации. И през цялото време не спираме да се поддържаме един друг с думи, за да не зациклим върху това, което ни заобикаля, и максимално да потиснем емоциите.

Гледам този висок, хубав мъж и си представям, че съм негова майка, сестра, любима – какво ли бих почувствала, докато чета редовете, в които ми пише, че върху него падат бомби, приятелят му е разкъсан от мина, частта му е обкръжена и не е ясно дали ще оцелее, или ще го пленят. Какво ли бих му отговорила? Как бих го окуражила? Той ще ми повярва ли, знаейки, че докато преживява всичко това, аз съм в някой град, където животът все пак продължава.

Предадоха ни, че са нападнали наш пост. Чувахме картечници. Ние бяхме назад в кръгова отбрана. Имахме далекобойни оръдия, но за да стигнем до тях, трябваше да минем през минно поле. Това е преломен момент за психиката – да превъзмогнеш страха, защото си наясно, че ако настъпиш мината – край. В същото време обаче трябва да тичаш към оръжието. Каквото и да ти се случва, каквото и да ти се наложи да направиш, знаеш, че трябва да си свършиш работата. Стигнахме до оръжията, заехме позиция. В това време пристигна и нашият БТР, който ни помогна. Всичко приключи много бързо. Седнахме, запалихме по цигара и един от по-възрастните войници ни каза: „Браво, мъже! Рискът за живота е този повратен момент, който ви прави не просто войници, а военни, които могат да воюват.“

Виждам, че Саша е притеснен. Сякаш иска да сподели нещо, което смята, че няма да ми хареса. Казвам му да говори спокойно, защото, ако някой е държал в ръцете си разкъсания труп на свой приятел, има право да каже всичко, дори и да не ми хареса. Той се усмихва по детски и започва да говори бързо.

За мен е много важно да кажа, че това, дето се твърди, че руснаците не могат да воюват, не е вярно. Те могат да воюват добре, колкото и да ми е неприятно да го призная. Освен това ни превъзхождат числено. Ако при една битка от техните загинат двайсет души, веднага на тяхно място идват нови двайсет, и нови, и нови… При нас не е така. За тях загубата на двайсет души не е нищо. За нас е много. Затова и се грижим за хората си повече, но пак не е достатъчно.

Притихва. Гледа ме изпитателно и малко виновно. Търси в мен упрека. Не го намира. Добива кураж и продължава:

Освен това тяхната военна индустрия работи, и то явно добре, защото гилзите, които падаха при нас, бяха с дата от тази година, значи са направени сега. Страната им е много голяма и очевидно всички работят сега за фронта. Нашите заводи не могат да смогнат да произведат такова количество оръжия и ако нямаме помощ от НАТО и ЕС, не знам какво би станало.

Откъси от Украйна: Тогава тихичко се появи страхът...
© Николета Атанасова

Мълчим и се гледаме около минута, без да знам какво да му кажа. Той пристъпва и се поклаща. Кракът го боли. Предлагам му да седнем. Отказва. Тогава споделя с мен още една своя тревога. Викат го отново на военна комисия, за да го върнат на фронта. Саша се притеснява, че кракът му няма да издържи, защото пластината в него е от метал, който не е медицински, а и не е поставена както трябва. Оперирали са го при полеви условия. Някои от лекарите му казали, че само да скочи или да се затича, пластината, която свързва костта му, може да се счупи. Други обаче го посъветвали, ако се счупи, да си върже крака с колана. Докато ми разказва това, тялото му сякаш се смалява и прегърбва. Преживява всяка своя дума. Тревожи се за две неща. Едното е, че някой може да го помисли за страхливец. Другото – че металната пластина може да не издържи в боя, когато се върне там.

Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...

© Макс Левин / Украински център за сигурност и сътрудничество / Володя Юрченко

Саша се надява, ако отново отиде да се сражава, да е пак в артилерията, откъдето се връща. Защото в пехотата боевете се водят много отблизо, а окопите на двете страни са на десет метра разстояние един от друг.

Виждат се очи в очи и си мятат един на друг гранати. Това е някакъв кошмар.

За университета, в който е учил до началото на войната, вече не мечтае, защото не знае дали ще оцелее. Въпреки всичко Саша не се съмнява, че Украйна ще победи. Почти въпросително ми казва:

Но кога ще се случи това и колко още човешки животи ще коства…

Тревожи се, че доброволците за фронта намаляват и ще се наложи задължителна мобилизация.

Даваме много жертви и това ще обърне нещата към лошо, защото каква ще е тази армия с войници, които са изпратени на фронта насила? Войната трябва да приключи, преди да са свършили тези, които отиват да воюват като доброволци.

Володимир е убеден, че ще се върне на фронта, където е и по-големият му брат.

Знам и съм готов. Мъжете в Украйна днес разбират, че рано или късно всички ще трябва да воюват. Защото факторите войната да спре са твърде много и не вярвам да сработят. Този конфликт не го създава само един човек. И тях никой не ги кара насила да ни убиват, нали? Руснаците могат и да се предадат, ако не искат да ни убиват. Тоест и в главите на войниците трябва нещо да се случи, както и в тяхното правителство и командване.

С Володимир говорим дълго за преживяванията на момчетата, когато се върнат от фронта. Според него това е много тежък период, защото войната променя хората страшно много.

Ценности като „не убивай“, „хуманност“, „добрина“ се заличават. Войната ги изтрива. Каквото и да си чувствал преди, спираш да го чувстваш, защото чувства по време на война не може да има, не съществуват. Всичко се заличава.

Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...
Откъси от Украйна: Тогава тихичко се появи страхът...

© Макс Левин / Украински център за сигурност и сътрудничество / Володя Юрченко

Володимир разказва, че след като се завърнат от фронта, много негови приятели искат да се самоубият, а някои дори са се самоубили, защото съпругите им не разбират промяната в тях и ги напускат заедно с децата им. Или пък всеки ден пристигат вести за загинали на фронта техни приятели.

Те губят смисъл и доверие в цивилния свят. Чувстваш се сам и се питаш: а какво следва оттук нататък? Какво? Но искам да ви кажа, че войната е най-ужасното нещо, което може да ти се случи, и в същото време е най-прекрасното, защото ти се иска да се върнеш там. Тя е като наркотик. Да, там е тежко, но когато се прибереш в цивилния живот, си мислиш, че на фронта ти е по-добре, защото там разбираш всичко, там всичко ти е ясно и много просто. Има враг. Ти го убиваш – или той теб. Това е.

Мълча и за пореден път не знам какво да кажа. Толкова много болка има в тези момчета, толкова много тъга и в същото време такава решителност. Питам Володимир как му изглеждат Европа и останалият свят, докато е на бойното поле, под обстрела на ракетите.

Преди се ядосвах много, защото, за съжаление, Европа не разбира, че те няма да спрат до нас и ако превземат Украйна, ще продължат нататък. Кой и какво ще им попречи? Никой. Дори и аз не си помислях, че ще стигнат дотук, преди да започнат пълномащабната война. Но не, те се оказаха такива идиоти, че от тях явно може да се очаква всичко. Илюзия е, че страни от ЕС или НАТО са защитени, защото от руснаците може да се очаква абсолютно всичко. Най-ужасно е, че има хора в Европа, които не разбират как това не е само наша битка. Ние пазим безопасността на всички близки европейски страни.

Според Володимир най-страшното би било, ако Русия превземе Украйна.

Ще започнат да промиват мозъците и на украинците, които живеят тук, и ще стане така, че в един момент украинци ще воюват против Европа. Защото ако ни превземат, те ще ни заставят да воюваме за тях. А Европа си седи спокойно и си мисли: „Е, това се случва някъде там. Не е у дома. Защо трябва да им давам каквото и да било, ако са толкова далеч?“ На нас ни трябват още много оръжия, включително далекобойни, трябва ни ПВО, за да освободим територията си. А после ще построим такава граница, че те никога повече да не припарят тук. Трябва да се разбере и в Европа, и тук, че има враг и трябва да го спрем по всякакъв начин. Защото ако Украйна не ги спре, те ще продължат нататък и ще се опитат да провалят живота на всички. Знам, че във вашата страна има купени политици, които лъжат хората – не в името на благополучието на вашия народ, а по други причини. Откъде извират всички тези глупости за плоската земя, антиваксърските теории или за всемирния заговор и колективния Запад? От Русия идват и това не води до нищо добро. Трябва да го знаете.

Откъси от Украйна: Тогава тихичко се появи страхът...
Володимир Скосогоренко © Николета Атанасова

В Киев вече е тъмно. Върху платформата на огромен камион лежи танк. Голям кран бавно го стоварва на площада до другите.

Момченце на около пет години пита баща си: „Татко, татко, какво е това?“ Баща му отговаря: „Това е танковоз.“

Била съм в подножието на танк само в музей. Зловещо е. Знаеш обаче, че това е било в предишни, далечни времена и когато си тръгнеш от музея, нищо не те грози. Тези танкове на Майдана в Киев са воювали току-що срещу Украйна. Разрушавали са градове, училища, убивали са невинни хора и деца насред Европа през ХХI век. Мисля си защо му е на малкото дете да научава дума като „танковоз“. Колко още ще му се налага да я чува и използва? Докато стане достатъчно голямо, за да воюва?

Време е да тръгваме, наближава комендантският час. Звъня на Юлия, доброволка, която носи помощи до фронтовата линия. Искам да се срещнем на другия ден във Виница. Разбира се, телефонният оператор се включва с вече познатото:

Моля, изчакайте. Абонатът говори за победата.

Вървим бавно към хотела. Сирени. Вибриращ телефон. Стрелки по тротоара сочат към „убежище“. Някак ми е все едно. Няма да се крием. Просто продължаваме по чистите, блестящи улици на Киев.

Multiple Load Balance Support in AWS CodeDeploy

Post Syndicated from Brian Beach original https://aws.amazon.com/blogs/devops/multiple-load-balance-support-in-codedeploy/

AWS CodeDeploy is a fully managed deployment service that automates software deployments to various compute services, such as Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (ECS), AWS Lambda, and on-premises servers. AWS CodeDeploy recently announced support for deploying to applications that use multiple AWS Elastic Load Balancers (ELB). CodeDeploy now supports multiple Classic Load Balancers (CLB), and multiple target groups associated with Application Load Balancers (ALB) or Network Load Balancer (NLB) when using CodeDeploy with Amazon EC2. In this blog post, I will show you how to deploy an application served by multiple load balancers.

Background

AWS CodeDeploy simplifies deploying application updates across Amazon EC2 instances registered with Elastic Load Balancers. The integration provides an automated, scalable way to deploy updates without affecting application availability.

To use CodeDeploy with load balancers, you install the CodeDeploy agent on Amazon EC2 instances that have been registered as targets of a Classic, Application, or Network Load Balancer. When creating a CodeDeploy deployment group, you specify the load balancer and target groups you want to deploy updates to.

During deployment, CodeDeploy safely shifts traffic by deregistering instances from the load balancer, deploying the new application revision, and then re-registering the instances to route traffic back. This approach ensures application capacity and availability are maintained throughout the deployment process. CodeDeploy coordinates the traffic shift across groups of instances, so that the deployment rolls out in a controlled fashion.

CodeDeploy offers two deployment approaches to choose from based on your needs: in-place deployments and blue/green deployments. With in-place deployments, traffic is shifted to the new application revision on the same set of instances. This allows performing rapid, incremental updates. Blue/green deployments involve shifting traffic to a separate fleet of instances running the new revision. This approach enables easy rollback if needed. CodeDeploy makes it easy to automate either deployment strategy across your infrastructure.

Architectures with Multiple Load Balancers

CodeDeploy’s expanded integration with Elastic Load Balancing unlocks new deployment flexibility. Users can now register multiple Classic Load Balancers and multiple target groups associated with Application or Network Load Balancers. This allows you to deploy updates across complex applications that leverage multiple target groups. For example, many customers run applications that serve both an internal audience and external audience. Often, these two audiences require different authentication and security requirements. It is common to provide access to the internal and external audiences through different load balancers, as shown in the following image.

Architecture showing two load balancers, one external facing and one internal facing

In the past, CodeDeploy only supported one load balancer per application. Customers running internal and external application tiers would have to duplicate environments, using separate EC2 instances and Amazon EC2 Auto Scaling groups for each audience. This resulted in overprovisioning and added overhead to manage duplicate resources.

With multiple load balancer support, CodeDeploy removes the need to duplicate environments. Users can now deploy updates to a single environment, and CodeDeploy will manage the deployment across both the internal and external load balancers. You simply select all the target groups used by your application, as shown in the following image.

CodeDeploy configuration showing two load balancers selected

This consolidated approach reduces infrastructure costs and operational complexity when automating deployments. CodeDeploy orchestrates the in-place or blue/green deployment across multiple load balanced target groups.

Migrating from a Classic Load Balancer

Many customers are migrating from Classic Load Balancers (CLB) to Application Load Balancers (ALB) or Network Load Balancers (NLB). ALB and NLB offer a more modern and advanced feature set than CLB, including integrated path-based and host-based routing, and native IPv6 support. They also deliver improved load balancing performance with higher throughput and lower latency. Other benefits include native integrations with AWS WAF, Shield, and Global Accelerator along with potential cost savings from requiring fewer load balancers. Overall, migrating to ALB or NLB provides an opportunity to gain advanced capabilities, better performance, tighter service integration, and reduced costs.

CodeDeploy’s new multi-target group capabilities streamline migrating from Classic Load Balancers (CLB) to Application or Network Load Balancers (ALB or NLB). Users can now deploy applications utilizing both legacy CLB and modern ALB or NLB in parallel during the transition. This enables gracefully testing integration with the new load balancers before fully cutting over. Once you verify that users have stopped using the CLB endpoint, you can delete the CLB.

During the transition period, CodeDeploy orchestrates deployments across the CLB and target groups tied to the ALB or NLB within a single automation. Users simply select the CLB and target groups of the new load balancer in the deployment group as shown in the following image.

CodeDeploy configuration showing a both a classic load balancer and target group selected

This consolidated approach lets CodeDeploy coordinate a staged rollout across CLB and ALB/NLB. With simplified management of multiple load balancers, CodeDeploy eases the critical process of modernizing infrastructure while maintaining application availability.

Conclusion

CodeDeploy’s expanded integration with Elastic Load Balancing allows more flexible application deployments. Support for multiple Classic Load Balancers and multiple target groups associated with Application or Network Load Balancers enables you to seamlessly update complex architectures on AWS. Whether you are consolidating disparate environments or migrating from Classic Load Balancers, CodeDeploy simplifies managing deployments across multiple load balanced tiers. To learn more, see Integrating CodeDeploy with Elastic Load Balancing in the AWS CodeDeploy Developer Guide or visit the CodeDeploy product page.

Enhance your security posture by storing Amazon Redshift admin credentials without human intervention using AWS Secrets Manager integration

Post Syndicated from Tahir Aziz original https://aws.amazon.com/blogs/big-data/enhance-your-security-posture-by-storing-amazon-redshift-admin-credentials-without-human-intervention-using-aws-secrets-manager-integration/

Amazon Redshift is a fully managed, petabyte-scale data warehouse service in the cloud. You can start with just a few hundred gigabytes of data and scale to a petabyte or more. Today, tens of thousands of AWS customers—from Fortune 500 companies, startups, and everything in between—use Amazon Redshift to run mission-critical business intelligence (BI) dashboards, analyze real-time streaming data, and run predictive analytics. With the constant increase in generated data, Amazon Redshift customers continue to achieve success in delivering better service to their end-users, improving their products, and running an efficient and effective business.

AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, and natively supports storing database secrets for Amazon Relational Database Service (Amazon RDS), Amazon Aurora, Amazon Redshift, and Amazon DocumentDB (with MongoDB compatibility). We recommend you use Secrets Manager for storing Amazon Redshift user credentials because it allows you to configure safer secret rotation, customize fine-grained access control, and audit and monitor secrets centrally. You can natively use existing Secrets Manager secrets to access Amazon Redshift using the Amazon Redshift API and query editor.

Until now, you would have needed to configure your Amazon Redshift admin credentials in plaintext, or let Amazon Redshift generate credential for you. To store these credentials in Secrets Manager, you either needed to manually create a secret, or configure scripts with the credentials hardcoded or generated. Both options required a human to retrieve them. Amazon Redshift now allows you to create and store admin credentials automatically without a human needing to see the credentials. As part of this workflow, the admin credentials are configured to rotate every 30 days automatically. By reducing the need for humans to see the secret during configuration, you can increase the security posture of your Amazon Redshift data warehouse and improve the accuracy of your audit trails.

In this post, we show how to integrate Amazon Redshift admin credentials with Secrets Manager for both new and previously provisioned Redshift clusters and Amazon Redshift Serverless namespaces.

Prerequisites

Complete the following prerequisites before starting:

  1. Have admin privileges to create and manage Redshift Serverless namespaces or Redshift clusters.
  2. Have admin privileges to create and manage secrets in Secrets Manager.
  3. Optionally, have a Redshift Serverless namespace or a Redshift cluster to enable Secrets Manager integration.
  4. Optionally, have different AWS Key Management Service (AWS KMS) keys for credentials encryption with Secrets Manager.
  5. Have access to Amazon Redshift Query Editor v2.

Set up a new cluster using Secrets Manager

In this section, we provide steps to configure either a Redshift provisioned cluster or a Redshift Serverless workgroup with Secrets Manager.

Create a Redshift provisioned cluster

To get started using Secrets Manager with a new Redshift provisioned cluster, complete the following steps:

  1. On the Amazon Redshift console, choose Create cluster.
  2. Define the Cluster configuration and Sample data sections as needed.
  3. In the Database configurations section, specify your desired admin user name.
  4. To use Secrets Manager to automatically create and store your password, select Manage admin credentials in AWS Secrets Manager.
  5. You can also customize the encryption settings with your own AWS customer managed KMS key by creating a key or choosing an existing one. This is the key that is used to encrypt the secret in Secrets Manager. If you don’t select Customize encryption settings, an AWS managed key will be used as default.
  6. Provide the information in Cluster permissions and Additional configurations as appropriate and choose Create cluster.
  7. When the cluster is available, you can check the ARN of the secret containing the admin password on the Properties tab of the cluster in the Database configurations section.

Create a Redshift Serverless workgroup

To get started using Secrets Manager with Redshift Serverless, create a Redshift Serverless workgroup with the following steps:

  1. On the Amazon Redshift Serverless dashboard, choose Create workgroup.
  2. Define the Workgroup name, Capacity, and Network and security sections as appropriate and choose Next.
  3. Select Create a new namespace and provide a suitable name
  4. In the Database name and password section, select Customize admin user and credentials.
  5. Provide an admin user name.
  6. In the Admin password section, select Manage admin credentials in AWS Secrets Manager.
  7. You can also customize the encryption settings with your own AWS customer managed KMS key by creating a key or choosing an existing one. This is the key that is used to encrypt the secret in Secrets Manager. If you don’t select Customize encryption settings, an AWS managed key will be used as default.
  8. Provide the information in the Permissions and Encryption and security sections as appropriate and choose Next.
  9. Review the selected options and choose Create.
  10. When the status of the newly created workgroup and namespace is Available, choose the namespace.
  11. You can find the Secrets Manager ARN with admin credentials under General information.

Enable Secrets Manager for an existing Redshift cluster

In this section, we provide steps to enable Secrets Manager for an existing Redshift provisioned cluster or a Redshift Serverless namespace.

Configure an existing Redshift provisioned cluster

To enable Secrets Manager for an existing Redshift cluster, follow these steps:

  1. On the Amazon Redshift console, choose the cluster that you want to modify.
  2. On the Properties tab, choose Edit admin credentials.
  3. Select Manage admin credentials in AWS Secrets Manager.
  4. To use AWS KMS to encrypt the data, select Customize encryption options and either choose an existing KMS key or choose Create an AWS KMS key.
  5. Choose Save changes.
  6. When the cluster is available, you can check the ARN of the secret containing the admin password on the Properties tab of the cluster in the Database configurations section.

Configure an existing Redshift Serverless namespace

To enable Secrets Manager on an existing Amazon Redshift Serverless namespace, follow these steps:

  1. On the Amazon Redshift Serverless Dashboard, choose the namespace that you want to modify.
  2. On the Actions menu, choose Edit admin credentials.
  3. Select Customize admin user credentials.
  4. Select Manage admin credentials in AWS Secrets Manager.
  5. To use AWS KMS to encrypt the data, select Customize encryption settings and either choose an existing AWS KMS key or choose Create an AWS KMS key.
  6. Choose Save changes.
  7. When the namespace status is Available, you can see the Secrets Manager ARN under Admin password ARN in the General information section.

Manage secrets in Secrets Manager

To manage the admin credentials in Secrets Manager, follow these steps:

  1. On the Secrets Manager console, choose the secret that you want to modify.

Amazon Redshift creates the secret with rotation enabled by default and a rotation schedule of every 30 days.

  1. To view the admin credentials, choose Retrieve secret value.
  2. To change the secret rotation, choose Edit rotation.
  3. Define the new rotation frequency and choose Save.
  4. To rotate the secret immediately, choose Rotate secret immediately and choose Rotate.

Secrets Manager can be integrated with your application via the AWS SDK, which is available in Java, JavaScript, C#, Python3, Ruby, and Go. The supported language code snippet is available in the Sample code section.

  1. Choose the tab for your preferred language and use the code snippet provided in your application.

Restore a snapshot

New warehouses can be launched from both serverless and provisioned snapshots. You have the choice to configure the restored cluster to use Secrets Manager credentials, even if the source cluster didn’t use Secrets Manager, by following these steps:

  1. Navigate to either the Redshift snapshot dashboard for snapshots of provisioned clusters or the Redshift data backup dashboard for snapshots of serverless workgroups and choose the snapshot you’d like to restore from.
    On the provisioned snapshot dashboard, on the Restore snapshot menu, choose Restore to provisioned cluster or Restore to serverless namespace.

    On the serverless snapshot dashboard, on the Actions menu, under Restore serverless snapshot, choose Restore to provisioned cluster or Restore to serverless namespace.

    If you’re restoring to a serverless endpoint from either option, you will need to have the target serverless namespace configured in advance.
  1. If you’re restoring to a warehouse using a snapshot that doesn’t have Secrets Manager credentials configured, you can enable it in the Database configuration section of the snapshot restoration page by selecting Manage admin credentials in AWS Secrets Manager.
  2. You can also customize the encryption settings with your own AWS customer managed KMS key by creating a key or choosing an existing one. If you don’t select Customize encryption settings, an AWS managed key will be used as default.
  3. If the snapshot was taken from a cluster that was using Secrets Manager to manage its admin credentials and you’re restoring to a provisioned cluster, you can optionally choose to update the key used to encrypt credentials in Secrets Manager. Otherwise, if you’d like to use the same configuration as the source snapshot, you can choose the same key as before.
  4. After you configure all the necessary details, choose Restore cluster from snapshot/Save changes to launch your provisioned cluster, or choose Restore to write the snapshot data to the namespace.

Connect to Amazon Redshift via Query Editor v2 using Secrets Manager

To connect to Amazon Redshift using Query Editor v2, complete the following steps:

  1. On the Amazon Redshift console, choose the cluster that you want to connect to.
  2. On the Properties tab, locate the admin user and admin password ARN.
  3. Make a note of the ARN to be used in the later steps.
  4. At the top of the cluster details page, on the Query data menu, choose Query in query editor v2.
  5. Locate the Redshift cluster or Redshift Serverless workgroup you want to connect to and choose the options menu (three dots) next to its name, then choose Create connection.
  6. In the connection window, select AWS Secrets Manager.
  7. For Secret, choose the appropriate secret for your cluster.
  8. Choose Create connection.

Note that access to the secrets can be controlled by AWS Identity and Access Management (IAM) permissions.

The connection should be established to your cluster now and you will be able to see the database objects in your cluster as well as run queries against your cluster

Conclusion

In this post, we demonstrated how the Secrets Manager integration with Amazon Redshift has simplified storing admin credentials. It’s a simple-to-use feature that is available immediately and automates the important task of maintaining admin credentials and rotating them for your Redshift data warehouse. Try it out today and leave a comment if you have any questions or suggestions.

About the Authors

Tahir Aziz is an Analytics Solution Architect at AWS. He has worked with building data warehouses and big data solutions for over 15 years. He loves to help customers design end-to-end analytics solutions on AWS. Outside of work, he enjoys traveling and cooking.

Julia Beck is an Analytics Specialist Solutions Architect at AWS. She supports customers in validating analytics solutions by architecting proof of concept workloads designed to meet their specific needs.

Ekta Ahuja is a Senior Analytics Specialist Solutions Architect at AWS. She is passionate about helping customers build scalable and robust data and analytics solutions. Before AWS, she worked in several different data engineering and analytics roles. Outside of work, she enjoys baking, traveling, and board games.

The collective thoughts of the interwebz