Using Single Sign On (SSO) to manage project teams for Amazon CodeCatalyst

Post Syndicated from Divya Konaka Satyapal original https://aws.amazon.com/blogs/devops/using-single-sign-on-sso-to-manage-project-teams-for-amazon-codecatalyst/

Amazon CodeCatalyst is a modern software development service that empowers teams to deliver software on AWS easily and quickly. Amazon CodeCatalyst provides one place where you can plan, code, and build, test, and deploy your container applications with continuous integration/continuous delivery (CI/CD) tools.

CodeCatalyst recently announced the teams feature, which simplifies management of space and project access. Enterprises can now use this feature to organize CodeCatalyst space members into teams using single sign-on (SSO) with IAM Identity Center. You can also assign SSO groups to a team, to centralize your CodeCatalyst user management.
CodeCatalyst space admins can create teams made up any members of the space and assign them to unique roles per project, such as read-only or contributor.

Introduction:

In this post, we will demonstrate how enterprises can enable access to CodeCatalyst with their workforce identities configured in AWS IAM Identity Center, and also easily manage which team members have access to CodeCatalyst spaces and projects. With AWS IAM Identity Center, you can connect a self-managed directory in Active Directory (AD) or a directory in AWS Managed Microsoft AD by using AWS Directory Service. You can also connect other external identity providers (IdPs) like Okta or OneLogin to authenticate identities from the IdPs through the Security Assertion Markup Language (SAML) 2.0 standard. This enables your users to sign in to the AWS access portal with their corporate credentials.

Pre-requisites:

To get started with CodeCatalyst, you need the following prerequisites. Please review them and ensure you have completed all steps before proceeding:

1. Set up an CodeCatalyst space. To join a space, you will need to either:

  1. Create an Amazon CodeCatalyst space that supports identity federation. If you are creating the space, you will need to specify an AWS account ID for billing and provisioning of resources. If you have not created an AWS account, follow the AWS documentation to create one

    Figure 1: CodeCatalyst Space Settings

    Figure 1: CodeCatalyst Space Settings

  2. Use an IAM Identity Center instance that is part of your AWS Organization or AWS account to associate with CodeCatalyst space.
  3. Accept an invitation to sign in with SSO to an existing space.

2. Create an AWS Identity and Access Management (IAM) role. Amazon CodeCatalyst will need an IAM role to have permissions to deploy the infrastructure to your AWS account. Follow the documentation for steps how to create an IAM role via the Amazon CodeCatalyst console.

3. Once the above steps are completed, you can go ahead and create projects in the space using the available blueprints or custom blueprints.

Walkthrough:

The emphasis of this post, will be on how to manage IAM identity center (SSO) groups with CodeCatalyst teams. At the end of the post, our workflow will look like the one below:

Figure 2: Architectural Diagram

Figure 2: Architectural Diagram

For the purpose of this walkthrough, I have used an external identity provider Okta to federate with AWS IAM Identity Center to manage access to CodeCatalyst.

Figure 3: Okta Groups from Admin Console

Figure 3: Okta Groups from Admin Console

You can also see the same Groups are synced with the IAM Identity Center instance from the figure below. Please note Groups and member management must be done only via external identity providers.

Figure 4: IAM Identity Center Groups created via SCIM synch

Figure 4: IAM Identity Center Groups created via SCIM synch

Now, if you go to your Okta apps and click on ‘AWS IAM Identity Center’, the AWS account ID and CodeCatalyst space that you created as part of prerequisites should be automatically configured for you via single sign-on. Developers and Administrators of the space can easily login using this integration.

Figure 5: CodeCatalyst Space via SSO

Figure 5: CodeCatalyst Space via SSO

Once you are in the CodeCatalyst space, you can organize CodeCatalyst space members into teams, and configure the default roles for them. You can choose one of the three roles from the list of space roles available in CodeCatalyst that you want to assign to the team. The role will be inherited by all members of the team:

  • Space administrator – The Space administrator role is the most powerful role in Amazon CodeCatalyst. Only assign the Space administrator role to users who need to administer every aspect of a space, because this role has all permissions in CodeCatalyst. For details, see Space administrator role.
  • Power user – The Power user role is the second-most powerful role in Amazon CodeCatalyst spaces, but it has no access to projects in a space. It is designed for users who need to be able to create projects in a space and help manage the users and resources for the space. For details, see Power user role.
  • Limited access – It is the role automatically assigned to users when they accept an invitation to a project in a space. It provides the limited permissions they need to work within the space that contains that project. For details, see Limited access role.

Since you have the space integrated with SSO groups set up in IAM Identity Center, you can use that option to create teams and manage members using SSO groups.

Figure 6: Managing Teams in CodeCatalyst Space

Figure 6: Managing Teams in CodeCatalyst Space

In this example here, if I go into the ‘space-admin’ team, I can view the SSO group associated with it through IAM Identity Center.

Figure 7: SSO Group association with Teams

Figure 7: SSO Group association with Teams

You can now use these teams from the CodeCatalyst space to help manage users and permissions for the projects in that space. There are four project roles available in CodeCatalyst:

  • Project administrator — The Project administrator role is the most powerful role in an Amazon CodeCatalyst project. Only assign this role to users who need to administer every aspect of a project, including editing project settings, managing project permissions, and deleting projects. For details, see Project administrator role.
  • Contributor — The Contributor role is intended for the majority of members in an Amazon CodeCatalyst project. Assign this role to users who need to be able to work with code, workflows, issues, and actions in a project. For details, see Contributor role.
  • Reviewer — The Reviewer role is intended for users who need to be able to interact with resources in a project, such as pull requests and issues, but not create and merge code, create workflows, or start or stop workflow runs in an Amazon CodeCatalyst project. For details, see Reviewer role.
  • Read only — The Read only role is intended for users who need to view the resources and status of resources but not interact with them or contribute directly to the project. Users with this role cannot create resources in CodeCatalyst, but they can view them and copy them, such as cloning repositories and downloading attachments to issues to a local computer. For details, see Read only role.

For the purpose of this demonstration, I have created projects from the default blueprints (I chose the modern three-tier web application blueprint) and assigned Teams to it with specific roles. You can also create a project using a default blueprint in CodeCatalyst space if you don’t already have an existing project.

Figure 8: Teams in Project Settings

Figure 8: Teams in Project Settings

You can also view the roles assigned to each of the teams in the CodeCatalyst Space settings.

Figure 9: Project roles in Space settings

Figure 9: Project roles in Space settings

Clean up your Environment:

If you have been following along with this workflow, you should delete the resources you deployed so you do not continue to incur charges. First, delete the two stacks that CDK deployed using the AWS CloudFormation console in the AWS account you associated when you launched the blueprint. If you had launched the Modern three-tier web application just like I did, these stacks will have names like mysfitsXXXXXWebStack and mysfitsXXXXXAppStack. Second, delete the project from CodeCatalyst by navigating to Project settings and choosing Delete project.

Conclusion:

In this post, you learned how to add Teams to a CodeCatalyst space and projects using SSO Groups. I used Okta for my external identity provider to connect with IAM Identity Center, but you can use your Organizations idP or any other IDP that supports SAML. You also learned how easy it is to maintain SSO group members in the CodeCatalyst space by assigning the necessary roles and restricting access when not necessary.

About the Authors:

Divya Konaka Satyapal

Divya Konaka Satyapal is a Sr. Technical Account Manager for WWPS Edtech/EDU customers. Her expertise lies in DevOps and Serverless architectures. She works with customers heavily on cost optimization and overall operational excellence to accelerate their cloud journey. Outside of work, she enjoys traveling and playing tennis.

25 Years of Krita

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

The developers of the Krita painting
application are celebrating
25 years of development
with a detailed history of the project.

A quarter century. That’s how long we’ve been working on
Krita. Well, what would become Krita. It started out as KImageShop,
but that name was nuked by a now long-dead German lawyer. Then it
was renamed to Krayon, and that name was also nuked. Then it was
renamed to Krita, and that name stuck.

Security updates for Friday

Post Syndicated from daroc original https://lwn.net/Articles/976209/

Security updates have been issued by Debian (gst-plugins-base1.0), Fedora (cacti, cacti-spine, roundcubemail, and wireshark), Oracle (.NET 7.0, .NET 8.0, bind and dhcp, gdk-pixbuf2, git-lfs, glibc, grafana, krb5, pcp, python-dns, python3, sssd, tigervnc, xorg-x11-server, and xorg-x11-server-Xwayland), Red Hat (edk2, less, nghttp2, and ruby:3.0), SUSE (gstreamer-plugins-base, Java, kernel, and python-requests), and Ubuntu (ffmpeg, node-browserify-sign, postgresql-14, postgresql-15, postgresql-16, and python-pymysql).

Implementing network traffic inspection on AWS Outposts rack

Post Syndicated from Macey Neff original https://aws.amazon.com/blogs/compute/implementing-network-traffic-inspection-on-aws-outposts-rack/

This blog post is written by Brian Daugherty, Principal Solutions Architect. Enrico Liguori, Solution Architect, Networking. Sedji Gaouaou, Senior Solution Architect, Hybrid Cloud.

Network traffic inspection on AWS Outposts rack is a crucial aspect of making sure of security and compliance within your on-premises environment. With network traffic inspection, you can gain visibility into the data flowing in and out of your Outposts rack environment, enabling you to detect and mitigate potential threats proactively.

By deploying AWS partner solutions on Outposts rack, you can take advantage of their expertise and specialized capabilities to gain insights into network traffic patterns, identify and mitigate threats, and help ensure compliance with industry-specific regulations and standards. This includes advanced network traffic inspection capabilities, such as deep packet inspection, intrusion detection and prevention, application-level firewalling, and advanced threat detection.

This post presents an example architecture of deploying a firewall appliance on an Outposts rack to perform on-premises to Virtual Private Cloud (VPC) and VPC-to-VPC inline traffic inspection.

Architecture

The example traffic inspection architecture illustrated in the following diagram is built using a common Outposts rack deployment pattern.

In this example, an Outpost rack is deployed on premises to support:

  • Manufacturing/operational technologies (OT) applications that need low latency between OT servers and devices
  • Information technology (IT) applications that are subject to strict data residency and data protection policies

Separate VPCs, that can be owned by different AWS accounts, and subnets are created for the IT and OT departments’ instances (see 1 and 2 in the diagram).

Organizational security policies require that traffic flowing to and from the Outpost and the site, and between VPCs on the Outpost, be inspected, controlled, and logged using a centralized firewall.

In an AWS Region it is possible to implement a centralized traffic inspection architecture using routing services such as AWS Transit Gateways (TGW) or Gateway Load Balancers (GWLB) to route traffic to a central firewall, but these services are not available on Outposts.

On Outposts, some use the Local Gateway (LGW) to implement a distributed traffic inspection architecture with firewalls deployed in each VPC, but this can be operationally complex and cost prohibitive.

In this post, you will learn how to use a recently introduced feature – Multi-VPC Elastic Network Interface (ENI) Attachments – to create a centralized traffic inspection architecture on Outposts. Using Multi-VPC Attached ENIs you can attach ENIs created in subnets that are owned and managed by other VPCs (even VPCs in different accounts) to an Amazon Elastic Compute Cloud (EC2) instance.

Specifically, you can create ENIs in the IT and OT subnets that can be shared with a centralized firewall (see 3 and 4).

Because it’s a best practice to minimize the attack surface of a centralized firewall through isolation, the example includes a VPC and subnet created solely for the firewall instance (see 5).

To protect traffic flowing to and from the IT, OT, and firewall VPCs and on-site networks, another ‘Exposed’ VPC, subnet (see 6), and ENI (see 7) are created. These are the only resources associated with the Outposts Local Gateway (LGW) and ‘exposed’ to on-site networks.

In the example, traffic is routed from the IT and OT VPCs using a default route that points to the ENI used by the firewall (see 8 and 9). The firewall can route traffic back to the IT and OT VPCs, as allowed by policy, through its directly connected interfaces.

The firewall uses a route for the on-site network (192.168.30.0/24) – or a default route – pointing to the gateway associated with the exposed ENI (eni11, 172.16.2.1 – see 10).

To complete the routing between the IT, OT, and firewall VPCs and the on-site networks, static routes are added to the LGW route table pointing to the firewall’s exposed ENI as the next hop (see 11).

Once these static routes are inserted, the Outposts Ingress Routing feature will trigger the routes to be advertised toward the on-site layer-3 switch using BGP.

Likewise, the on-site layer-3 switch will advertise a route (see 12) for 192.168.30.0/24 (or a default route) over BGP to the LGW, completing end-to-end routing between on-site networks and the IT and OT VPCs through the centralized firewall.

The following diagram shows an example of packet flow between an on-site OT device and the OT server, inspected by the firewall:

Implementation on AWS Outposts rack

The following implementation details are essential for our example traffic inspection on the Outposts rack architecture.

Prerequisites

