Announcing the new AWS Asia Pacific (Thailand) Region

Post Syndicated from Donnie Prakoso original https://aws.amazon.com/blogs/aws/announcing-the-new-aws-asia-pacific-thailand-region/

Today, we’re pleased to announce that the AWS Asia Pacific (Thailand) Region is now generally available with three Availability Zones and API name ap-southeast-7.

The AWS Asia Pacific (Thailand) Region is the first infrastructure Region in Thailand and the fourteenth Region in Asia Pacific, joining existing Regions in Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, and Tokyo, as well as the Beijing and Ningxia China Regions.

Lumphini Park, one of the largest green spaces in central Bangkok spanning 142 acres.

The adoption of cloud computing has gained significant momentum in Thailand, driven by evolving business needs and government initiatives such as Thailand 4.0. These initiatives aim to transform Thailand into an innovation-driven economy by using emerging technologies to enhance productivity, competitiveness, and sustainable growth.

The new AWS Region will help startups, enterprises, government agencies, educational institutions, and nonprofit organizations run their applications and serve end users while maintaining data residency in Thailand. This aligns with Thailand’s digital transformation goals and the growing demand for cloud services. Over the next 15 years, Amazon Web Services (AWS) planned investments in Thailand are estimated to contribute $10B to Thailand’s Gross Domestic Product (GDP) and support an estimated average of 11,000 full-time equivalent (FTE) jobs in local Thai businesses annually.

Growing presence of AWS in Thailand
Our journey in Thailand began in 2013 with the first AWS office in Bangkok. Since then, AWS has continuously expanded its infrastructure and services in the country:

Amazon CloudFront – Since 2020, AWS has established six Amazon CloudFront edge locations throughout Thailand. These edge locations are part of the highly secure and programmable AWS content delivery network (CDN), designed to accelerate the delivery of data, videos, applications, and APIs to users worldwide with low latency and high transfer speeds.

AWS Outposts – In the same year, 2020, AWS introduced AWS Outposts to the Thai market. As a fully managed solution, AWS Outposts brings AWS infrastructure and services to virtually any on-premises or edge location, enabling a truly consistent hybrid experience. This service is particularly valuable for workloads that require low latency, local data processing, or local data storage.

AWS Local Zones – In 2022, AWS strengthened its commitment to Thailand by launching AWS Local Zones in Bangkok. This infrastructure deployment places compute, storage, database, and other select services closer to large population, industry, and IT centers. As a result, customers can deliver applications requiring single-digit millisecond latency to end users.

AWS Direct Connect – AWS established a AWS Direct Connect location in Bangkok in 2023 to enhance connectivity options and added a new AWS Direct Connect location with the launch of the AWS Asia Pacific (Thailand) Region. Customers can use AWS Direct Connect to establish secure and dedicated network connections to their AWS resources, providing improved network performance and reduced bandwidth costs.

AWS customer success stories in Thailand
Organizations in Thailand are using our services to drive innovation and transformation. Here are a few examples:

2C2P
2C2P, a leading Thailand-based FinTech startup, chose AWS for its robust security capabilities. As an omnichannel payment service provider in Southeast Asia, the company processes millions of customer payments globally using AWS CloudHSM for cryptographic key management, AWS Shield for distributed denial of service (DDoS) protection, and AWS Secrets Manager to safeguard sensitive credentials.

“Through AWS, we’ve unlocked the power to securely, dynamically, and compliantly scale to meet the surge in payment transaction volumes. AWS CloudHSM plays a pivotal role in fulfilling compliance requirements and propelling us toward accelerated business expansion,” says Myo Zaw, Chief Technology Officer at 2C2P.

aCommerce
aCommerce, the largest ecommerce enabler in Southeast Asia, has revolutionized market intelligence by launching AskIQ, a generative AI–powered feature on AWS. This software as a service (SaaS) platform provides the world’s leading brands with comprehensive competitor and category performance tracking capabilities across Southeast Asia’s largest ecommerce sites.

Leena Chanvirach, VP of Data Products at aCommerce Group, emphasizes the strategic value of their AWS collaboration: “Our collaboration with AWS allows clients to double down on their core competencies and business priorities. This best-of-both-worlds approach gives brands a competitive edge without the burden of building and maintaining sophisticated data infrastructure in-house.”

