Category: Blogs

  • Hashicorp Versus OpenTofu Gets Ugly

    Hashicorp Versus OpenTofu Gets Ugly

    When HashiCorp dumped its open-source Mozilla license for the Business Source License (BSL 1.1) for its flagship program, infrastructure as code (IaC) tool Terraform, many Terraform developers and partners were ticked off. As open source developers are wont to do in such situations, they created a Terraform fork, called OpenTofu.

    So far, that’s business as usual when a company shifts a project away from open source. Things heated up, though, when the Linux Foundation announced it would support the new fork. Now, the conflict between HashiCorp and OpenTofu is starting to boil, as HashiCorp accused OpenTofu of “not respecting the terms of its BSL license governing its Terraform codebase.”

    Them’s fighting words!

    OpenTofu replied, “OpenTofu vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code.” The organization added, “HashiCorp may be conflating code that it had previously been open-sourced under the MPL and more recently developed code it published under the BSL.” And, OpenTofu says, it will “issue a written response providing a more detailed explanation of its position.”

    So, what is this code in question? Neither Hashicorp nor Terraform is saying, quite yet. However, it appears to be a “removed block” automation process that enables Terraform to manage resource deletion.

    Matt Asay, MongoDB‘s VP of Developer Relations, revealed this accusation. He accused OpenTofu of lifting the “removed block” code, which was released under the BSL a few months after the OpenTofu fork was created. “The tell? OpenTofu took this BUSL-licensed HashiCorp code, removed the headers, and tried to instead relicense it under the Mozilla Public License (MPL 2.0),” Asay wrote.

    Oh, it’s on now.

    Even before news of the legally threatening message emerged, prominent open source leaders attacked Asay’s claim. Bryan Cantrill, the hyper-cloud Oxide Computer co-founder and CTO, claimed, “This is an extraordinarily serious accusation – and the cited files frankly don’t substantiate it.”

    Cantrill is far from alone in thinking that there is insufficient evidence to justify the accusation that OpenTofu has stolen any code. Until we have harder evidence, the issue will remain a case of “He said, she said.”

    Chris Aniszczyk, the CTO of the Cloud Native Computing Foundation (CNCF), a Linux Foundation-related organization, doesn’t think it’s a good look for HashiCorp. He said it’s “embarrassing to see a company light all of its hard-earned developer reputation on fire, on top of attacking open source.”

    Dan Lorenc, CEO and co-founder of Chainguard, a software supply chain security company, warns this could be the start of something big and ugly in software development circles. “I don’t have any philosophical or ethical issues with source-available licenses, but their proponents are going to have to address these cease-and-desist threats,” he wrote. “Developers working in OSS (OSI/FSF approved licenses) are going to be prevented from engaging with or even looking at source-available projects completely to prevent the risk of lawsuits. It’s just too risky to pretend otherwise.”

    Lorenc adds, “There’s no gradual transition here, it’s going to be a hard fork in communities if these lawsuit threats keep continuing. And I know which community I’d bet on sticking around.”

    I lived through the SCO-Linux copyright wars. I think I know who will win, too.

    Photo credit: Quino Al on Unsplash

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com provides a weekly DevOps jobs report through which opportunities for DevOps professionals are highlighted, as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it just that much easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    CareerBuilder.com

    Insight Global
    Chantilly, VA
    Cloud DevOps Engineer
    $140,000

    Indeed.com

    General Motors
    Warren, MI
    Senior DevOps Engineer
    $128,900 to $232,900

    SimplyHired.com

    Maxar Technologies
    Springfield, VA
    DevOps Engineer
    $131,000 to $219,000

    Dice.com

    Adobe
    San Jose, CA
    DevOps Engineer
    $124,000 to $234,000

    LinkedIn

    Ascendion
    Seattle, WA
    DevOps/Platform Engineer
    $100,000 to $135,000

  • Dynatrace Elevates IT Sustainability

    Dynatrace Elevates IT Sustainability

    Dynatrace’s Carbon Impact App

    Dynatrace, in collaboration with Lloyds Banking Group, has taken a bold step forward with the Carbon Impact app. This initiative represents a significant advancement in addressing the environmental impact of IT operations. Addressing a critical gap in the tech industry’s approach to environmental responsibility, Klaus Enzenhofer, Product Lead Business Analytics at Dynatrace, encapsulates this progress: “Dynatrace successfully rolled out the Carbon Impact app last year, and we’ve been working with Lloyds Banking Group to develop it further to support our customers’ hybrid and multicloud environments. This has allowed us to accelerate and focus on our product development while helping our customers meet their sustainability goals.”

    Techstrong TV’s Bonnie Schneider speaks with Klaus Enzenhofer, Product Lead Business Analytics, Dynatrace, about their Carbon Impact App. Click the image above to watch the full interview.

     

    How Does the Carbon Impact App Work?

    Understanding the operational intricacies of the Carbon Impact app reveals why it’s a game-changer. It functions by meticulously monitoring the energy consumption of IT assets, whether they reside on-premises, in the cloud, or within a hybrid setup. This data is then converted into CO2e metrics, providing a tangible measure of the environmental impact. What sets the Carbon Impact app apart is its ability to deliver these insights in real-time, offering a dynamic and granular view of where and how emissions are generated.

     

    Instances: Where should you focus your attention?

    From Dynatrace: The Instances view details energy and CO2e consumption per host instance. Filters help narrow your focus. For example, you could view underutilized instances in a specific AWS data center or top CO2e emitters within a specific host group. Because Carbon Impact automatically connects to Dynatrace Smartscape® topology modeling, it’s easy to drill into host and process details. Or you can open Notebooks for ad hoc analysis, arming your teams with the insights needed to evaluate opportunities to reduce carbon emissions.

     

    Synergy Between Dynatrace and Lloyds Banking Group

    The collaboration between Dynatrace and Lloyds Banking Group amplifies the app’s impact. Together, they’ve fine-tuned the app to cater to the specific needs of hybrid and multicloud environments, ensuring that companies operating within these complex IT landscapes can achieve their sustainability objectives more effectively. This partnership not only highlights the potential for tech innovations to drive environmental sustainability but also serves as a model for how corporations can work together towards a greener future.

    Beyond Carbon Tracking: A Tool for Strategic Decision-Making

    The implications of the Carbon Impact app extend beyond mere monitoring and reporting. It serves as a strategic tool, guiding companies on how to reconfigure their IT operations for reduced environmental impact. Whether it’s identifying underutilized resources, optimizing server allocations, or making the switch to greener cloud providers, the app offers actionable insights that can lead to significant reductions in carbon emissions.

    A Call to Action for the Tech Industry

    Dynatrace’s initiative, backed by the support from Lloyds Banking Group, marks a pivotal moment in the tech industry’s journey towards sustainability. It underscores the critical role that technology can play in solving some of the most pressing environmental challenges. More importantly, it serves as a call to action for other tech companies to follow suit. By providing a means to accurately measure and manage the carbon footprint of IT operations, it offers a path forward for organizations looking to reconcile their digital transformation efforts with their environmental responsibilities.

     

  • Mastering AWS Troubleshooting: A Deep Dive Into Debugging Queue Message Age Alerts

    Mastering AWS Troubleshooting: A Deep Dive Into Debugging Queue Message Age Alerts

    Quiz #23 was:

    As a seasoned Site Reliability Engineer, you’ve encountered an alert indicating that the “worker-prod queue message age” has exceeded its threshold. This alarm could potentially impact the system’s performance and reliability. To effectively troubleshoot and address this issue, which of the following steps should you prioritize?

    1) Increase the number of EC2 instances running the worker service to scale up the processing power, assuming the worker service is under-provisioned.

    2) Immediately clear all messages from the “worker-prod” queue to reset the message age metric, assuming the messages are outdated or irrelevant.

    3) Review CloudWatch metrics and logs for the “worker-prod” service to identify any recent changes in error rates or execution times that could be delaying message processing.

    4) Temporarily disable the AWS alarm for “worker-prod queue message age” to avoid receiving further alerts while you investigate unrelated system components.

    5) Manually execute the worker service’s tasks to process the queue messages, assuming the automated process has failed.

    Correct Answer: 3) Review CloudWatch metrics and logs for the “worker-prod” service to identify any recent changes in error rates or execution times that could be delaying message processing.

    Rationale: The most effective initial step in debugging the “worker-prod queue message age” alarm is to analyze the CloudWatch metrics and logs for the worker service. This approach allows you to pinpoint any recent changes or anomalies in the service’s behavior, such as increased error rates or longer execution times, which could be contributing to the delayed processing of queue messages. Understanding the root cause is essential for implementing a targeted and effective solution, unlike the other options which might temporarily mitigate symptoms without addressing the underlying issue.

    116 people answered this question and 14% got it right.

    In the realm of cloud computing, especially within AWS environments, SREs (Site Reliability Engineers) face a myriad of challenges daily. One such challenge is effectively troubleshooting and resolving alerts like the “worker-prod queue message age” without disrupting the system’s performance. This blog aims to dissect this issue, analyze potential responses, and illustrate why a particular strategy outshines the others. Along the way, we’ll tackle the complexities involved in each approach and offer code snippets to enrich your troubleshooting toolkit.

    The Challenge At Hand

    When an alert for “worker-prod queue message age” pops up, it signals that messages within the queue are not being processed swiftly enough. This lag can lead to performance bottlenecks, customer dissatisfaction, and potentially severe system failures. How we approach this problem is crucial, and here’s a breakdown of potential actions:

    Option A: Increasing EC2 instances to enhance processing power seems like a straightforward solution. However, it’s a bit like adding more horsepower to an already overloaded truck without first checking if the load can be redistributed or lightened. It’s essential, but it doesn’t address the root cause. In this manner this quiz is similar to our previous quiz on AWS ELB Performance.

    Code Snippet for Scaling EC2 Instances:

    import boto3

    # Initialize a boto3 client

    ec2 = boto3.client(‘ec2′, region_name=’your-region’)

    # Scale up EC2 instances

    ec2.modify_auto_scaling_group(AutoScalingGroupName=’your-auto-scaling-group-name’,DesiredCapacity=new_desired_capacity)

    Option B: Clearing the queue might offer temporary relief but could lead to data loss or further issues down the line. It’s akin to wiping the slate clean without learning from the errors written on it.

    Option C: This is where the gold lies. Diving into CloudWatch metrics and logs can reveal patterns, spikes in error rates, or increases in execution time, offering clues to the underlying issue. It’s detective work that requires patience and keen insight. But what if an AI could do this for us – this is precisely what Webb.ai’s solution does. It leverages AI to automate troubleshooting identifying the root cause. Try it:

    Troubleshooting modern cloud environments is hard and expensive. There are too many alerts, too many changes, and too many components. That’s why Webb.ai uses AI to automate troubleshooting. See for yourself how you can become 10x more productive by letting AI conduct troubleshooting to find the root cause of the alert: Early Access Program. It uses an intuitive approach based on first principles so it is easy to follow and for every step of troubleshooting it provides the commands that you can copy and run in your environment to verify the findings.

    Code Snippet for Reviewing CloudWatch Logs:

    import boto3

    # Initialize a boto3 client

    logs = boto3.client(‘logs’, region_name=’your-region’)

    # Fetch logs for analysis response = logs.filter_log_events(

    logGroupName=’your-log-group-name’,

    startTime=unix_start_time,

    endTime=unix_end_time,

    filterPattern=’ERROR’

    )

    print(response[‘events’])

    Option D: Disabling the alarm might silence the noise, but it’s equivalent to ignoring the check engine light on your dashboard. It doesn’t solve anything and could lead to more significant problems.

    Option E: Manual intervention might fix the immediate issue but fails to offer a scalable or long-term solution. It’s a band-aid on a potentially gaping wound.

    Why Option C Reigns Supreme

    Option C is the clear winner because it encourages a methodical, data-driven approach to problem-solving. By analyzing CloudWatch metrics and logs, SREs can identify the root cause of the delayed queue message processing. This approach not only solves the immediate problem but also aids in the development of more resilient systems by providing insights into how similar issues can be prevented in the future.

    The Complexity Of Analysis

    Each option presents its own set of challenges. For instance, scaling EC2 instances (Option A) requires a good understanding of the system’s load and capacity planning. Clearing the queue (Option B) might necessitate data recovery strategies, while manually processing tasks (Option E) could involve complex script writing. Disabling the alarm (Option D) is the least desirable, as it avoids addressing the issue altogether.

    In conclusion, troubleshooting the “worker-prod queue message age” alarm in AWS requires a blend of tactical decision-making and strategic analysis. By opting for a data-driven approach and diving into CloudWatch metrics and logs, SREs can not only address the immediate issue but also enhance their system’s reliability and performance. Remember, the key to effective troubleshooting is not just fixing problems as they arise but preventing them from occurring in the first place.

    Troubleshooting modern cloud environments is hard and expensive. There are too many alerts, too many changes, and too many components. That’s why Webb.ai uses AI to automate troubleshooting. See for yourself how you can become 10x more productive by letting AI conduct troubleshooting to find the root cause of the alert: Early Access Program.

  • Center Identity Launches Patented Passwordless Authentication for Businesses

    Center Identity Launches Patented Passwordless Authentication for Businesses

    Portland, Oregon, April 4th, 2024, CyberNewsWire

    Center Identity, a pioneering cybersecurity company, is excited to unveil its patented secret location authentication, reshaping how businesses manage workforce digital identity. This proprietary technology enables users to authenticate their identity using a secret location selected on a map.

    The benefits of this novel approach to digital identity management include:

    ● Simplicity: There is no need to remember a long list of complicated passwords or seed phrases.

    ● Security: Secret locations are less likely to be shared and far less susceptible to brute force hacking.

    ● Recovery: The use of Artificial Intelligence ensures that hints for selected secret locations meet robust cybersecurity standards, offering users an easy recovery mechanism.

    Compared with other passwordless authentication solutions which require the user to possess one or more hardware devices, secret locations are a cost effective solution which do not require purchasing devices for your entire workforce. Center Identity is also launching the integration of secret location authentication with OpenID Connect, a widely adopted open standard, making integration a straightforward process.

    “Traditional password management and account recovery methods fail to keep pace with the rising tide of security threats. Our secret location-based algorithm changes all that by authenticating based on geo-coordinates. Users only need to remember a place of personal significance, which is both intuitive and incredibly secure,” says Matt Vogel, Founder and CTO of Center Identity.

    Moreover, Center Identity addresses the security concerns of businesses with stringent endpoint security measures, taking advantage of firewalls and VPNs to enhance protection even further. “Our technology allows these organizations to block satellite map traffic based on which website the user is on, effectively neutralizing the threat of phishing by ensuring that only whitelisted websites can access map-based authentication services,” says Vogel.

    This new protocol transforms access management in a way that mitigates the risks and reduces the hassles associated with traditional password-based systems. “We know that businesses lose around 30% of their time resetting passwords. Our solution not only plugs this productivity drain, but also enhances security without compromising convenience,” adds Vogel.

    Users and businesses can visit Center Identity’s passwordless solutions here.

    About Center Identity

    Center Identity is a pioneering cybersecurity company based in the United States with a patented approach to digital identity management. Leveraging cutting-edge solutions and blockchain technology, the expert team at Center Identity ensures unparalleled security for data and networks, empowering both individuals and businesses to navigate the digital landscape with confidence.

    About Matt Vogel

    Matt Vogel is a distinguished software engineer with a profound impact on digital security, holding key patents in digital identity, cybersecurity, and artificial intelligence. His contributions have significantly influenced technological standards and innovations. As a recognized author and advisor, Vogel’s expertise has been instrumental in shaping industry discourse and guiding the future of technology.

    For more information users can visit.

    Contact

    Stoyan Bojinov
    pr@centeridentity.com