The following prerequisites are required:

  • Deployment of an Outpost on premises;
  • Creation of four VPCs – Exposed, firewall, IT, and OT;
  • Creation of private subnets in each of the four VPCs where ENIs and instances can be created;
  • Creation of ENIs in each of the four private subnets for attachment to the firewall instance (keep track of the ENI IDs);
  • If needed, sharing the subnets and ENIs with the firewall account, using AWS Resource Access Manager (AWS RAM);
  • Association of the Exposed VPC to the LGW.

Firewall selection and sizing

Although in this post a basic Linux instance is deployed and configured as the firewall, in the Network Security section of the AWS Marketplace, you can find several sophisticated, powerful, and manageable AWS Partner solutions that perform deep packet inspection.

Most network security marketplace offerings provide guidance on capabilities and expected performance and pricing for specific appliance instance sizes.

Firewall instance selection

Currently, an Outpost rack can be configured with EC2 instances in the M5, C5, R5, and G4dn families. As a user, you can select the size and number of instances available on an Outpost to match your requirements.

When selecting an EC2 instance for use as a centralized firewall it is important to consider the following:

  • Performance recommendations for instance types and sizes made by the firewall appliance partner;
  • The number of VPCs that are inspected by the firewall appliance;
  • The availability of instances on the Outpost.

For example, after evaluating the partner recommendations you may determine that an instance size of c5.large, r5.large, or larger provide the required performance.

Next, you can use the following AWS Command Line Interface (AWS CLI) command to identify the EC2 instances configured on an Outpost:

Outposts get-outpost-instance-types \
--outpost-id op-abcdefgh123456789

The output of this command lists the instance types and sizes configured on your Outpost:

InstanceTypes:
- InstanceType: c5.xlarge
- InstanceType: c5.4xlarge
- InstanceType: r5.2xlarge
- InstanceType: r5.4xlarge

With knowledge of the instance types and sizes installed on your Outpost, you can now determine if any of these are available. The following AWS CLI command – one for each of the preceding instance types – lists the number of each instance type and size available for use. For example:

aws cloudwatch get-metric-statistics \
--namespace AWS/Outposts \
--metric-name AvailableInstanceType_Count \
--statistics Average --period 3600 \
--start-time $(date -u -Iminutes -d '-1hour') \
--end-time $(date -u -Iminutes) \
--dimensions \
Name=OutpostId,Value=op-abcdefgh123456789 \
Name=InstanceType,Value=c5.xlarge

This command returns:

Datapoints:
- Average: 2.0
  Timestamp: '2024-04-10T10:39:00+00:00'
  Unit: Count
Label: AvailableInstanceType_Count

The output indicates that there are (on average) two c5.xlarge instances available on this Outpost in the specified time period (1 hour). The same steps for the other instance type suggest that there are also two c5.4xlarge, two r5.2xlarge, and no r5.4xlarge available.

Next, consider the number of VPCs to be connected to the firewall and determine if the instances available support the required number of ENIs.

The firewall requires an ENI in its own VPC, in the Exposed VPC, and one for each additional VPC. In this post, because there is a VPC for IT and for OT, you need an EC2 instance that supports four interfaces in total:

To determine the number of supported interfaces for each available instance type and size, let’s use the AWS CLI:

aws ec2 describe-instance-types \
--instance-types c5.xlarge c5.4xlarge r5.2xlarge \
--query 'InstanceTypes[].[InstanceType,NetworkInfo.NetworkCards]'

This returns:

- - r5.2xlarge
  - - BaselineBandwidthInGbps: 2.5
      MaximumNetworkInterfaces: 4
      NetworkCardIndex: 0
      NetworkPerformance: Up to 10 Gigabit
      PeakBandwidthInGbps: 10.0
- - c5.xlarge
  - - BaselineBandwidthInGbps: 1.25
      MaximumNetworkInterfaces: 4
      NetworkCardIndex: 0
      NetworkPerformance: Up to 10 Gigabit
      PeakBandwidthInGbps: 10.0
- - c5.4xlarge
  - - BaselineBandwidthInGbps: 5.0
      MaximumNetworkInterfaces: 8
      NetworkCardIndex: 0
      NetworkPerformance: Up to 10 Gigabit
      PeakBandwidthInGbps: 10.0

The output suggests that the three available EC2 instances (r5.2xlarge, c5.xlarge and c5.4xlarge) can support four network interfaces. The output also suggests that the c5.4xlarge instance, for example, supports up to 8 network interfaces and a maximum bandwidth of 10Gb/s. This helps you plan for the potential growth in network requirements.

Attaching remote ENIs to the firewall instance

With the firewall instance deployed in the firewall VPC, the next step is to attach the remote ENIs created previously in the Exposed, OT, and IT subnets. Using the firewall instance ID and the Network Interface IDs for each of the remote ENIs, you can create the Multi-VPC Attached ENIs to connect the firewall to the other VPCs.  Each attached interface needs a unique device-index greater than ‘0’ which is the primary instance interface.

For example, to connect the Exposed VPC ENI:

aws ec2 attach-network-interface --device-index 1 \
--instance-id i-0e47e6eb9873d1234 \
--network-interface-id eni-012a3b4cd5efghijk \
--region us-west-2

Attach the OT and IT ENIs while incrementing the device-index and using the respective unique ENI IDs:

aws ec2 attach-network-interface --device-index 2 \
--instance-id i-0e47e6eb9873d1234 \
--network-interface-id eni-0bbe1543fb0bdabff \
--region us-west-2
aws ec2 attach-network-interface --device-index 3 \
--instance-id i-0e47e6eb9873d1234 \
--network-interface-id eni-0bbe1a123b0bdabde \
--region us-west-2

After attaching each remote ENI, the firewall instance now has an interface and IP address in each VPC used in this example architecture:

ubuntu@firewall:~$ ip address

ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    inet 10.240.4.10/24 metric 100 brd 10.240.4.255 scope global dynamic ens5

ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    inet 10.242.0.50/24 metric 100 brd 10.242.0.255 scope global dynamic ens6

ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    inet 10.244.76.51/16 metric 100 brd 10.244.255.255 scope global dynamic ens7

ens11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    inet 172.16.2.7/24 metric 100 brd 172.16.2.255 scope global dynamic ens11

Updating the VPC/subnet route tables

You can now add the routes needed to allow traffic to be inspected to flow through the firewall.

For example, the OT subnet (10.242.0.0/24) uses a route table with the ID rtb- abcdefgh123456789. To send the traffic through the firewall, you need to add a default route with the target being the ENI (eni-07957a9f294fdbf5d) that is now attached to the firewall:

aws ec2 create-route --route-table-id rtb-abcdefgh123456789 \
--destination-cidr-block 0.0.0.0/0 \
--network-interface-id eni-07957a9f294fdbf5d

You can follow the same process is used to add a default route to the IT VPC/subnet.

With routing established from the IT and OT VPCs to the firewall, you need to make sure that the firewall uses the Exposed VPC to route traffic toward the on-premises network 192.168.30.0/24. This is done by adding a route within the firewall OS using the VPC gateway as a next hop.

The ENI attached to the firewall from the Exposed VPC is in subnet 172.16.2.0/28, and the gateway used by this subnet is, by Amazon Virtual Private Cloud (VPC) convention, the first address in the subnet – 172.16.2.1. This is used when updating the firewall OS route table:

sudo ip route add 192.168.30.0/24 via 172.16.2.1

You can now confirm that the firewall OS has routes to each attached subnet and to the on-premises subnet:

ubuntu@firewall:~$ ip route
default via 10.240.4.1 dev ens5 proto dhcp src 10.240.4.10 metric 100
10.240.0.2 via 10.240.4.1 dev ens5 proto dhcp src 10.240.4.10 metric 100
10.240.4.0/24 dev ens5 proto kernel scope link src 10.240.4.10 metric 100
10.240.4.1 dev ens5 proto dhcp scope link src 10.240.4.10 metric 100
10.242.0.0/24 dev ens6 proto kernel scope link src 10.242.0.50 metric 100
10.242.0.2 dev ens6 proto dhcp scope link src 10.242.0.50 metric 100
10.244.0.0/16 dev ens7 proto kernel scope link src 10.244.76.51 metric 100
10.244.0.2 dev ens7 proto dhcp scope link src 10.244.76.51 metric 100
172.16.2.0/24 dev ens11 proto kernel scope link src 172.16.2.7 metric 100
172.16.2.2 dev ens11 proto dhcp scope link src 172.16.2.7 metric 100
192.168.30.0/24 via 172.16.2.1 dev ens11

The final step in establishing end-to-end routing is to make sure that the LGW route table contains static routes for the firewall, IT, and OT VPCs. These routes target the ENIs used by the firewall in the Exposed VPC.

After gathering the LGW Route Table ID and the firewall’s Exposed ENI ID used by the firewall, you can now add routes toward the firewall VPC:

aws ec2 create-local-gateway-route \
    --local-gateway-route-table-id lgw-rtb-abcdefgh123456789 \
    --network-interface-id eni-0a2e4f68f323022c3 \
    --destination-cidr-block 10.240.0.0/16

Repeat this command for the OT and IT VPC CIDRs – 10.242.0.0/16 and 10.244.0.0/16, respectively.

You can query the LGW route table to make sure that each of the static routes was inserted:

aws ec2 search-local-gateway-routes \
    --local-gateway-route-table-id lgw-rtb-abcdefgh123456789 \
    --filters "Name=type,Values=static"

This returns:

Routes:

- DestinationCidrBlock: 10.240.0.0/16
  LocalGatewayRouteTableId: lgw-rtb-abcdefgh123456789
  NetworkInterfaceId: eni-0a2e4f68f323022c3
  State: active
  Type: static

- DestinationCidrBlock: 10.242.0.0/16
  LocalGatewayRouteTableId: lgw-rtb-abcdefgh123456789
  NetworkInterfaceId: eni-0a2e4f68f323022c3
  State: active
  Type: static

- DestinationCidrBlock: 10.244.0.0/16
  LocalGatewayRouteTableId: lgw-rtb-abcdefgh123456789
  NetworkInterfaceId: eni-0a2e4f68f323022c3
  State: active
  Type: static

With the addition of these static routes the LGW begins to advertise reachability to the firewall, OT, and IT Classless Inter-Domain Routing (CIDR) blocks over the BGP neighborship. The CIDR for the Exposed VPC is already advertised because it is associated directly to the LGW.

The firewall now has full visibility of the traffic and can apply the monitoring, inspection, and security profiles defined by your organization.

Other considerations

  • It is important to follow the best practices specified by the Firewall Appliance Partner to fully secure the appliance. In the example architecture, access to the firewall console is restricted to AWS Session Manager.
  • The commands used previously to create/update the Outpost/LGW route tables need an account with full privileges to administer the Outpost.

Fault tolerance

As a crucial component of the infrastructure, the firewall instance needs a mechanism for automatic recovery from failures. One effective approach is to deploy the firewall instances within an Auto Scaling group, which can automatically replace unhealthy instances with new, healthy ones. In addition, using host or rack level spread placement group makes sure that your instances are deployed on distinct underlying hardware. This enables high availability and minimizes downtime. Furthermore, this approach based on Auto Scaling can be implemented regardless of the specific third-party product used.

To ensure a seamless transition when Auto Scaling replaces an unhealthy firewall instance, it is essential that the multi-VPC ENIs responsible for receiving and forwarding traffic are automatically attached to the new instance. When re-using the same multi-VPC ENIs, make sure that no changes are required in the subnets and LGW route tables.

To re-attach the same multi-VPC ENIs to the new instance, you can do this using Auto Scaling lifecycle hooks, with which you can pause the instance replacement process and perform custom actions.

After re-attaching the multi-VPC ENIs to the instance, the last step is to restore the configuration of the firewall from a backup.

Conclusion

In this post, you have learned how to implement on-premises to VPC and VPC-to-VPC inline traffic inspection on Outposts rack with a centralized firewall deployment. This architecture requires a VPC for the firewall instance itself, an Exposed VPC connecting to your on-premises network, and one or more VPCs for your workloads running on the Outpost. You can either use a basic Linux instance as a router, or choose from the advanced AWS Partner solutions in the Network Security section of the AWS Marketplace and follow the respective guidance on firewall instance selection. With multi-VPC ENI attachments, you can create network traffic routing between VPCs and forward traffic to the centralized firewall for inspection. In addition, you can use Auto Scaling groups, spread placement groups, and Auto Scaling lifecycle hooks to enable high availability and fault tolerance for your firewall instance.

If you want to learn more about network security on AWS, visit: Network Security on AWS.

Extending local traffic management load balancing to Layer 4 with Spectrum

Post Syndicated from Chris Ward original https://blog.cloudflare.com/extending-local-traffic-management-load-balancing-to-layer-4-with-spectrum


In 2023, Cloudflare introduced a new load balancing solution, supporting Local Traffic Management (LTM). This gives organizations a way to balance HTTP(S) traffic between private or internal servers within a region-specific data center. Today, we are thrilled to be able to extend those same LTM capabilities to non-HTTP(S) traffic. This new feature is enabled by the integration of Cloudflare Spectrum, Cloudflare Tunnels, and Cloudflare load balancers and is available to enterprise customers. Our customers can now use Cloudflare load balancers for all TCP and UDP traffic destined for private IP addresses, eliminating the need for expensive on-premise load balancers.