Ascend Money
Ascend Money, a leading Southeast Asian FinTech company, achieved a 70 percent reduction in compute costs while simultaneously improving application performance by up to 40 percent in certain workloads. Ascend Money implemented a sophisticated compute strategy using Amazon EC2 instances, resulting in significant operational improvements.

“AWS has significantly improved our performance, enabling us to deliver more innovative services to our customers,” says Peerawit Phuangkaeo, Head of Technical Operations at Ascend Money.

Building cloud skills together
AWS has built comprehensive programs for cloud education and skills development in Thailand, training more than 50,000 individuals in cloud skills since 2017. Here are some of the programs:

AWS Skill Builder
AWS Skill Builder is an online learning center where you can learn from AWS experts and build cloud skills online. AWS has made cloud education more accessible to Thai learners by offering more than 600 courses, with 106 courses specifically available in Thai language. The recent launch of the Amazon AI Ready initiative has further expanded the learning opportunities, particularly in the growing field of AI.

AWS Educate
Since its introduction in 2016, AWS Educate has played a transformative role in Thai education. The program has successfully integrated cloud computing into educational curricula across Thailand, providing students with direct access to AWS resources and hands-on experience. The impact has been substantial, with over 20,000 Thai students enrolled in the program. Beyond student education, AWS Educate has invested in training Thai educators, preparing them to deliver engaging and practical cloud computing courses that prepare students for the demands of the digital economy.

AWS Academy
AWS Academy has been instrumental in connecting academic learning with industry needs since its launch in Thailand in 2017. Through strategic partnerships with more than 30 leading universities and colleges across the country, AWS Academy has created a robust pipeline of cloud-skilled professionals. The program provides educational institutions with comprehensive cloud computing curricula that align with industry needs, making sure that students graduate with practical, job-ready skills.

Through these various initiatives and programs, AWS is not just providing educational resources, it’s building a foundation for Thailand’s digital future by helping equip the workforce with the necessary skills to use cloud technologies effectively.

Supporting sustainable innovation in Thailand
The AWS commitment to sustainability extends to supporting innovative companies in Thailand that are driving environmental initiatives.

BODA Technology & Consultancy
BODA, an AWS powered sustainability startup, uses AWS IoT Core to develop AI-powered solutions for energy efficiency optimization. The company has successfully improved operations in over 100,000 buildings and factories across Thailand, enabling these facilities to maximize efficiency while reducing costs and environmental impact.

GSPC Group
GSPC Group, a leading sustainable power company in Thailand, demonstrates how AWS supports the energy sector’s digital transformation. Following the merger between Global Power Synergy Public Company and Glow Energy, the group chose AWS Cloud for migrating its photovoltaic solar plant operations. Working with AWS and AWS Partner Dailitech, GSPC Group has achieved a 20–25 percent reduction in hardware, software, and licensing costs since moving to the cloud.

Things to know
AWS Community in Thailand — Thailand is home to two AWS Heroes, seven AWS Community Builders, and more than 17,000 members of the AWS User Group. If you’re interested in joining AWS User Group Thailand, visit their Facebook page.

AWS Global footprint — AWS now spans 111 Availability Zones within 35 geographic regions worldwide. We have announced plans for 15 more Availability Zones and five more AWS Regions in Germany, Taiwan, Mexico, the Kingdom of Saudi Arabia, and New Zealand. 

The new Asia Pacific (Thailand) Region is ready to support your business. To learn more, visit the AWS Global Infrastructure page and start building on ap-southeast-7!

Happy building!
— Donnie

Kicinski: netdev in 2024

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

Kernel networking maintainer Jakub Kicinski reviews progress in
the networking subsystem in 2024.

Work on relieving the rtnl_lock pressure has continued throughout
the year. The rtnl_lock is often mentioned as one of the biggest
global locks in the kernel, as it protects all of the network
configuration and state. The efforts can be divided into two broad
categories – converting read operations to rely on RCU protection
or other fine grained locking (v6.9, v6.10), and splitting the lock
into per-network namespace locks (preparations for which started in
v6.13).

2024 in retrospect (Gentoo News)

Post Syndicated from jzb original https://lwn.net/Articles/1004373/

Gentoo Linux has published a project
retrospective that looks at the major improvements and news from
2024, the Gentoo Foundation’s finances, and contributions to Gentoo by
the numbers.

The number of commits to the main ::gentoo
repository has remained at an overall high level in 2024, with a
2.4% increase from 121000 to 123942. The number of commits by external
contributors has grown strongly from 10708 to 12812, now across 421
unique external authors.

The importance of GURU, our
user-curated repository with a trusted user model, as entry point
for potential developers, is clearly increasing as well. We have had
7517 commits in 2024, a strong growth from 5045 in 2023. The number of
contributors to GURU has increased a lot as well, from 158 in 2023 to
241 in 2024. Please join us there and help packaging the latest and
greatest software.

Use CI/CD best practices to automate Amazon OpenSearch Service cluster management operations

Post Syndicated from Camille BIRBES original https://aws.amazon.com/blogs/big-data/use-ci-cd-best-practices-to-automate-amazon-opensearch-service-cluster-management-operations/

Quick and reliable access to information is crucial for making smart business decisions. That’s why companies are turning to Amazon OpenSearch Service to power their search and analytics capabilities. OpenSearch Service makes it straightforward to deploy, operate, and scale search systems in the cloud, enabling use cases like log analysis, application monitoring, and website search.

Efficiently managing OpenSearch Service indexes and cluster resources can lead to significant improvements in performance, scalability, and reliability – all of which directly impact a company’s bottom line. However, the industry lacks built-in and well-documented solutions to automate these important operational tasks.

Applying continuous integration and continuous deployment (CI/CD) to managing OpenSearch index resources can help do that. For instance, storing index configurations in a source repository allows for better tracking, collaboration, and rollback. Using infrastructure as code (IaC) tools can help automate resource creation, providing consistency and reducing manual work. Finally, using a CI/CD pipeline can automate deployments and streamline workflow.

In this post, we discuss two options to achieve this: the Terraform OpenSearch provider and the Evolution library. Which one is best suited to your use case depends on the tooling you are familiar with, your language of choice, and your existing pipeline.

Solution overview

Let’s walk through a straightforward implementation. For this use case, we use the AWS Cloud Development Kit (AWS CDK) to provision the relevant infrastructure as described in the following architecture diagram that follows, AWS Lambda to trigger Evolution scripts and AWS CodeBuild to apply Terraform files. You can find the code for the entire solution in the GitHub repo.

Solution Architecture Diagram

Prerequisites

To follow along with this post, you need to have the following:

  • Familiarity with Java and OpenSearch
  • Familiarity with the AWS CDK, Terraform, and the command line
  • The following software versions installed on your machine: Python 3.12, NodeJS 20, and AWS CDK 2.170.0 or higher
  • An AWS account, with an AWS Identity and Access Management (IAM) role configured with the relevant permissions

Build the solution

To build an automated solution for OpenSearch Service cluster management, follow these steps:

  1. Enter the following commands in a terminal to download the solution code; build the Java application; build the required Lambda layer; create an OpenSearch domain, two Lambda functions and a CodeBuild project; and deploy the code:
git clone https://github.com/aws-samples/opensearch-automated-cluster-management
cd opensearch-automated-cluster-management
cd app/openSearchMigration
mvn package
cd ../../lambda_layer
chmox a+x create_layer.sh
./create_layer.sh
cd ../infra
npm install
npx cdk bootstrap
aws iam create-service-linked-role --aws-service-name es.amazonaws.com
npx cdk deploy --require-approval never
  1. Wait 15 to 20 minutes for the infrastructure to finish deploying, then check that your OpenSearch domain is up and running, and that the Lambda function and CodeBuild project have been created, as shown in the following screenshots.

OpenSearch domain provisioned successfully OpenSearch Migration Lambda function created successfully OpenSearchQuery Lambda function created successfully CodeBuild project created successfully

Before you use automated tools to create index templates, you can verify that none already exist using the OpenSearchQuery Lambda function.

  1. On the Lambda console, navigate to the relevant Function
  2. On the Test tab, choose Test.

The function should return the message “No index patterns created by Terraform or Evolution,” as shown in the following screenshot.

Check that no index patterns have been created

Apply Terraform files

First, you use Terraform with CodeBuild. The code is ready for you to test, let’s look at a few important pieces of configuration:

  1. Define the required variables for your environment:
variable "OpenSearchDomainEndpoint" {
  type = string
  description = "OpenSearch domain URL"
}