A quick primer

In this blog post, we will be referring to load balancers at either layer 4 or layer 7. This is, of course, referring to layers of the OSI model but more specifically, the ingress path that is being used to reach the load balancer. Layer 7, also known as the Application Layer, is where the HTTP(S) protocol exists. Cloudflare is well known for our layer 7 capabilities, which are built around speeding up and protecting websites which run over HTTP(S). When we refer to layer 7 load balancers, we are referring to HTTP(S)-based services. Our layer 7 stack allows Cloudflare to apply services like CDN, WAF, Bot Management, DDoS protection, and more to a customer’s website or application to improve performance, availability, and security.

Layer 4 load balancers operate at a lower level of the OSI model, called the Transport Layer, which means they can be used to support a much broader set of services and protocols. At Cloudflare, our public layer 4 load balancers are enabled by a Cloudflare product called Spectrum. Spectrum works as a layer 4 reverse proxy. This places Cloudflare in front of any DDoS attacks that may be launched against Spectrum-proxied services, and by using Spectrum in front of your application, your private origin IP address is concealed, which also prevents bad actors from discovering and attacking your origin’s IP address directly.

Services that use TCP or UDP for transport can leverage Spectrum with a Cloudflare load balancer. Layer 4 load balancing allows us to support other application layer protocols such as SSH, FTP, NTP, and SMTP since they operate over TCP and UDP. Given the breadth of services and protocols this represents, the treatment provided is more generalized. Cloudflare Spectrum supports features such as TLS/SSL offloading, DDoS protection, Argo Smart Routing, and session persistence with our layer 4 load balancers.

Cloudflare’s current load balancing capabilities

Before we dig into the new features we are announcing, it’s important to understand what Cloudflare load balancing supports today and the challenges our customers face with regard to their load balancing needs.

There are three main load balancing traffic flows that Cloudflare supports today:

  1. Internet-facing load balancers connecting to publicly accessible origins operating at layer 7, which supports HTTP(S)
  2. Internet-facing load balancers connecting to publicly accessible origins operating at layer 4 (Spectrum), which supports all TCP-based and UDP-based services such as SSH, FTP, NTP, SMTP, etc.
  3. Publicly accessible load balancers connecting to private origins operating at layer 7 HTTP(S) over Cloudflare Tunnels

One of the biggest advantages Cloudflare’s load balancing solutions offer our customers is that there is no hardware to purchase or maintain. Hardware-based load balancers are expensive to purchase, license, operate, and upgrade. “Need more bandwidth? Just buy and install this additional module.” “Need more features? Just buy and install this new license.” “Oh, your hardware load balancer is End-of-Life? Just purchase an entire new kit which we will EOL in a few years!” The upgrade or refresh cycle on a fully integrated LTM load balancer setup can take years and, by the time you finish the planning, implementation, and cutover, it might actually be time to start planning the next refresh.

Cloudflare eliminates all these concerns and lets you focus on innovation and growth. Your load balancers exist in every Cloudflare data center across the globe, in over 300 cities, with virtually unlimited scale and capacity. You never need to worry about bandwidth constraints, deployment locations, extra hardware modules, downtime, upgrades, or maintenance windows ever again. With Cloudflare’s global Anycast network, every customer connects to a nearby Cloudflare data center and load balancer, where relevant policies, rules, and steering are applied.

Load balancing more than websites with Cloudflare Spectrum

Today, we are excited to announce that Cloudflare Spectrum can now support load balancing traffic to private networks. The addition of private IP origin support for Cloudflare load balancers is very powerful and that’s why we are extending that support to load balancing with Cloudflare Spectrum as well. This means that any set of private or internal applications that use TCP or UDP can now be locally load balanced via Cloudflare. These services will also benefit from Spectrum’s layer 3/4 DDoS protection and can leverage other features like session persistence without compromising security. So while the ingress to these load balancers is public, the origins to which they distribute traffic can all be private, inaccessible from the public Internet.

Ordinarily, load balancing to private networks would require expensive on-premise hardware or costly direct physical connections to cloud providers. But, by using Spectrum as the ingress path for TCP and UDP load balancing, customers can keep their origins completely protected and unreachable from the Internet and allow access exclusively through their Cloudflare load balancer – no expensive hardware required. Customers no longer need to manage complex ACLs or security settings to make sure only certain source IP addresses are connecting to the origins. These private origins can be hosted in private data centers, a public cloud, a private cloud, or on-premise.

How we enabled Spectrum to support private networks

All of our changes to create this feature center around integrations with Apollo, the unifying service created by the Cloudflare Zero Trust team. You can read their previous blog post on the Oxy framework for more details on how Zero Trust handles and routes traffic. Apollo accepts incoming traffic from supported on-ramps, applies Zero Trust logic as configured by the customer, and then routes the traffic to egress via supported off-ramps. For example, Apollo enables clients connected securely using Cloudflare’s WARP client to communicate over Cloudflare Tunnels with private origins in a customer’s data center. Now, Apollo is being extended to do more.

When a user creates a load balanced Spectrum app, they choose a hostname and port, and select a Cloudflare load balancer as their origin. This allocates a hostname which will resolve to an IP address where Spectrum will listen for incoming traffic on the customer-configured port. Spectrum makes a call to Cloudflare’s internal load balancing service, Director, which responds with the appropriate endpoint, to which Spectrum will proxy the connection. Previously, load balanced Spectrum apps only supported publicly addressable origins. Now, if the response from Director indicates that the traffic is destined for a private origin, Spectrum passes the private origin’s IP address and virtual network ID to Apollo, which then proxies the traffic to the customer’s private origin.

In short, new integrations between our Spectrum service and Apollo and between Apollo and Director have allowed us to expand our load balancing offerings not only to layer 4, but also enable us to leverage virtual networks to keep load balanced traffic private and off the public Internet. This also sets the stage for integrating load balancing with other traffic on-ramps and off-ramps, such as WARP, in the future. It also opens the door to a number of exciting possibilities like load balancing authenticated device traffic to private networks or even load balancing internal traffic that is never exposed to the public Internet.

Looking to the future

We are excited to be releasing this new load balancing feature which enables Cloudflare Spectrum to reach private IP endpoints. Cloudflare load balancers now support steering any TCP or UDP-based protocols over Cloudflare Tunnels to private IP endpoints, which are otherwise not accessible via the public Internet. You can learn more about how to configure this feature on our load balancing documentation pages.

We are just getting started with our local traffic management load balancing support. There is so much more to come including support for load balancing internal traffic, enhanced layer 4 session affinity, new steering methods, additional traffic ingress methods, and more!

Третата вълна, или как да пием по-добро кафе

Post Syndicated from Йовко Ламбрев original https://www.toest.bg/tretata-vulna-ili-kak-da-piem-po-dobro-kafe/

Третата вълна, или как да пием по-добро кафе

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

Предишните две вълни са от миналия ХХ век. Първата се свързва с превръщането на кафето в глобален продукт чрез масовизиране на производството и консумацията му. По време на тази първа вълна, започнала в началото на века, кофеиновата напитка се разпространява почти навсякъде по света – включително в домовете на хората, за което огромен принос имат и продукти като емблематичната кафеварка на Алфонсо Биалети

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

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

Във фокуса на тази промяна са вече сортовете арабика, чиито зърна обаче продължават да се изпичат до много тъмно, защото се смята, че така кафето се комбинира по-добре с вкуса на млякото. Самите напитки пък често се овкусяват допълнително със сиропи и различни добавки, като карамел и шоколад. В същия исторически промеждутък се появяват и автоматите и вендинг машините, макар че в света на кафето (и напук на технологичните революции) автоматизацията често носи повече вреди, отколкото ползи. 

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

Преди това обаче нека уточним основните понятия и фактология.

Какво

Ботаниката различава повече от 120 растения от рода Coffea, но от плодовете само на няколко от тях човечеството приготвя своето кафе. Така наречените зърна, от които правим любимата си напитка, всъщност са семки в плодчетата на растението. Самите плодчета пък най-често се наричат череши. Ако трябва да бъдем прецизни, според ботаниката нито плодът е череша, нито зърната са зърна… но това са наложилите се популярни названия, и то далеч не само в българския език.

Най-разпространените видове кафе са арабика и робуста, които заемат съответно около 65 и 35% от световното производство.

Най-рано култивираната и най-широко отглеждана разновидност на кафето е арабиката. Тя е спечелила предпочитанието на публиката със своята по-широка палитра от вкусове и аромати, по-изразена сладка и плодова киселинност и по-фино тяло. Съдържанието на захари в арабиката е около 6–9%, докато при робустата е между 3 и 7%. Арабиката, от друга страна, е с почти двойно по-ниско съдържание на кофеин – едва 1,5% спрямо 2,7% при робустата.

Растенията арабика са капризни и предпочитат по-висока надморска височина, като в същото време никак не понасят мразовито време.

Робуста се е наложило като общо название за сортовете на вида Coffea canephora, от които само единият наистина се нарича robusta, но вече май трябва да сме свикнали, че в света на кафето не бива да сме твърде придирчиви за правилната употреба на названията.

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

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

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

Либерика, най-редкият вид Coffea, заема едва 1,5% от световното производство. Тя е с по-ниско съдържание на кофеин дори от арабиката – около 1%, при сходно съдържание на захари. Но тъй като човешкото небце възприема кофеина като силно горчив, това създава усещането, че кафето от либерика е по-сладко. Същевременно либериката е по-близка вкусово до робустата – с плътно, опушено ядково тяло, но пък с отличим флорален и плодов аромат, по-характерен за арабиката.

Къде

Кафе се отглежда в повече от 70 страни по света с преобладаващ тропически климат, дори в две европейски локации – на Азорските острови, които са част от Португалия, и на Канарските острови, разположени съвсем близо до крайбрежието на Мароко, но принадлежащи на Испания. Трите най-големи производители обаче са Бразилия, Виетнам и Колумбия. Заедно те осигуряват над 60% от световната продукция, като само Бразилия отглежда над една трета от кафето, което човечеството консумира всяка година.

Виетнам е най-големият производител на робуста (около 40% от световното производство), но тя се отглежда също в значителен мащаб и в Бразилия, Индонезия, Индия, Уганда и други страни. Най-големите производители на кафе арабика са Бразилия, Колумбия и Етиопия.

Колко и как

В последните години в челната десетка на страните, които консумират най-много кафе на глава от населението, има най-много една държава, която не е в Европа, и най-често тя е Канада, заемаща девето или десето място. На първите позиции обикновено са Финландия, Норвегия, Дания, Холандия.

Средногодишната консумация във Финландия достига до 12 кг на човек, което означава приблизително по 4 чаши дневно. Там кратките почивки за кафе са регламентирани в трудовото законодателство на страната. Често в първата петица попадат и исландците, които даже имат интересно свое название за късо кафе – tíu dropar, което буквално означава десет капки. Следващите позиции обикновено се заемат от Швеция, Швейцария и Белгия. А много често в класацията влизат също Естония и Люксембург – едни от най-малките страни на света, но с много развита мрежа от кафенета и годишна консумация от около 6,5 кг кафе на глава от населението.

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

Известният ресторант Noma в Копенхаген има своя авангардна рецепта, в която са комбинирани три класически техники за тяхното т.нар. Nomaricano. То се приготвя първоначално като много дълго (180 мл) еспресо от скандинавско изпечени зърна арабика, допълнително филтрирано през V60, към което накрая се добавят 120 мл гореща вода, за да се получи балансирано американо с плътен букет от флорални вкусове. Популярното вече по цял свят flat white кафе (макар и продукт на втората вълна) е родено в Австралия. А набиращото популярност през последните няколко години dirty coffee („мръсно кафе“) е с японски произход.

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

На гребена на третата вълна

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

А качеството на едно кафе е свързано в огромна степен с две неща – неговия произход и подходящото му изпичане. 

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

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

Част от single origin кафетата с много високо качество се наричат специални.

След като кафеените плодове са събрани (специалните кафета най-често се берат ръчно), зърната трябва да бъдат извадени и изсушени. Има няколко различни метода за това. След тази обработка се получава т.нар. зелено кафе, което напуска фермата, опаковано в чували. В този си вид кафето е доста твърдо и с изразен тревист вкус и аромат. След изпичането зърната стават крехки и развиват естествените си вкусове и аромати. 

Именно печенето е процесът, който отключва и влияе пряко на вкусовете, ароматите и дори върху кофеиновото съдържание на едно кафе.

Така печенето и пекарите стават следващият най-важен фактор за добрия вкус в чашите ни.

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

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

След три-четири месеца от печенето вече почти няма да има значение дали и колко специално е било едно кафе. 

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

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

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

А по-важно от това дали пиете скъпо екзотично специално кафе, е дали то е прясно изпечено.