variable "IAMRoleARN" {
  type = string
  description = "IAM Role ARN to interact with OpenSearch"
}
  1. Define and configure the provider
terraform {
  required_providers {
    opensearch = {
      source = "opensearch-project/opensearch"
      version = "2.3.1"
    }
  }
}

provider "opensearch" {
  url = "https://${var.OpenSearchDomainEndpoint}"
  aws_assume_role_arn = "${var.IAMRoleARN}"
}

NOTE: As of the publication date of this post, there is a bug in the Terraform OpenSearch provider that will trigger when launching your CodeBuild project and that will prevent successful execution. Until it is fixed, please use the following version:

terraform {
  required_providers {
    opensearch = {
      source = "gnuletik/opensearch"
      version = "2.7.0"
    }
  }
}
  1. Create an index template
resource "opensearch_index_template" "template_1" {
  name = "cicd_template_terraform"
  body = <<EOF
{
  "index_patterns": ["terraform_index_*"],
  "template": {
    "settings": {
      "number_of_shards": "1"
    },
    "mappings": {
        "_source": {
            "enabled": false
        },
        "properties": {
            "host_name": {
                "type": "keyword"
            },
            "created_at": {
                "type": "date",
                "format": "EEE MMM dd HH:mm:ss Z YYYY"
            }
        }
    }
  }
}
EOF
}

You are now ready to test.

  1. On the CodeBuild console, navigate to the relevant Project and choose Start Build.

The build should complete successfully, and you should see the following lines in the logs:

opensearch_index_template.template_1: Creating...
opensearch_index_template.template_1: Creation complete after 0s (id=cicd_template_terraform)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

You can check that the index template has been properly created using the same Lambda function as earlier, and should see the following results.

Terraform index properly created

Run Evolution scripts

In the next step, you use the Evolution library. The code is ready for you to test, let’s look at a few important pieces of code and configuration:

  1. To begin with, you need to add the latest version of the Evolution core library and AWS SDK as Maven dependencies. The full xml file is available in the GitHub repository; to check the Evolution library’s compatibility with different OpenSearch versions, see here.
<dependency>
    <groupId>com.senacor.elasticsearch.evolution</groupId>
    <artifactId>elasticsearch-evolution-core</artifactId>
    <version>0.6.0</version><!--check the latest version-->
</dependency>
<dependency>
   <groupId>software.amazon.awssdk</groupId>
   <artifactId>auth</artifactId>
</dependency>
  1. Create Evolution Bean and an AWS interceptor (which implements HttpRequestInterceptor).

Interceptors are open-ended mechanisms in which the SDK calls code that you write to inject behavior into the request and response lifecycle. The function of the AWS interceptor is to hook into the execution of API requests and create an AWS signed request stamped with proper IAM roles. You can use the following code to create your own implementation to sign all the requests made to OpenSearch within AWS.

  1. Create your own OpenSearch client to manage automatic creation of index, mappings, templates, and aliases.

The default ElasticSearch client that comes bundled in as part of the Maven dependency can’t be used to make PUT calls to the OpenSearch cluster. Therefore, you need to bypass the default REST client instance, and add a CallBack to the AwsRequestSigningInterceptor.

The following is a sample implementation:

private RestClient getOpenSearchEvolutionRestClient() {
    return RestClient.builder(getHttpHost())
        .setHttpClientConfigCallback(hacb -> 
            hacb.addInterceptorLast(getAwsRequestSigningInterceptor()))
        .build();
}
  1. Use the Evolution Bean to call your migrate method, which is responsible for initiating the migration of the scripts defined either using classpath or filepath:
public void executeOpensearchScripts() {
    ElasticsearchEvolution opensearchEvolution = ElasticsearchEvolution.configure()
        .setEnabled(true) // true or false
        .setLocations(Arrays.asList("classpath:opensearch_migration/base",
            "classpath:opensearch_migration/dev")) // List of all locations where scripts are located.
        .setHistoryIndex("opensearch_changelog") // Tracker index to store history of scripts executed.
        .setValidateOnMigrate(false) // true or false
        .setOutOfOrder(true) // true or false
        .setPlaceholders(Collections.singletonMap("env","dev")) // list of placeholders which will get replaced in the script during execution.
        .load(getElasticsearchEvolutionRestClient());
    opensearchEvolution.migrate();
}
  1. An Evolution migration script represents a REST call to the OpenSearch API (for example, PUT /_index_template/cicd_template_evolution), where you define index patterns, settings, and mappings in JSON format. Evolution interprets these scripts, manages their versioning, and provides ordered execution. See the following example:
PUT /_index_template/cicd_template_evolution
Content-Type: application/json

{
  "index_patterns": ["evolution_index_*"],
  "template": {
    "settings": {
      "number_of_shards": "1"
    },
    "mappings": {
        "_source": {
            "enabled": false
        },
        "properties": {
            "host_name": {
                "type": "keyword"
            },
            "created_at": {
                "type": "date",
                "format": "EEE MMM dd HH:mm:ss Z YYYY"
            }
        }
    }
  }
}

The first two lines must be followed by a blank line. Evolution also supports comment lines in its migration scripts. Every line starting with # or // will be interpreted as a comment-line. Comment lines aren’t sent to OpenSearch. Instead, they are filtered by Evolution.

The migration script file naming convention must follow a pattern:

  • Start with esMigrationPrefix which is by default V or the value that has been configured using the configuration option esMigrationPrefix
  • Followed by a version number, which must be numeric and can be structured by separating the version parts with a period (.)
  • Followed by the versionDescriptionSeparator: __ (the double underscore symbol)
  • Followed by a description, which can be any text your filesystem supports
  • End with esMigrationSuffixes which is by default .http and is configurable and case insensitive

You’re now ready to execute your first automated change. An example of a migration script has already been created for you, which you can refer to in a previous section. It will create an index template named cicd_template_evolution.

  1. On the Lambda console, navigate to your function.
  2. On the Test tab, choose Test.

After a few seconds, the function should successfully complete. You can review the log output in the Details section, as shown in the following screenshots.

Migration function finish successfully

The index template now exists, and you can check that its configuration is indeed in line with the script, as shown in the following screenshot.

Evolution index template properly created

Clean up

To clean up the resources that were created as part of this post, run the following commands (in the infra folder):

npx cdk destroy --all

Conclusion

In this post, we demonstrated how to automate OpenSearch index templates using CI/CD practices and tools such as Terraform or the Evolution library.

To learn more about OpenSearch Service, refer to the Amazon OpenSearch Service Developer Guide. To further explore the Evolution library, refer to the documentation. To learn more about the Terraform OpenSearch provider, refer to the documentation.

We hope this detailed guide and accompanying code will help you get started. Try it out, let us know your thoughts in the comments section, and feel free to reach out to us for questions!

About the Authors

Camille BirbesCamille Birbes is a Senior Solutions Architect with AWS and is based in Hong Kong. He works with major financial institutions to design and build secure, scalable, and highly available solutions in the cloud. Outside of work, Camille enjoys any form of gaming, from board games to the latest video game.

Sriharsha Subramanya Begolli works as a Senior Solutions Architect with AWS, based in Bengaluru, India. His primary focus is assisting large enterprise customers in modernizing their applications and developing cloud-based systems to meet their business objectives. His expertise lies in the domains of data and analytics.

Security updates for Tuesday

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

Security updates have been issued by AlmaLinux (python-requests), Oracle (python-requests), SUSE (python-Jinja2 and rizin), and Ubuntu (ceph, linux, linux-aws, linux-aws-hwe, linux-gcp, linux-gcp-4.15, linux-hwe,
linux-kvm, linux-oracle, linux, linux-lts-xenial, linux-aws, linux-aws-5.15, linux-gcp, linux-gcp-5.15, linux-hwe-5.15,
linux-nvidia, linux-oracle, linux-raspi, linux-aws, linux-kvm, linux-hwe-6.8, linux-intel-iotg, linux-oem-6.11, linux-raspi-5.4, and salt).

Backblaze Adds Canadian Region, Expanding Location Choices and Data Sovereignty Options

Post Syndicated from Chris Opat original https://www.backblaze.com/blog/backblaze-adds-canadian-region-expanding-location-choices-and-data-sovereignty-options/

A decorative image showing Backblaze data regions, represented as clouds, around the planet.

Customers that have data governance, compliance, and performance at top of mind have more options for achieving all three with the opening of our new data region, known as Canada East (or CA East). The region is now available for current and future Backblaze customers.  

This new region builds on our mission to deliver high-performance, compliant, and cost-effective cloud storage solutions to businesses around the world and further expands our footprint in the North American market.