Прието е, че едно добро еспресо трябва да бъде извлечено за около 25–30 секунди. Много важна е и постоянната температура на водата, при това съобразена със степента на изпичане на зърната. По-светло изпечените кафета обикновено се приготвят с по-гореща вода (92–96°C) от средно изпечените (88–93°C) или тъмните (85–91°C). Смилането на зърната също се отразява на вкуса в чашата, като конкретно за еспресото е много важно смляното кафе да е еднородно (тоест да няма едновременно фини и по-едри частици), за което е нужна качествена мелачка. 

Прекалената горчивост на напитката обикновено е в резултат на твърде дълго извличане, а киселият вкус е симптом за недостатъчна екстракция. За да променим вкуса на кафето от по-кисел към неутрален или по-горчив, има няколко начина: да увеличим температурата, да мелим по-фино, да ползваме по-тъмно изпечено кафе или да увеличим времето за екстракция. Вече споменахме, че робустата придава горчивост, а арабиката – киселинност. Робустата също осигурява повече от т.нар. каймак в еспресото, особено когато зърната са прясно и тъмно изпечени. Средно и по-светло изпечените зърна запазват повече от палитрата от вкусове, които кафето носи със себе си. Тези нюанси се усещат по-лесно чрез филтърни техники за приготвяне на кафе, като V60 или Chemex.

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

Не просто бизнес, а призвание

Добрата новина е, че третата вълна донесе прясно изпеченото кафе под носа ни. Дори в България, ако живеете в София, Пловдив, Варна, Плевен или Благоевград, е вероятно да имате кафе пекарна в центъра на града, а може би и в квартала си. Ако пък не, може да поръчате прясно изпечено кафе по интернет от почти всички български пекари, както и от много румънски или гръцки, а защо не и от цяла Европа и отвъд океана.

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

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

Преди около десетина години Ангел влага всичките си спестявания в първата си машина за печене на кафе, мотивиран от философията на третата вълна и от мечтата да може да нарече един продукт моето кафе. „На изток казват: „Не е важна целта, а пътят“, споделя той с мен.

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

Питам и двамата колко е трудно в България да превъзпитаваш вкуса на публиката и как преценяват нивото на кафе културата у нас.

Според Ангел „което не е трудно, не е интересно“. Той добавя:

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

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

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

Димо споделя сходни мисли:

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

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

Не мога да не попитам за конкуренцията, особено в съседните ни Румъния и Гърция, където третата вълна се надига с голяма сила. През 2019 г. Богдан Джорджеску, румънски ИТ специалист, който едва пет години по-рано започва да пече кафе вкъщи за себе си, спечели второ място на Световния шампионат по печене на кафе, а днес неговото прясно печено кафе Mabó се предлага в над 30 заведения в Букурещ и в още толкова в други румънски градове. Миналата година друг румънец зае петото място в същия шампионат.

Ангел споделя общото мнение, че съседите ни се развиват по-добре от нас. Но се радва, че продава и на гърци, и на румънци. И добавя:

Генезисът на третата вълна е такъв, че се съсредоточава в местната общност и се търсят локални предпочитания. Тази ограниченост не позволява „избухване“ на международно ниво и спечелване на по-голяма популярност. Защото всички ползваме една и съща техника, в повечето случаи едни и същи сортове и като цяло правим каквото можем с наличния ресурс.

Димо също признава, че конкуренцията в кафе индустрията сред нашите най-близки съседи е доста интензивна. И допълва: 

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

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

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

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

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

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

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

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

How AI Will Change Democracy

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/05/how-ai-will-change-democracy.html

I don’t think it’s an exaggeration to predict that artificial intelligence will affect every aspect of our society. Not by doing new things. But mostly by doing things that are already being done by humans, perfectly competently.

Replacing humans with AIs isn’t necessarily interesting. But when an AI takes over a human task, the task changes.

In particular, there are potential changes over four dimensions: Speed, scale, scope and sophistication. The problem with AIs trading stocks isn’t that they’re better than humans—it’s that they’re faster. But computers are better at chess and Go because they use more sophisticated strategies than humans. We’re worried about AI-controlled social media accounts because they operate on a superhuman scale.

It gets interesting when changes in degree can become changes in kind. High-speed trading is fundamentally different than regular human trading. AIs have invented fundamentally new strategies in the game of Go. Millions of AI-controlled social media accounts could fundamentally change the nature of propaganda.

It’s these sorts of changes and how AI will affect democracy that I want to talk about.

To start, I want to list some of AI’s core competences. First, it is really good as a summarizer. Second, AI is good at explaining things, teaching with infinite patience. Third, and related, AI can persuade. Propaganda is an offshoot of this. Fourth, AI is fundamentally a prediction technology. Predictions about whether turning left or right will get you to your destination faster. Predictions about whether a tumor is cancerous might improve medical diagnoses. Predictions about which word is likely to come next can help compose an email. Fifth, AI can assess. Assessing requires outside context and criteria. AI is less good at assessing, but it’s getting better. Sixth, AI can decide. A decision is a prediction plus an assessment. We are already using AI to make all sorts of decisions.

How these competences translate to actual useful AI systems depends a lot on the details. We don’t know how far AI will go in replicating or replacing human cognitive functions. Or how soon that will happen. In constrained environments it can be easy. AIs already play chess and Go better than humans. Unconstrained environments are harder. There are still significant challenges to fully AI-piloted automobiles. The technologist Jaron Lanier has a nice quote, that AI does best when “human activities have been done many times before, but not in exactly the same way.”

In this talk, I am going to be largely optimistic about the technology. I’m not going to dwell on the details of how the AI systems might work. Much of what I am talking about is still in the future. Science fiction, but not unrealistic science fiction.

Where I am going to be less optimistic—and more realistic—is about the social implications of the technology. Again, I am less interested in how AI will substitute for humans. I’m looking more at the second-order effects of those substitutions: How the underlying systems will change because of changes in speed, scale, scope and sophistication. My goal is to imagine the possibilities. So that we might be prepared for their eventuality.

And as I go through the possibilities, keep in mind a few questions: Will the change distribute or consolidate power? Will it make people more or less personally involved in democracy? What needs to happen before people will trust AI in this context? What could go wrong if a bad actor subverted the AI in this context? And what can we do, as security technologists, to help?

I am thinking about democracy very broadly. Not just representations, or elections. Democracy as a system for distributing decisions evenly across a population. It’s a way of converting individual preferences into group decisions. And that includes bureaucratic decisions.

To that end, I want to discuss five different areas where AI will affect democracy: Politics, lawmaking, administration, the legal system and, finally, citizens themselves.

I: AI-assisted politicians

I’ve already said that AIs are good at persuasion. Politicians will make use of that. Pretty much everyone talks about AI propaganda. Politicians will make use of that, too. But let’s talk about how this might go well.

In the past, candidates would write books and give speeches to connect with voters. In the future, candidates will also use personalized chatbots to directly engage with voters on a variety of issues. AI can also help fundraise. I don’t have to explain the persuasive power of individually crafted appeals. AI can conduct polls. There’s some really interesting work into having large language models assume different personas and answer questions from their points of view. Unlike people, AIs are always available, will answer thousands of questions without getting tired or bored and are more reliable. This won’t replace polls, but it can augment them. AI can assist human campaign managers by coordinating campaign workers, creating talking points, doing media outreach and assisting get-out-the-vote efforts. These are all things that humans already do. So there’s no real news there.

The changes are largely in scale. AIs can engage with voters, conduct polls and fundraise at a scale that humans cannot—for all sizes of elections. They can also assist in lobbying strategies. AIs could also potentially develop more sophisticated campaign and political strategies than humans can. I expect an arms race as politicians start using these sorts of tools. And we don’t know if the tools will favor one political ideology over another.

More interestingly, future politicians will largely be AI-driven. I don’t mean that AI will replace humans as politicians. Absent a major cultural shift—and some serious changes in the law—that won’t happen. But as AI starts to look and feel more human, our human politicians will start to look and feel more like AI. I think we will be OK with it, because it’s a path we’ve been walking down for a long time. Any major politician today is just the public face of a complex socio-technical system. When the president makes a speech, we all know that they didn’t write it. When a legislator sends out a campaign email, we know that they didn’t write that either—even if they signed it. And when we get a holiday card from any of these people, we know that it was signed by an autopen. Those things are so much a part of politics today that we don’t even think about it. In the future, we’ll accept that almost all communications from our leaders will be written by AI. We’ll accept that they use AI tools for making political and policy decisions. And for planning their campaigns. And for everything else they do. None of this is necessarily bad. But it does change the nature of politics and politicians—just like television and the internet did.

II: AI-assisted legislators

AIs are already good at summarization. This can be applied to listening to constituents:  summarizing letters, comments and making sense of constituent inputs. Public meetings might be summarized. Here the scale of the problem is already overwhelming, and AI can make a big difference. Beyond summarizing, AI can highlight interesting arguments or detect bulk letter-writing campaigns. They can aid in political negotiating.

AIs can also write laws. In November 2023, Porto Alegre, Brazil became the first city to enact a law that was entirely written by AI. It had to do with water meters. One of the councilmen prompted ChatGPT, and it produced a complete bill. He submitted it to the legislature without telling anyone who wrote it. And the humans passed it without any changes.

A law is just a piece of generated text that a government agrees to adopt. And as with every other profession, policymakers will turn to AI to help them draft and revise text. Also, AI can take human-written laws and figure out what they actually mean. Lots of laws are recursive, referencing paragraphs and words of other laws. AIs are already good at making sense of all that.

This means that AI will be good at finding legal loopholes—or at creating legal loopholes. I wrote about this in my latest book, A Hacker’s Mind. Finding loopholes is similar to finding vulnerabilities in software. There’s also a concept called “micro-legislation.” That’s the smallest unit of law that makes a difference to someone. It could be a word or a punctuation mark. AIs will be good at inserting micro-legislation into larger bills. More positively, AI can help figure out unintended consequences of a policy change—by simulating how the change interacts with all the other laws and with human behavior.

AI can also write more complex law than humans can. Right now, laws tend to be general. With details to be worked out by a government agency. AI can allow legislators to propose, and then vote on, all of those details. That will change the balance of power between the legislative and the executive branches of government. This is less of an issue when the same party controls the executive and the legislative branches. It is a big deal when those branches of government are in the hands of different parties. The worry is that AI will give the most powerful groups more tools for propagating their interests.

AI can write laws that are impossible for humans to understand. There are two kinds of laws: specific laws, like speed limits, and laws that require judgment, like those that address reckless driving. Imagine that we train an AI on lots of street camera footage to recognize reckless driving and that it gets better than humans at identifying the sort of behavior that tends to result in accidents. And because it has real-time access to cameras everywhere, it can spot it … everywhere. The AI won’t be able to explain its criteria: It would be a black-box neural net. But we could pass a law defining reckless driving by what that AI says. It would be a law that no human could ever understand. This could happen in all sorts of areas where judgment is part of defining what is illegal. We could delegate many things to the AI because of speed and scale. Market manipulation. Medical malpractice. False advertising. I don’t know if humans will accept this.

III: AI-assisted bureaucracy

Generative AI is already good at a whole lot of administrative paperwork tasks. It will only get better. I want to focus on a few places where it will make a big difference. It could aid in benefits administration—figuring out who is eligible for what. Humans do this today, but there is often a backlog because there aren’t enough humans. It could audit contracts. It could operate at scale, auditing all human-negotiated government contracts. It could aid in contracts negotiation. The government buys a lot of things and has all sorts of complicated rules. AI could help government contractors navigate those rules.

More generally, it could aid in negotiations of all kinds. Think of it as a strategic adviser. This is no different than a human but could result in more complex negotiations. Human negotiations generally center around only a few issues. Mostly because that’s what humans can keep in mind. AI versus AI negotiations could potentially involve thousands of variables simultaneously. Imagine we are using an AI to aid in some international trade negotiation and it suggests a complex strategy that is beyond human understanding. Will we blindly follow the AI? Will we be more willing to do so once we have some history with its accuracy?

And one last bureaucratic possibility: Could AI come up with better institutional designs than we have today? And would we implement them?

IV: AI-assisted legal system

When referring to an AI-assisted legal system, I mean this very broadly—both lawyering and judging and all the things surrounding those activities.

AIs can be lawyers. Early attempts at having AIs write legal briefs didn’t go well. But this is already changing as the systems get more accurate. Chatbots are now able to properly cite their sources and minimize errors. Future AIs will be much better at writing legalese, drastically reducing the cost of legal counsel. And there’s every indication that it will be able to do much of the routine work that lawyers do. So let’s talk about what this means.

Most obviously, it reduces the cost of legal advice and representation, giving it to people who currently can’t afford it. An AI public defender is going to be a lot better than an overworked not very good human public defender. But if we assume that human-plus-AI beats AI-only, then the rich get the combination, and the poor are stuck with just the AI.

It also will result in more sophisticated legal arguments. AI’s ability to search all of the law for precedents to bolster a case will be transformative.

AI will also change the meaning of a lawsuit. Right now, suing someone acts as a strong social signal because of the cost. If the cost drops to free, that signal will be lost. And orders of magnitude more lawsuits will be filed, which will overwhelm the court system.

Another effect could be gutting the profession. Lawyering is based on apprenticeship. But if most of the apprentice slots are filled by AIs, where do newly minted attorneys go to get training? And then where do the top human lawyers come from? This might not happen. AI-assisted lawyers might result in more human lawyering. We don’t know yet.

AI can help enforce the law. In a sense, this is nothing new. Automated systems already act as law enforcement—think speed trap cameras and Breathalyzers. But AI can take this kind of thing much further, like automatically identifying people who cheat on tax returns, identifying fraud on government service applications and watching all of the traffic cameras and issuing citations.

Again, the AI is performing a task for which we don’t have enough humans. And doing it faster, and at scale. This has the obvious problem of false positives. Which could be hard to contest if the courts believe that the computer is always right. This is a thing today: If a Breathalyzer says you’re drunk, it can be hard to contest the software in court. And also the problem of bias, of course: AI law enforcers may be more and less equitable than their human predecessors.

But most importantly, AI changes our relationship with the law. Everyone commits driving violations all the time. If we had a system of automatic enforcement, the way we all drive would change—significantly. Not everyone wants this future. Lots of people don’t want to fund the IRS, even though catching tax cheats is incredibly profitable for the government. And there are legitimate concerns as to whether this would be applied equitably.

AI can help enforce regulations. We have no shortage of rules and regulations. What we have is a shortage of time, resources and willpower to enforce them, which means that lots of companies know that they can ignore regulations with impunity. AI can change this by decoupling the ability to enforce rules from the resources necessary to do it. This makes enforcement more scalable and efficient. Imagine putting cameras in every slaughterhouse in the country looking for animal welfare violations or fielding an AI in every warehouse camera looking for labor violations. That could create an enormous shift in the balance of power between government and corporations—which means that it will be strongly resisted by corporate power.

AIs can provide expert opinions in court. Imagine an AI trained on millions of traffic accidents, including video footage, telemetry from cars and previous court cases. The AI could provide the court with a reconstruction of the accident along with an assignment of fault. AI could do this in a lot of cases where there aren’t enough human experts to analyze the data—and would do it better, because it would have more experience.

AIs can also perform judging tasks, weighing evidence and making decisions, probably not in actual courtrooms, at least not anytime soon, but in other contexts. There are many areas of government where we don’t have enough adjudicators. Automated adjudication has the potential to offer everyone immediate justice. Maybe the AI does the first level of adjudication and humans handle appeals. Probably the first place we’ll see this is in contracts. Instead of the parties agreeing to binding arbitration to resolve disputes, they’ll agree to binding arbitration by AI. This would significantly decrease cost of arbitration. Which would probably significantly increase the number of disputes.

So, let’s imagine a world where dispute resolution is both cheap and fast. If you and I are business partners, and we have a disagreement, we can get a ruling in minutes. And we can do it as many times as we want—multiple times a day, even. Will we lose the ability to disagree and then resolve our disagreements on our own? Or will this make it easier for us to be in a partnership and trust each other?

V: AI-assisted citizens

AI can help people understand political issues by explaining them. We can imagine both partisan and nonpartisan chatbots. AI can also provide political analysis and commentary. And it can do this at every scale. Including for local elections that simply aren’t important enough to attract human journalists. There is a lot of research going on right now on AI as moderator, facilitator, and consensus builder. Human moderators are still better, but we don’t have enough human moderators. And AI will improve over time. AI can moderate at scale, giving the capability to every decision-making group—or chatroom—or local government meeting.

AI can act as a government watchdog. Right now, much local government effectively happens in secret because there are no local journalists covering public meetings. AI can change that, providing summaries and flagging changes in position.

AIs can help people navigate bureaucracies by filling out forms, applying for services and contesting bureaucratic actions. This would help people get the services they deserve, especially disadvantaged people who have difficulty navigating these systems. Again, this is a task that we don’t have enough qualified humans to perform. It sounds good, but not everyone wants this. Administrative burdens can be deliberate.

Finally, AI can eliminate the need for politicians. This one is further out there, but bear with me. Already there is research showing AI can extrapolate our political preferences. An AI personal assistant trained on and continuously attuned to your political preferences could advise you, including what to support and who to vote for. It could possibly even vote on your behalf or, more interestingly, act as your personal representative.

This is where it gets interesting. Our system of representative democracy empowers elected officials to stand in for our collective preferences. But that has obvious problems. Representatives are necessary because people don’t pay attention to politics. And even if they did, there isn’t enough room in the debate hall for everyone to fit. So we need to pick one of us to pass laws in our name. But that selection process is incredibly inefficient. We have complex policy wants and beliefs and can make complex trade-offs. The space of possible policy outcomes is equally complex. But we can’t directly debate the policies. We can only choose one of two—or maybe a few more—candidates to do that for us. This has been called democracy’s “lossy bottleneck.” AI can change this. We can imagine a personal AI directly participating in policy debates on our behalf along with millions of other personal AIs and coming to a consensus on policy.

More near term, AIs can result in more ballot initiatives. Instead of five or six, there might be five or six hundred, as long as the AI can reliably advise people on how to vote. It’s hard to know whether this is a good thing. I don’t think we want people to become politically passive because the AI is taking care of it. But it could result in more legislation that the majority actually wants.

Where will AI take us?

That’s my list. Again, watch where changes of degree result in changes in kind. The sophistication of AI lawmaking will mean more detailed laws, which will change the balance of power between the executive and the legislative branches. The scale of AI lawyering means that litigation becomes affordable to everyone, which will mean an explosion in the amount of litigation. The speed of AI adjudication means that contract disputes will get resolved much faster, which will change the nature of settlements. The scope of AI enforcement means that some laws will become impossible to evade, which will change how the rich and powerful think about them.

I think this is all coming. The time frame is hazy, but the technology is moving in these directions.

All of these applications need security of one form or another. Can we provide confidentiality, integrity and availability where it is needed? AIs are just computers. As such, they have all the security problems regular computers have—plus the new security risks stemming from AI and the way it is trained, deployed and used. Like everything else in security, it depends on the details.

First, the incentives matter. In some cases, the user of the AI wants it to be both secure and accurate. In some cases, the user of the AI wants to subvert the system. Think about prompt injection attacks. In most cases, the owners of the AIs aren’t the users of the AI. As happened with search engines and social media, surveillance and advertising are likely to become the AI’s business model. And in some cases, what the user of the AI wants is at odds with what society wants.

Second, the risks matter. The cost of getting things wrong depends a lot on the application. If a candidate’s chatbot suggests a ridiculous policy, that’s easily corrected. If an AI is helping someone fill out their immigration paperwork, a mistake can get them deported. We need to understand the rate of AI mistakes versus the rate of human mistakes—and also realize that AI mistakes are viewed differently than human mistakes. There are also different types of mistakes: false positives versus false negatives. But also, AI systems can make different kinds of mistakes than humans do—and that’s important. In every case, the systems need to be able to correct mistakes, especially in the context of democracy.

Many of the applications are in adversarial environments. If two countries are using AI to assist in trade negotiations, they are both going to try to hack each other’s AIs. This will include attacks against the AI models but also conventional attacks against the computers and networks that are running the AIs. They’re going to want to subvert, eavesdrop on or disrupt the other’s AI.

Some AI applications will need to run in secure environments. Large language models work best when they have access to everything, in order to train. That goes against traditional classification rules about compartmentalization.

Fourth, power matters. AI is a technology that fundamentally magnifies power of the humans who use it, but not equally across users or applications. Can we build systems that reduce power imbalances rather than increase them? Think of the privacy versus surveillance debate in the context of AI.

And similarly, equity matters. Human agency matters.

And finally, trust matters. Whether or not to trust an AI is less about the AI and more about the application. Some of these AI applications are individual. Some of these applications are societal. Whether something like “fairness” matters depends on this. And there are many competing definitions of fairness that depend on the details of the system and the application. It’s the same with transparency. The need for it depends on the application and the incentives. Democratic applications are likely to require more transparency than corporate ones and probably AI models that are not owned and run by global tech monopolies.

All of these security issues are bigger than AI or democracy. Like all of our security experience, applying it to these new systems will require some new thinking.

AI will be one of humanity’s most important inventions. That’s probably true. What we don’t know is if this is the moment we are inventing it. Or if today’s systems are yet more over-hyped technologies. But these are security conversations we are going to need to have eventually.

AI is fundamentally a power-enhancing technology. We need to ensure that it distributes power and doesn’t further concentrate it.

AI is coming for democracy. Whether the changes are a net positive or negative depends on us. Let’s help tilt things to the positive.

This essay is adapted from a keynote speech delivered at the RSA Conference in San Francisco on May 7, 2024. It originally appeared in Cyberscoop.

 

На второ четене: „Красноречието на сардината“

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

„Красноречието на сардината“ от Бил Франсоа

На второ четене: „Красноречието на сардината“

превод от френски Наташа Колевска-Куртева, изд. „Жанет 45“, 2022

Когато за пръв път мернах прекрасния сборник с есета „Красноречието на сардината“, моментално се сетих за „Елегантността на таралежа“ на Мюриел Барбери и двете книги наистина имат общи неща – освен подобието в заглавията. Франсоа смесва изискан и хуманен хумор с личния си морски опит, ерудицията и научното си познание – с любовта към пословичните дълбини под вълнитe.

Едва ли в много други страни саундтракът към „Аризонска мечта“ – наистина невероятна среща между Брегович и Иги Поп, е имал толкова радушен или даже култов прием, колкото в България. В една от песните Иги Поп казва в речитатива си, че

рибата не мисли / рибата е безмълвна, без изражение / рибата не мисли, защото тя знае всичко.

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

Рибата говори, просто ние не владеем нейния език.

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

През годините, а и до ден днешен не съм любител на морските почивки. Не съм привърженик на печенето на слънце. Не мога и да плувам. Но същевременно името на един от най-добрите ми приятели на тази земя означава буквално „морски“. А чувството, което ме обзема, когато гледам морето, усещам вятъра и слушам вълните, е наистина „океанско“, както го нарича Ромен Ролан в писмо до Фройд. Впоследствие Фройд, както често прави, развива своя собствена и своеобразна теория. Ролан има предвид вътрешното усещане за вечност, което те обзема, когато се усещаш част от целия външен свят. Когато се усещаш като част от цяло, като вода във водата, като песъчинка от плажа, който е част от големия пясъчен часовник, чието съществуване и изтичане нямаме капацитета да осъзнаем.

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

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

На второ четене: „Красноречието на сардината“

Франсоа е колкото информативен, толкова и ненатрапчиво поетичен, когато смесва и натрупва впечатленията си за песента на китовете, за гостуванията си на средиземноморските риби меч, или как брои албатросите и играе със скатове манта. Опияняващо и страшно е да се чете, като разказва за живота в перфектна симбиоза на постоянно застрашения в момента коралов риф. Или за безумната любов на римляните към „гарум“ – соса, който се получава чрез ферментация на хамсия. Или как е измислена изкуствената перла от майстор Жакен, който не искал да създаде за жената на сина си токсичната до този момент алтернатива на истинската перла. Или как Плиний Стари загива, опитвайки се да спаси приятел от Везувий. Или как Франсоа разчита сигналите на делфините, как разбира колко брутално се лови риба тон или какво е изкуството да се доближиш до тюлени. Или как… Историите са наистина много.

Описанията на Франсоа могат да влюбят читателя в подводните жители и да разширят неимоверно представите му. Той разказва как зеленушки и морски каракуди се носят над пяната и скалите. Как

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

Как

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

Или как

лангустите пък се мислят за по-музикални и свирят на цигулка със своите антени,

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

Историята, която ме покърти, е за най-самотния кит на света.

Песента му приличала на тази при финвалите и имала честота 52 херца, която е еквивалентна на най-ниската нота, произвеждана от туба. Това е прекалено висок, пронизителен звук за финвалите, които се свързват на звукова честота от 10 до 35 херца. Затова от десетилетия този кит пее, говори и зове себеподобните си, без да получава отговор. Той се скита самотен в необятната водна шир и само океанографските хидрофони чуват всяка година неговия зов. Никой не знае защо той има толкова странен глас. […] също така никой не знае дали някога е срещал други китове, нито какво може да е почувствал при такава среща, като е виждал другите, без да може да разговаря с тях. Никой не е успял да го види, въпреки че всяка година самотната му миграция може да бъде проследена по звука. За хората самотният кит съществува само чрез своята песен, същата тази, която го изолира от събратята му, тази песен, която той изпраща неуморно с надежда в пустотата на Тихия океан.

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

Такива книги (като „Черноморски упанишад“ на Николай Грозни или като излязлата наскоро „Кратка философия на морето“ на Лоранс Дьовилер) са усилия по посока на усъмняване в превъзходството и нарцисизма на човешкия род и в превръщането му в един по-добър представител на екосистемата на планетата ни. Преди да я досъсипе с ентусиазъм и задоволство от постигнатите резултати.

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

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


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

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