Meeting the needs of Canadian businesses

Our new CA East region is located in Toronto, Ontario, and has been designed to address the specific needs of Canadian businesses and organizations, many of which are subject to laws and regulations requiring data to be stored within the country. With this expansion, customers are able to ensure compliance with local regulations while taking advantage of a robust cloud solution that prioritizes data sovereignty. 

A local region also delivers performance benefits for Canadian customers. By reducing the distance that data needs to travel, Backblaze can offer lower latency and improved speeds for Canadian customers, making it ideal for real-time applications and large-scale data transfers.

Strengthening our partnership with Opti9

In collaboration with Opti9, an international leader in hybrid cloud solutions and a Veeam Cloud Storage Provider (VCSP), this expansion marks a significant opportunity for us to deliver robust managed services to Canadian businesses. Opti9, as the exclusive Canadian channel partner for Backblaze B2 Reserve and the Powered by Backblaze program, is uniquely positioned to bring this enhanced offering to market.

Opti9 and Backblaze share a unified vision of providing Canadian businesses and organizations with cutting-edge cloud solutions that are both affordable and high performing. Cloud data storage is evolving rapidly to meet changing customer needs. We are excited to launch this Canadian storage region in collaboration with Backblaze, which expands our overall cloud storage footprint in Canada. This partnership equips our Canadian partners and end-user organizations with the tools they need to thrive in today’s fast-evolving digital landscape.

—Cory Mac Donell, Vice President of Sales & Business Development, Opti9

Protecting data within borders

Canada’s cloud services market is expanding rapidly, driven by increased demand from industries such as healthcare, finance, and government—all of which often require data to remain within national borders. The new data region gives Canadian and international businesses more choice for storing their data while maintaining data sovereignty.

Competitive edge through open cloud solutions

Multi-cloud and hybrid cloud strategies are becoming all the more common. Businesses increasingly seek open, interoperable solutions that avoid vendor lock-in and allow them to integrate the best services from multiple providers and our offerings provide the flexibility and control businesses need, while still benefiting from the security, compliance, data governance requirements, and performance of a local data center. The new region enables companies doing business in Canada to tap into multi-cloud and hybrid cloud strategies as they look to strengthen their cloud infrastructure.

Security and compliance details for the Canadian region

The Toronto data center has been assessed and maintains a security program that addresses the requirements of SOC 1 Type 2, SOC 2 Type 2, ISO 27001, PCI DSS, and HIPAA. These certifications ensure the highest levels of security and compliance for businesses in regulated industries. 

Ready to store data in CA East?

The new data region is available to customers now, and you can create an account there by selecting CA East in the region drop-down when creating a Backblaze account. Already storying data with Backblaze and want to keep a Canadian copy? Leverage our Cloud Replication feature and diversify your storage. 

We’ll have more stories to tell about bringing up the data center and some of the interesting networking there, so stay tuned to the blog!

The post Backblaze Adds Canadian Region, Expanding Location Choices and Data Sovereignty Options appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Rapid7 Recognized with Top Score of 100 in 2025 Corporate Equality Index

Post Syndicated from Rapid7 original https://blog.rapid7.com/2025/01/07/rapid7-recognized-with-top-score-of-100-in-2025-corporate-equality-index/

Rapid7 Recognized with Top Score of 100 in 2025 Corporate Equality Index

On January 7, the Human Rights Campaign Foundation released their 2025 Corporate Equality Index (CEI), where Rapid7 earned a top score of 100.

The CEI is the nation’s leading benchmark for LGBTQ+ workforce equality, evaluating policies and practices in areas such as non-discrimination, equitable benefits, inclusive cultures, and corporate social responsibility. With this score, Rapid7 is recognized as a leader in LGBTQ+ Workplace Inclusion.

This recognition reflects Rapid7’s core value; and our commitment to creating a dynamic workplace where all people can build a rewarding career. Our core value  ‘Bring You’ is an invitation for everyone to embrace their uniqueness and bring their true selves to the workplace. We know that fostering a culture of inclusion enables people to be more creative and generate innovative ideas – essential skills when working in the field of cybersecurity. Additionally, we recognize that our work in this space is truly ‘Never Done’. We continuously evaluate, optimize, and seek feedback on programs and practices that support diversity, equity, and inclusion across the business. We’re proud of this recognition, and will continue to work towards building and maintaining a workplace where all people have access to the tools, resources, and communities that enable them to feel seen and valued, so they can make an incredible impact through their work.

In consideration for this recognition, the CEI examined Rapid7’s practices and policies against four core pillars:

• Non-discrimination policies across business entities

• Equitable benefits for LGBTQ+ workers and their families

• Supporting an inclusive culture; and,

• Corporate social responsibility

“HRC Equality Index recognition reflects a gold standard, one that ensures employees—regardless of their lived experience—have equitable access to benefits and are treated inclusively. We alignwith the HRC Equality Index standard, as we believe it fosters an environment that enables employees to bring their authentic selves to work. By cultivating an environment that nutures this dynamic, we empower our people to perform at their best and contribute meaningfully to the success of our business.

Additionally, achieving recognition on the HRC Equality Index underscores our broader commitment to being an employer who strives to reflect the global community we seek to secure. This milestone also highlights how essential equity is to our mission. Equity is a key part of the equation, and it is vital that we never lose sight of its importance.

I am incredibly proud that we are included on the index this year. This achievement reflects our ongoing commitment to fostering innovation, belonging, and excellence in all that we do.”

In addition to offering equitable benefits, Rapid7’s employee resource groups provide opportunities for people to come together around shared experiences. The Pride community provides space for LGBTQ+ employees and their allies to raise visibility and provide support through various virtual and in-office events. These initiatives include hosting external speakers, facilitating open discussions, and organizing celebrations.

To learn more about Rapid7 as a workplace, visit our careers page today.

US Treasury Department Sanctions Chinese Company Over Cyberattacks

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/01/us-treasury-department-sanctions-chinese-company-over-cyberattacks.html

From the Washington Post:

The sanctions target Beijing Integrity Technology Group, which U.S. officials say employed workers responsible for the Flax Typhoon attacks which compromised devices including routers and internet-enabled cameras to infiltrate government and industrial targets in the United States, Taiwan, Europe and elsewhere.

Title Launch Observability at Netflix Scale

Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/title-launch-observability-at-netflix-scale-19ea916be1ed

Part 2: Navigating Ambiguity

By: Varun Khaitan

With special thanks to my stunning colleagues: Mallika Rao, Esmir Mesic, Hugo Marques

Building on the foundation laid in Part 1, where we explored the “what” behind the challenges of title launch observability at Netflix, this post shifts focus to the “how.” How do we ensure every title launches seamlessly and remains discoverable by the right audience?

In the dynamic world of technology, it’s tempting to leap into problem-solving mode. But the key to lasting success lies in taking a step back — understanding the broader context before diving into solutions. This thoughtful approach doesn’t just address immediate hurdles; it builds the resilience and scalability needed for the future. Let’s explore how this mindset drives results.

Understanding the Bigger Picture

Let’s take a comprehensive look at all the elements involved and how they interconnect. We should aim to address questions such as: What is vital to the business? Which aspects of the problem are essential to resolve? And how did we arrive at this point?

This process involves:

  1. Identifying Stakeholders: Determine who is impacted by the issue and whose input is crucial for a successful resolution. In this case, the main stakeholders are:

    – Title Launch Operators
    Role:     Responsible for setting up the title and its metadata into our systems.
    Challenge: Don’t understand the cascading effects of their setup on these perceived black box personalization systems

    – Personalization System Engineers
    Role: Develop and operate the personalization systems.
    Challenge: End up spending unplanned cycles on title launch and personalization investigations.

    – Product Managers
    Role: Ensure we put forward the best experience for our members.
    Challenge: Members may not connect with the most relevant title.

    – Creative Representatives
    Role: Mediator between the content creators and Netflix.
    Challenge: Build trust in the Netflix brand with content creators.

  2. Mapping the Current Landscape: By charting the existing landscape, we can pinpoint areas ripe for improvement and steer clear of redundant efforts. Beyond the scattered solutions and makeshift scripts, it became evident that there was no established solution for title launch observability. This suggests that this area has been neglected for quite some time and likely requires significant investment. This situation presents both challenges and opportunities; while it may be more difficult to make initial progress, there are plenty of easy wins to capitalize on.
  3. Clarifying the Core Problem: By clearly defining the problem, we can ensure that our solutions address the root cause rather than just the symptoms. While there were many issues and problems we could address, the core problem here was to make sure every title was treated fairly by our personalization stack. If we can ensure fair treatment with confidence and bring that visibility to all our stakeholders, we can address all their challenges.
  4. Assessing Business Priorities: Understanding what is most important to the organization helps prioritize actions and resources effectively. In this context, we’re focused on developing systems that ensure successful title launches, build trust between content creators and our brand, and reduce engineering operational overhead. While this is a critical business need and we definitely should solve it, it’s essential to evaluate how it stacks up against other priorities across different areas of the organization.