Тайланд под кожата (първа част)

Post Syndicated from Емине Садкъ original https://www.toest.bg/tayland-pod-kozhata-purva-chast/

Тайланд под кожата (първа част)

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

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

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

На популярни места като Чианг Май, Патая, Пукет или островите Фи Пи ще се убедите, че

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

а някои тайландци са готови да ви го продадат на всяка цена. Заради това екзотичността се превръща в безкрайна досада.

Ако обаче не си падате по шоу с вагини, пушещи цигари или изстрелващи топчета за пинг-понг към вас, крокодили на чеверме, скорпиони на клечка и некачествени наркотици, има вероятност улици като „Косан Роад“ и нощните пазари в Бангкок да ви се сторят агресивни и шумни. И все пак – заслужава си да се пуснете по тях, защото само там може да видите как срещу баба, готвеща pad thai (нудъли на тиган със зеленчуци, тофу или месо) танцуват полуголи лейдибойс.

Транссексуалността в Тайланд е толерирана заради будизма –

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

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

е възможно Тайланд да бъде първата държава в Югоизточна Азия, която ще легализира еднополовите бракове.

Това беше и първата страна в Югоизточна Азия, легализирала марихуаната. В началото на пролетта на 2022 г. с публикация в социалните мрежи министърът на здравеопазването Анутин Чарнвиракул обяви, че от 9 юни същата година марихуаната ще бъде достъпна за всички. Мотивите на правителството гласяха, че с това престъпността ще намалее, а земеделските региони в провинцията ще имат възможност да се развиват. Друга причина за легализацията на марихуаната беше, че пандемията нанесе огромни щети върху икономиката на страната и обръщането в тази посока би поощрило по-бързото завръщане на туристите. И привличането на нови.

По данни на Световната банка туризмът съставлява 20% от БВП на страната.

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

След края на пандемията и закрепването на туристическия сектор, както и със смяната на правителството, се говори, че марихуаната в Тайланд отново ще бъде криминализирана, което ще доведе до затварянето на безброй частни магазини за марихуана и кофишопове, както и до закриването на международни компании, инвестирали милиони – например Royal Queen Seeds, най-голямата банка за семена в света.

Туризмът е жизненоважен сегмент от икономиката на страната и след като помага за стабилизирането ѝ през 1970–1980 г., когато САЩ и други инвеститори се оттеглят заради петролната криза, става основен фокус в политиките за развитие на страната. Разбира се, всичко това не би било възможно без красотата на Тайланд и гостоприемството на тайландците, които превръщат това място в достъпен рай за всеки турист. В зависимост от нуждите ви – хостел за шест евро или луксозна вила за хиляда долара на вечер – там има всичко. И всички биват третирани еднакво – с уважение, внимание и търпение. Както и с безкрайни поздрави и благодарности.

Когато поздравяват или благодарят, тайландците използват т.нар. wai – поклон напред със събрани ръце, подобно на намасте. Намирам за очарователна комуникацията, която включва и тялото. Поздравът Sawasdee (sah-waah-dee) и благодарностите Khwaap khun се превръщат в танц между двама души, водещ до кратко съвместно смирение.

Тайланд под кожата (първа част)

И ако искате хората да разберат, че сте били в Тайланд, без да казвате, че сте били в Тайланд, може да продължите да отговаряте с khaap khun след всяко изречение, когато се приберете. Или да си направите свещена татуировка с бамбукова пръчка. Традиционната татуировка – Sak Yant, се смята за свещена, а татуистите – Sak Yant Ajarns, са с ранг на духовни учители. По време на ритуала на татуиране се освещава всяка капка мастило, която носи късмет, любов, закрила и други благоденствия за татуирания. Но и без да преминете през мастиления ритуал,

Тайланд ще остане под кожата ви и една от причините за това, разбира се, е храната.

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

Вместо краве мляко в традиционната тайска кухня се използва кокосово като един от основните компоненти, както и кафява захар, соев или стриден сос, лимонена трева и люто. Много люто. Още по-люто. Смърт. Често в менютата на ресторантите има две скàли за лютивост – Western spicy или Thai spicy. Ако изберете втората, възможно е сервитьорите тайно да ви наблюдават, докато ядете, и да се любуват на последвалите гримаси.

Сладостта в тайското къри и някои други ястия не е по моя вкус, но

да си вегетарианец в Тайланд е много по-лесно дори в сравнение с най-хипстърския град на нашия континент.

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

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

Друго, което тайландците продават навсякъде, е бензин в бутилки от ром. Така по всяко време може да заредиш японския си (като марка) скутер, произведен в Тайланд и нает за 150 бата на ден (около 7,50 лв.). Както в повечето азиатски страни, и тук скутерите масово се използват за придвижване дори в големите градове, в които разстоянията са изтощителни.

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

Тайланд под кожата (първа част)

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

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

Всички снимки в статията са собственост на авторката.

[$] Standardizing the BPF ISA

Post Syndicated from daroc original https://lwn.net/Articles/975830/

While BPF may be most famous for its use in the Linux kernel, there is actually
a growing effort to standardize BPF for use on other systems. These include

eBPF for Windows
, but also

uBPF
,

rBPF
,

hBPF
,

bpftime
, and
others. Some hardware manufacturers are even
considering integrating BPF directly into networking hardware. Dave Thaler
led two sessions about all of the problems that cross-platform use inevitably
brings and the current status of the standardization work at the 2024
Linux Storage,
Filesystem, Memory Management, and BPF Summit
.

Migrate a petabyte-scale data warehouse from Actian Vectorwise to Amazon Redshift

Post Syndicated from Krishna Gogineni original https://aws.amazon.com/blogs/big-data/migrate-a-petabyte-scale-data-warehouse-from-actian-vectorwise-to-amazon-redshift/

Amazon Redshift is a fast, scalable, and fully managed cloud data warehouse that allows you to process and run your complex SQL analytics workloads on structured and semi-structured data. It also helps you securely access your data in operational databases, data lakes, or third-party datasets with minimal movement or copying of data. Tens of thousands of customers use Amazon Redshift to process large amounts of data, modernize their data analytics workloads, and provide insights for their business users.

In this post, we discuss how a financial services industry customer achieved scalability, resiliency, and availability by migrating from an on-premises Actian Vectorwise data warehouse to Amazon Redshift.

Challenges

The customer’s use case required a high-performing, highly available, and scalable data warehouse to process queries against large datasets in a low-latency environment. Their Actian Vectorwise system was designed to replace Excel plugins and stock screeners but eventually evolved into a much larger and ambitious portfolio analysis solution running multiple API clusters on premises, serving some of the largest financial services firms worldwide. The customer saw growing demand that needed high performance and scalability due to 30% year-over-year increase in usage from the success of their products. The customer needed to keep up with increased volume of read requests, but they couldn’t do this without deploying additional hardware in the data center. There was also a customer mandate that business-critical products must have their hardware updated to cloud-based solutions or be deemed on the path to obsolescence. In addition, the business started moving customers onto a new commercial model, and therefore new projects would need to provision a new cluster, which meant that they needed improved performance, scalability, and availability.

They faced the following challenges:

  • Scalability – The customer understood that infrastructure maintenance was a growing issue and, although operations were a consideration, the existing implementation didn’t have a scalable and efficient solution to meet the advanced sharding requirements needed for query, reporting, and analysis. Over-provisioning of data warehouse capacity to meet unpredictable workloads resulted in underutilized capacity during normal operations by 30%.
  • Availability and resiliency – Because the customer was running business-critical analytical workloads, it required the highest levels of availability and resiliency, which was a concern with the on-premises data warehouse solution.
  • Performance – Some of their queries needed to be processed in priority, and users were starting to experience performance degradation with longer-running query times as their solution started getting used more and more. The need for a scalable and efficient solution to manage customer demand, address infrastructure maintenance concerns, replace legacy tooling, and tackle availability led to them choosing Amazon Redshift as the future state solution. If these concerns were not addressed, the customer would be prevented from growing their user base.

Legacy architecture

The customer’s platform was the main source for one-time, batch, and content processing. It served many enterprise use cases across API feeds, content mastering, and analytics interfaces. It was also the single strategic platform within the company for entity screening, on-the-fly aggregation, and other one-time, complex request workflows.

The following diagram illustrates the legacy architecture.

The architecture consists of many layers:

  • Rules engine – The rules engine was responsible for intercepting every incoming request. Based on the nature of the request, it routed the request to the API cluster that could optimally process that specific request based on the response time requirement.
  • API – Scalability was one of the primary challenges with the existing on-premises system. It wasn’t possible to quickly scale up and down API service capacity to meet growing business demand. Both the API and data store had to support a highly volatile workload pattern. This included simple data retrieval requests that had to be processed within a few milliseconds vs. power user-style batch requests with complex analytics-based workloads that could take several seconds and significant compute resources to process. To separate these different workload patterns, the API and data store infrastructure was split into multiple isolated physical clusters. This made sure each workload group was provisioned with sufficient reserved capacity to meet the respective response time expectations. However, this model of reserving capacity for each workload type resulted in suboptimal usage of compute resources because each cluster would only process a specific workload type.
  • Data store – The data store used a custom data model that had been highly optimized to meet low-latency query response requirements. The current on-premises data store wasn’t horizontally scalable, and there was no built-in replication or data sharding capability. Due to this limitation, multiple database instances were created to meet concurrent scalability and availability requirements because the schema wasn’t generic per dataset. This model caused operational maintenance overhead and wasn’t easily expandable.
  • Data ingestion – Pentaho was used to ingest data sourced from multiple data publishers into the data store. The ingestion framework itself didn’t have any major challenges. However, the primary bottleneck was due to scalability issues associated with the data store. Because the data store didn’t support sharding or replication, data ingestion had to explicitly ingest the same data concurrently across multiple database nodes within a single transaction to provide data consistency. This significantly impacted overall ingestion speed.

Overall, the current architecture didn’t support workload prioritization, therefore a physical model of resources was reserved for this reason. The downside here is over-provisioning. The system had an integration with legacy backend services that were all hosted on premises.

Solution overview

Amazon Redshift is an industry-leading cloud data warehouse. Amazon Redshift uses SQL to analyze structured and semi-structured data across data warehouses, operational databases, and data lakes using AWS-designed hardware and machine learning (ML) to deliver the best price-performance at any scale.

Amazon Redshift is designed for high-performance data warehousing, which provides fast query processing and scalable storage to handle large volumes of data efficiently. Its columnar storage format minimizes I/O and improves query performance by reading only the relevant data needed for each query, resulting in faster data retrieval. Lastly, you can integrate Amazon Redshift with data lakes like Amazon Simple Storage Service (Amazon S3), combining structured and semi-structured data for comprehensive analytics.

The following diagram illustrates the architecture of the new solution.

In the following sections, we discuss the features of this solution and how it addresses the challenges of the legacy architecture.

Rules engine and API

Amazon API Gateway is a fully managed service that help developers deliver secure, robust, API-driven application backends at any scale. To address scalability and availability requirements of the rules and routing layer, we introduced API Gateway to do the routing of the client requests to different integration paths using routes and parameter mappings. Having API Gateway as the entry point allowed the customer to move away from the design, testing, and maintenance of their rules engine development workload. In their legacy environment, handling fluctuating amounts of traffic posed a significant challenge. However, API Gateway seamlessly addressed this issue by acting as a proxy and automatically scaling to accommodate varying traffic demands, providing optimal performance and reliability.

Data storage and processing

Amazon Redshift allowed the customer to meet their scalability and performance requirements. Amazon Redshift features such as workload management (WLM), massively parallel processing (MPP) architecture, concurrency scaling, and parameter groups helped address the requirements:

  • WLM provided the ability for query prioritization and managing resources effectively
  • The MPP architecture model provided horizontal scalability
  • Concurrency scaling added additional cluster capacity to handle unpredictable and spiky workloads
  • Parameter groups defined configuration parameters that control database behavior

Together, these capabilities allowed them to meet their scalability and performance requirements in a managed fashion.

Data distribution

The legacy data center architecture was unable to partition the data without deploying additional hardware in the data center, and it couldn’t handle read workloads efficiently.

The MPP architecture of Amazon Redshift offers efficient data distribution across all the compute nodes, which helped run heavy workloads in parallel and subsequently lowered response times. With the data distributed across all the compute nodes, it allows data to be processed in parallel. Its MPP engine and architecture separates compute and storage for efficient scaling and performance.

Operational efficiency and hygiene

Infrastructure maintenance and operational efficiency was a concern for the customer in their current state architecture. Amazon Redshift is a fully managed service that takes care of data warehouse management tasks such as hardware provisioning, software patching, setup, configuration, and monitoring nodes and drives to recover from failures or backups. Amazon Redshift periodically performs maintenance to apply fixes, enhancements, and new features to your Redshift data warehouse. As a result, the customer’s operational costs reduced by 500%, and they are now able to spend more time innovating and building mission-critical applications.

Workload management

Amazon Redshift WLM was able to resolve issues with the legacy architecture where longer-running queries were consuming all the resources, causing other queries to run slower, impacting performance SLAs. With automatic WLM, the customer was able to create separate WLM queues with different priorities, which allowed them to manage the priorities for the critical SLA-bound workloads and other non-critical workloads. With short query acceleration (SQA) enabled, it prioritized selected short-running queries ahead of longer-running queries. Furthermore, the customer benefited by using query monitoring rules in WLM to apply performance boundaries to control poorly designed queries and take action when a query goes beyond those boundaries. To learn more about WLM, refer to Implementing workload management.

Workload isolation

In the legacy architecture, all the workloads—extract, transform, and load (ETL); business intelligence (BI); and one-time workloads—were running on the same on-premises data warehouse, leading to the noisy neighbor problem and performance issues with the increase in users and workloads.

With the new solution architecture, this issue is remediated using data sharing in Amazon Redshift. With data sharing, the customer is able to share live data with security and ease across Redshift clusters, AWS accounts, or AWS Regions for read purposes, without the need to copy any data.

Data sharing improved the agility of the customer’s organization. It does this by giving them instant, granular, and high-performance access to data across Redshift clusters without the need to copy or move it manually. With data sharing, customers have live access to data, so their users can see the most up-to-date and consistent information as it’s updated in Redshift clusters. Data sharing provides workload isolation by running ETL workloads in its own Redshift cluster and sharing data with other BI and analytical workloads in their respective Redshift clusters.

Scalability

With the legacy architecture, the customer was facing scalability challenges during large events to handle unpredictable spiky workloads and over-provisioning of the database capacity. Using concurrency scaling and elastic resize allowed the customer to meet their scalability requirements and handle unpredictable and spiky workloads.

Data migration to Amazon Redshift

The customer used a home-grown process to extract the data from Actian Vectorwise and store it in Amazon S3 and CSV files. The data from Amazon S3 was then ingested into Amazon Redshift.

The loading process used a COPY command and ingested the data from Amazon S3 in a fast and efficient way. A best practice for loading data into Amazon Redshift is to use the COPY command. The COPY command is the most efficient way to load a table because it uses the Amazon Redshift MPP architecture to read and load data in parallel from a file or multiple files in an S3 bucket.

To learn about the best practices for source data files to load using the COPY command, see Loading data files.

After the data is ingested into Redshift staging tables from Amazon S3, transformation jobs are run from Pentaho to apply the incremental changes to the final reporting tables.

The following diagram illustrates this workflow.

Key considerations for the migration

There are three ways of migrating an on-premises data warehouse to Amazon Redshift: one-step, two-step, and wave-based migration. To minimize the risk of migrating over 20 databases that vary in complexity, we decided on the wave-based approach. The fundamental concept behind wave-based migration involves dividing the migration program into projects based on factors such as complexity and business outcomes. The implementation then migrates each project individually or by combining certain projects into a wave. Subsequent waves follow, which may or may not be dependent on the results of the preceding wave.

This strategy requires both the legacy data warehouse and Amazon Redshift to operate concurrently until the migration and validation of all workloads are successfully complete. This provides a smooth transition while making sure the on-premises infrastructure can be retired only after thorough migration and validation have taken place.

In addition, within each wave, we followed a set of phases to make sure that each wave was successful:

  • Assess and plan
  • Design the Amazon Redshift environment
  • Migrate the data
  • Test and validate
  • Perform cutover and optimizations

In the process, we didn’t want to rewrite the legacy code for each migration. With minimal code changes, we migrated the data to Amazon Redshift because SQL compatibility was very important in the process due to existing knowledge within the organization and downstream application consumption. After the data was ingested into the Redshift cluster, we adjusted the tables for best performance.

One of the main benefits we realized as part of the migration was the option to integrate data in Amazon Redshift with other business groups in the future that use AWS Data Exchange, without significant effort.

We performed blue/green deployments to make sure that the end-users didn’t encounter any latency degradation while retrieving the data. We migrated the end-users in a phased manner to measure the impact and adjust the cluster configuration as needed.

Results

The customer’s decision to use Amazon Redshift for their solution was further reinforced by the platform’s ability to handle both structured and semi-structured data seamlessly. Amazon Redshift allows the customer to efficiently analyze and derive valuable insights from their diverse range of datasets, including equities and institutional data, all while using standard SQL commands that teams are already comfortable with.

Through rigorous testing, Amazon Redshift consistently demonstrated remarkable performance, meeting the customer’s stringent SLAs and delivering exceptional subsecond query response times with an impressive latency. With the AWS migration, the customer achieved a 5% improvement in query performance. Scalability of the clusters was done in minutes compared to 6 months in the data center. Operational cost reduced by 500% due to the simplicity of the Redshift cluster operations in AWS. Stability of the clusters improved by 100%. Upgrades and patching cycle time improved by 200%. Overall, improvement in operational posture and total savings for the footprint has resulted in significant savings for the team and platform in general. In addition, the ability to scale the overall architecture based on market data trends in a resilient and highly available way not only met the customer demand in terms of time to market, but also significantly reduced the operational costs and total cost of ownership.

Conclusion

In this post, we covered how a large financial services customer improved performance and scalability, and reduced their operational costs by migrating to Amazon Redshift. This enabled the customer to grow and onboard new workloads into Amazon Redshift for their business-critical applications.

To learn about other migration use cases, refer to the following:


About the Authors

Krishna Gogineni is a Principal Solutions Architect at AWS helping financial services customers. Krishna is Cloud-Native Architecture evangelist helping customers transform the way they build software. Krishna works with customers to learn their unique business goals, and then super-charge their ability to meet these goals through software delivery that leverages industry best practices/tools such as DevOps, Data Lakes, Data Analytics, Microservices, Containers, and Continuous Integration/Continuous Delivery.

Dayananda Shenoy is a Senior Solution Architect with over 20 years of experience designing and architecting backend services for financial services products. Currently, he leads the design and architecture of distributed, high-performance, low latency analytics services for a data provider. He is passionate about solving scalability and performance challenges in distributed systems leveraging emerging technology which improve existing tech stacks and add value to the business to enhance customer experience.

Vishal Balani is a Sr. Customer Solutions Manager based out of New York. He works closely with Financial Services customers to help them leverage cloud for businesses agility, innovation and resiliency. He has extensive experience leading large-scale cloud migration programs. Outside of work he enjoys spending time with family, tinkering with a new project or riding his bike.

Ranjan Burman is a Sr. PostgreSQL Database Specialist SA. He specializes in RDS & Aurora PostgreSQL. He has more than 18 years of experience in different database and data warehousing technologies. He is passionate about automating and solving customer problems with the use of cloud solutions.

Muthuvelan Swaminathan is an Enterprise Solutions Architect based out of New York. He works with enterprise customers providing architectural guidance in building resilient, cost-effective and innovative solutions that address business needs.

Quickly adopt new AWS features with the Terraform AWS Cloud Control provider

Post Syndicated from Welly Siauw original https://aws.amazon.com/blogs/devops/quickly-adopt-new-aws-features-with-the-terraform-aws-cloud-control-provider/

Introduction

Today, we are pleased to announce the general availability of the Terraform AWS Cloud Control (AWS CC) Provider, enabling our customers to take advantage of AWS innovations faster. AWS has been continually expanding its services to support virtually any cloud workload; supporting over 200 fully featured services and delighting customers through its rapid pace of innovation with over 3,400 significant new features in 2023. Our customers use Infrastructure as Code (IaC) tools such as HashiCorp Terraform among others as a best-practice to provision and manage these AWS features and services as part of their cloud infrastructure at scale. With the Terraform AWS CC Provider launch, AWS customers using Terraform as their IaC tool can now benefit from faster time-to-market by building cloud infrastructure with the latest AWS innovations that are typically available on the Terraform AWS CC Provider on the day of launch. For example, AWS customer Meta’s Oculus Studios was able to quickly leverage Amazon GameLift to support their game development. “AWS and Hashicorp have been great partners in helping Oculus Studios standardize how we deploy our GameLift infrastructure using industry best practices.” said Mick Afaneh, Meta’s Oculus Studios Central Technology.

The Terraform AWS CC Provider leverages AWS Cloud Control API to automatically generate support for hundreds of AWS resource types, such as Amazon EC2 instances and Amazon S3 buckets. Since the AWS CC provider is automatically generated, new features and services on AWS can be supported as soon as they are available on AWS Cloud Control API, addressing any coverage gaps in the existing Terraform AWS standard provider. This automated process allows the AWS CC provider to deliver new resources faster because it does not have to wait for the community to author schema and resource implementations for each new service. Today, the AWS CC provider supports 950+ AWS resources and data sources, with more support being added as AWS service teams continue to adopt the Cloud Control API standard.

As a Terraform practitioner, using the AWS CC Provider would feel familiar to the existing workflow. You can employ the configuration blocks shown below, while specifying your preferred region.

terraform {
  required_providers {
    awscc = {
      source  = "hashicorp/awscc"
      version = "~> 1.0"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "awscc" {
  region = "us-east-1"
}

provider "aws" {
  region = "us-east-1"
}

During Terraform plan or apply, the AWS CC Terraform provider interacts with AWS Cloud Control API to provision the resources by calling its consistent Create, Read, Update, Delete, or List (CRUD-L) APIs.

AWS Cloud Control API

AWS service teams own, publish, and maintain resources on the AWS CloudFormation Registry using a standardized resource model. This resource model uses uniform JSON schemas and provisioning logic that codifies the expected behavior and error handling associated with CRUD-L operations. This resource model enables AWS service teams to expose their service features in an easily discoverable, intuitive, and uniform format with standardized behavior. Launched in September 2021, AWS Cloud Control API exposes these resources through a set of five consistent CRUD-L operations without any additional work from service teams. Using Cloud Control API, developers can manage the lifecycle of hundreds of AWS and third-party resources with consistent resource-oriented API instead of using distinct service-specific APIs. Furthermore, Cloud Control API is up-to-date with the latest AWS resources as soon as they are available on the CloudFormation Registry, typically on the day of launch. You can read more on launch day requirement for Cloud Control API in this blog post. This enables AWS Partners such as HashiCorp to take advantage of consistent CRUD-L API operations and integrate Terraform with Cloud Control API just once, and then automatically access new AWS resources without additional integration work.

History and Evolution of the Terraform AWS CC Provider

The general availability of Terraform AWS CC Provider project is a culmination of 4+ years of collaboration between AWS and HashiCorp. Our teams partnered across the Product, Engineering, Partner, and Customer Support functions in influencing, shaping, and defining the customer experience leading up to the the technical preview announcement of the AWS CC provider in September 2021. At technical preview, the provider supported more than 300 resources. Since then, we have added an additional 600+ resources to the provider, bringing the total to 950+ supported resources at general availability.

Beyond just increasing resource coverage, we gathered additional signals from customer feedback during the technical preview and rolled out several improvements since September 2021. Customers care deeply about the user experience on the providers available on the Terraform registry. Customers sought practical examples in the form of sample HCL configurations for each resource that they could use to immediately test in order to confidently start using the provider. This prompted us to enrich the AWS CC provider with hundreds of practical examples for popular AWS CC provider resources in the Terraform registry. This was made possible by contributions of hundreds of Amazonians who became early adopters of the AWS CC provider. We also published a how-to guide for anyone interested in contributing to AWS CC provider examples. Furthermore, customers also wanted to minimize context switching by moving between Terraform and AWS service documentation on what each attribute of a resource signified and the type of values it needed as part of configuration. This empowered us to prioritize augmenting the provider with rich resource attribute description with information taken from AWS documentation. The documentation provides detailed information of how to use the attributes, enumerations of the accepted attribute values and other relevant information for dozens of popularly used AWS resources.

We also worked with HashiCorp on various bug fixes and feature enhancements for the AWS CC provider, as well as the upstream Cloud Control API dependencies. We improved handling for resources with complex nested attribute schemas, implemented various bug fixes to resolve unintended resource replacement, and refined provider behavior under various conditions to support the idempotency expected by Terraform practitioners. While this are not an exhaustive list of improvements, we continue to listen to customer feedback and iterate on improving the experience. We encourage you to try out the provider and share feedback on the AWS CC provider’s GitHub page.

Using the AWS CC Provider

Let’s take an example of a recently introduced service, Amazon Q Business, a fully managed, generative AI-powered assistant that you can configure to answer questions, provide summaries, generate content, and complete tasks based on your enterprise data. Amazon Q Business resources were available in AWS CC provider shortly after the April 30th 2024 launch announcement. In the following example, we’ll create a demo Amazon Q Business application and deploy the web experience.

data "aws_caller_identity" "current" {}

data "aws_ssoadmin_instances" "example" {}

resource "awscc_qbusiness_application" "example" {
  description                  = "Example QBusiness Application"
  display_name                 = "Demo_QBusiness_App"
  attachments_configuration    = {
    attachments_control_mode = "ENABLED"
  }
  identity_center_instance_arn = data.aws_ssoadmin_instances.example.arns[0]
}

resource "awscc_qbusiness_web_experience" "example" {
  application_id              = awscc_qbusiness_application.example.id
  role_arn                    = awscc_iam_role.example.arn
  subtitle                    = "Drop a file and ask questions"
  title                       = "Demo Amazon Q Business"
  welcome_message             = "Welcome, please enter your questions"
}

resource "awscc_iam_role" "example" {
  role_name   = "Amazon-QBusiness-WebExperience-Role"
  description = "Grants permissions to AWS Services and Resources used or managed by Amazon Q Business"
  assume_role_policy_document = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "QBusinessTrustPolicy"
        Effect = "Allow"
        Principal = {
          Service = "application.qbusiness.amazonaws.com"
        }
        Action = [
          "sts:AssumeRole",
          "sts:SetContext"
        ]
        Condition = {
          StringEquals = {
            "aws:SourceAccount" = data.aws_caller_identity.current.account_id
          }
          ArnEquals = {
            "aws:SourceArn" = awscc_qbusiness_application.example.application_arn
          }
        }
      }
    ]
  })
  policies = [{
    policy_name = "qbusiness_policy"
    policy_document = jsonencode({
      Version = "2012-10-17"
      Statement = [
        {
          Sid = "QBusinessConversationPermission"
          Effect = "Allow"
          Action = [
            "qbusiness:Chat",
            "qbusiness:ChatSync",
            "qbusiness:ListMessages",
            "qbusiness:ListConversations",
            "qbusiness:DeleteConversation",
            "qbusiness:PutFeedback",
            "qbusiness:GetWebExperience",
            "qbusiness:GetApplication",
            "qbusiness:ListPlugins",
            "qbusiness:GetChatControlsConfiguration"
          ]
          Resource = awscc_qbusiness_application.example.application_arn
        }
      ]
    })
  }]
}