Defining Title Health

Navigating such an ambiguous space required a shared understanding to foster clarity and collaboration. To address this, we introduced the term “Title Health,” a concept designed to help us communicate effectively and capture the nuances of maintaining each title’s visibility and performance. This shared language became a foundation for discussing the complexities of this domain.

“Title Health” encompasses various metrics and indicators that reflect how well a title is performing, in terms of discoverability and member engagement. The three main questions we try to answer are:

  1. Is this title visible at all to any member?
  2. Is this title visible to an appropriate audience size?
  3. Is this title reaching all the appropriate audiences?

Defining Title Health provided a framework to monitor and optimize each title’s lifecycle. It allowed us to align with partners on principles and requirements before building solutions, ensuring every title reaches its intended audience seamlessly. This common language not only introduced the problem space effectively but also accelerated collaboration and decision-making across teams.

Categories of issues

To build a robust plan for title launch observability, we first needed to categorize the types of issues we encounter. This structured approach allows us to address all aspects of title health comprehensively.

Currently, these issues are grouped into three primary categories:

1. Title Setup

A title’s setup includes essential attributes like metadata (e.g., launch dates, audio and subtitle languages, editorial tags) and assets (e.g., artwork, trailers, supplemental messages). These elements are critical for a title’s eligibility in a row, accurate personalization, and an engaging presentation. Since these attributes feed directly into algorithms, any delays or inaccuracies can ripple through the system.

The observability system must ensure that title setup is complete and validated in a timely manner, identify potential bottlenecks and ensure a smooth launch process.

2. Personalization Systems

Titles are eligible to be recommended across multiple canvases on product — HomePage, Coming Soon, Messaging, Search and more. Personalization systems handle the recommendation and serving of titles on these canvases, leveraging a vast ecosystem of microservices, caches, databases, code, and configurations to build these product canvases.

We aim to validate that titles are eligible in all appropriate product canvases across the end to end personalization stack during all of the title’s launch phases.

3. Algorithms

Complex algorithms drive each personalized product experience, recommending titles tailored to individual members. Observability here means validating the accuracy of algorithmic recommendations for all titles.
Algorithmic performance can be affected by various factors, such as model shortcomings, incomplete or inaccurate input signals, feature anomalies, or interactions between titles. Identifying and addressing these issues ensures that recommendations remain precise and effective.

By categorizing issues into these areas, we can systematically address challenges and deliver a reliable, personalized experience for every title on our platform.

Issue Analysis

Let’s also learn more about how often we see each of these types of issues and how much effort it takes to fix them once they come up.

From the above chart, we see that setup issues are the most common but they are also easy to fix since it’s relatively straightforward to go back and rectify a title’s metadata. System issues, which mostly manifest as bugs in our personalization microservices are not uncommon, and they take moderate effort to address. Algorithm issues, while rare, are really difficult to address since these often involve interpreting and retraining complex machine learning models.

Evaluating Our Options

Now that we understand more deeply about the problems we want to address and how we should go about prioritizing our resources. Lets go back to the two options we discussed in Part 1, and make an informed decision.

Ultimately, we realized this space demands the full spectrum of features we’ve discussed. But the question remained: Where do we start?
After careful consideration, we chose to focus on proactive issue detection first. Catching problems before launch offered the greatest potential for business impact, ensuring smoother launches, better member experiences, and stronger system reliability.

This decision wasn’t just about solving today’s challenges — it was about laying the foundation for a scalable, robust system that can grow with the complexities of our ever-evolving platform.

Up next

In the next iteration we will talk about how to design an observability endpoint that works for all personalization systems. What are the main things to keep in mind while creating a microservice API endpoint? How do we ensure standardization? What is the architecture of the systems involved?

Keep an eye out for our next binge-worthy episode!

Title Launch Observability at Netflix Scale was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The collective thoughts of the interwebz