As you see in this example, you can use both the AWS and AWS CC providers in the same configuration file. This allows you to easily incorporate new resources available in the AWS CC provider into your existing configuration with minimal changes. The AWS CC provider also accepts the same authentication method and provider-level features available in the AWS provider. This means you don’t have to add additional configuration in your CI/CD pipeline to start using the AWS CC provider. In addition, you can also add custom agent information inside the provider block as described in this documentation.

Things to know

The AWS CC provider is unique due to how it was developed and its dependencies with Cloud Control API and AWS resource model in the CloudFormation registry. As such, there are things that you should know before you start using the AWS CC provider.

  • The AWS CC provider is generated from the latest CloudFormation schemas, and will release weekly containing all new AWS services and enhancements added to Cloud Control API.
  • Certain resources available in the CloudFormation schema are not compatible with the AWS CC provider due to nuances in the schema implementation. You can find them on the GitHub issue list here. We are actively working to add these resources to the AWS CC provider.
  • The AWS CC provider requires Terraform CLI version 1.0.7 or higher.
  • Every AWS CC provider resource includes a top-level attribute `id` that acts as the resource identifier. If the CloudFormation resource schema also has a similarly named top-level attribute `id`, then that property is mapped to a new attribute named `<type>_id`. For example `web_experience_id` for `awscc_qbusiness_web_experience` resource.
  • If a resource attribute is not defined in the Terraform configuration, the AWS CC provider will honor the default values specified in the CloudFormation resource schema. If the resource schema does not include a default value, AWS CC provider will use attribute value stored in the Terraform state (taken from Cloud Control API GetResponse after resource was created).
  • In correlation to the default value behavior as stated above, when an attribute value is removed from the Terraform configuration (e.g. by commenting the attribute), the AWS CC provider will use the previous attribute value stored in the Terraform state. As such, no drift will be detected on the resource configuration when you run Terraform plan / apply.
  • The AWS CC provider data sources are either plural or singular with filters based on `id` attribute. Currently there is no native support for metadata sources such as `aws_region` or `aws_caller_identity`. You can continue to leverage the AWS provider data sources to complement your Terraform configuration.

If you want to dive deeper into AWS CC provider resource behavior, we encourage you to check the documentation here.

Conclusion

The AWS CC provider is now generally available and will be the fastest way for customers to access newly launched AWS features and services using Terraform. We will continue to add support for more resources, additional examples and enriching the schema descriptions. You can start using the AWS CC provider alongside your existing AWS standard provider. To learn more about the AWS CC provider, please check the HashiCorp announcement blog post. You can also follow the workshop on how to get started with AWS CC provider. If you are interested in contributing with practical examples for AWS CC provider resources, check out the how-to guide. For more questions or if you run into any issues with the new provider, don’t hesitate to submit your issue in the AWS CC provider GitHub repository.

Authors

Manu Chandrasekhar

Manu is an AWS DevOps consultant with close to 19 years of industry experience wearing QA/DevOps/Software engineering and management hats. He looks to enable teams he works with to be self-sufficient in
modelling/provisioning Infrastructure in cloud and guides them in cloud adoption. He believes that by improving the developer experience and reducing the barrier of entry to any technology with the advancements in automation and AI, software deployment and delivery can be a non-event.

Rahul Sharma

Rahul is a Principal Product Manager-Technical at Amazon Web Services with over three and a half years of cumulative product management experience spanning Infrastructure as Code (IaC) and Customer Identity and Access Management (CIAM) space.

Welly Siauw

As a Principal Partner Solution Architect, Welly led the co-build and co-innovation strategy with AWS ISV partners. He is passionate about Terraform, Developer Experience and Cloud Governance. Welly joined AWS in 2018 and carried with him almost 2 decades of experience in IT operations, application development, cyber security, and oil exploration. In between work, he spent time tinkering with espresso machines and outdoor hiking.

CVE-2024-24919: Check Point Security Gateway Information Disclosure

Post Syndicated from Rapid7 original https://blog.rapid7.com/2024/05/30/etr-cve-2024-24919-check-point-security-gateway-information-disclosure/

CVE-2024-24919: Check Point Security Gateway Information Disclosure

On May 28, 2024, Check Point published an advisory for CVE-2024-24919, a high-severity information disclosure vulnerability affecting Check Point Security Gateway devices configured with either the “IPSec VPN” or “Mobile Access” software blade.

On May 29, 2024, security firm mnemonic published a blog reporting that they have observed in-the-wild exploitation of CVE-2024-24919 since April 30, 2024, with threat actors leveraging the vulnerability to enumerate and extract password hashes for all local accounts, including accounts used to connect to Active Directory. They’ve also observed adversaries moving laterally and extracting the “ntds.dit” file from compromised customers’ Active Directory servers, within hours of an initial attack against a vulnerable Check Point Gateway.

On May 30, 2024, watchTowr published technical details of CVE-2024-24919 including a PoC.

The vulnerability allows an unauthenticated remote attacker to read the contents of an arbitrary file located on the affected appliance. For example, this allows an attacker to read the appliances /etc/shadow file, disclosing the password hashes for local accounts. The attacker is not limited to reading this file and may read other files that contain sensitive information. An attacker may be able to crack the password hashes for these local accounts, and if the Security Gateway allows password only authentication, the attacker may use the cracked passwords to authenticate.

Mitigation Guidance

According to the vendor advisory, the following products are vulnerable to CVE-2024-24919:

  • CloudGuard Network
  • Quantum Maestro
  • Quantum Scalable Chassis
  • Quantum Security Gateways
  • Quantum Spark Appliances

Check Point has advised that a Security Gateway is vulnerable if one of the following configuration is applied:

  • If the “IPSec VPN” blade has been enabled and the Security Gateway device is part of the “Remote Access” VPN community.
  • If the “Mobile Access” blade has been enabled.

Check Point has released hotfixes for Quantum Security Gateway, Quantum Maestro, Quantum Scalable Chassis, and Quantum Spark Appliances. We advise customers to refer to the Check Point advisory for the most current information on affected versions and hotfixes.

The vendor supplied hotfixes should be applied immediately. Rapid7 strongly recommends that Check Point Security Gateway customers examine their environments for signs of compromise and reset local account credentials in addition to applying vendor-provided fixes.

Check Point notes that exploit attempts their team has observed “focus on remote access scenarios with old local accounts with unrecommended password-only authentication.” The company recommends that customers check for local account usage, disable any unused local accounts, and add certificate-based authentication rather than password-only authentication. More information and recommendations on user and client authentication for remote access is available here.

Rapid7 Customers

A vulnerability check is in development for InsightVM and Nexpose customers to assess exposure to CVE-2024-24919. This blog will be updated with the latest information as and when it is available

InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on post-exploitation behavior related to this vulnerability:

  • Suspicious Web Server Request – Successful Path Traversal Attack
  • Suspicious Web Request – Possible Check Point VPN (CVE-2024-24919) Exploitation

Let’s Architect! Learn About Machine Learning on AWS

Post Syndicated from Luca Mezzalira original https://aws.amazon.com/blogs/architecture/lets-architect-learn-about-machine-learning-on-aws/

A data-driven approach empowers businesses to make informed decisions based on accurate predictions and forecasts, leading to improved operational efficiency and resource optimization. Machine learning (ML) systems have the remarkable ability to continuously learn and adapt, improving their performance over time as they are exposed to more data. This self-learning capability ensures that organizations can stay ahead of the curve, responding dynamically to changing market conditions and customer preferences, ultimately driving innovation and enhancing competitiveness.

By leveraging the power of machine learning on AWS, businesses can unlock benefits that enhance efficiency, improve decision-making, and foster growth.

AWS re:Invent 2023 – Zero to machine learning: Jump-start your data-driven journey

In this session, see how organizations with constrained resources (budgets, skill gaps, time) can jump start their data-driven journey with advanced analytics and ML capabilities. Learn AWS Working Backwards best practices to drive forward data-related projects that address tangible business value. Then dive into AWS analytics and AI/ML capabilities that simplify and expedite data pipeline delivery and business value from ML workloads. Hear about low-code no-code (LCNC) AWS services within the context of a complete data pipeline architecture.

Take me to this video

See an architecture to analyze customer churn using AWS services

Figure 1. See an architecture to analyze customer churn using AWS services

Introduction to MLOps engineering on AWS

As artificial intelligence (AI) continues to revolutionize industries, the ability to operationalize and scale ML models has become a critical challenge. This session introduces the concept of MLOps, a discipline that builds upon and extends the widely adopted DevOps practices prevalent in software development. By applying MLOps principles, organizations can streamline the process of building, training, and deploying ML models, ensuring efficient and reliable model lifecycle management. By mastering MLOps, organizations can bridge the gap between AI development and operations, enabling them to unlock the full potential of their ML initiatives.

Take me to this video

MLOps maturity level will help to assess your organization and understand how to reach the next level.

Figure 2. MLOps maturity level will help to assess your organization and understand how to reach the next level.

Behind-the-scenes look at generative AI infrastructure at Amazon

To power generative AI applications while keeping costs under control, AWS designs and builds machine learning accelerators like AWS Trainium and AWS Inferentia. This session introduces purpose-built ML hardware for model training and inference, and shows how Amazon and AWS customers take advantage of those solutions to optimize costs and reduce latency.

You can learn from practical examples showing the impact of those solutions and explanations about how these chips work. ML accelerators are not only beneficial for generative AI workloads; they can also be applied to other use cases, including representation learning, recommender systems, or any scenario with deep neural network models.

Take me to this video

Discover the technology that powers our AI services

Figure 3. Discover the technology that powers our AI services

How our customers are implementing machine learning on AWS

The following resources drill down into the ML infrastructure that’s used to train large models at Pinterest and the experimentation framework built by Booking.com.

The Pinterest video discusses the strategy to create an ML development environment, orchestrate training jobs, ingest data into the training loop, and accelerate the training speed. You can also learn about the advantages derived from containers in the context of ML and how Pinterest decided to set up the entire ML lifecycle, including distributed model training.

The second resource covers how Booking.com accelerated the experimentation process by leveraging Amazon SageMaker for data analysis, model training, and online experimentation. This resulted in shorter development times for their ranking models and increased speed for the data science teams.

Take me to Pinterest video

Take me to Booking.com blog post

Let’s discover how Pinterest is using AWS services for machine learning workloads

Figure 4. Let’s discover how Pinterest is using AWS services for machine learning workloads

SageMaker Immersion Day

Amazon SageMaker Immersion Day helps customers and partners provide end-to-end understanding of building ML use cases. From feature engineering to understanding various built-in algorithms, with a focus on training, tuning, and deploying the ML model in a production-like scenario, this workshop guides you to bring your own model to perform lift-and-shift from on-premises to the Amazon SageMaker platform. It further demonstrates more advanced concepts like model debugging, model monitoring, and AutoML.

Take me to the workshop

Train, tune and deploy your workload using Amazon SageMaker

Figure 5. Train, tune and deploy your workload using Amazon SageMaker

See you next time!

Thanks for reading! With this post, introduced you to the art of possibility on using AWS machine learning services. In the next blog, we will talk about cloud migrations.

To revisit any of our previous posts or explore the entire series, visit the Let’s Architect! page.

The collective thoughts of the interwebz