Tag: devops

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    staging-devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it 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 being 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

    Cognizant Technology Solutions
    Phoenix, Arizona
    Senior DevOps Architect
    $130,000 to $180,000

    Indeed.com

    IBM
    Research Triangle Park, North Carolina
    SAP DevSecOps SME
    $126,000 to $235,000

    Dice.com

    DGN Technologies
    Dallas, Texas
    Azure DevOps Engineer
    $110,000 to $115,000

    SimplyHired.com

    Sabre Systems
    Lexington Park, Maryland
    Cloud Engineer – DevOps
    $106,000 to $134,000

    LinkedIn

    Deloitte
    Miami – Fort Lauderdale, Florida
    Junior Cloud Infrastructure Architect
    $65,000 to $97,000

  • The Great CentOS Linux Migration: How We Got Here and What’s Next

    The Great CentOS Linux Migration: How We Got Here and What’s Next

    The recent news regarding Red Hat’s decision to limit access to the source code of their Red Hat Enterprise Linux (RHEL) distribution has garnered considerable attention. In order to understand the ramifications and subsequent changes, it is important to look back at CentOS, its historical alignment with RHEL and the options moving forward.

    CentOS Then and Now

    Starting in 2004, right from its inception, every iteration of the commercial RHEL offering triggered a corresponding release of CentOS. These iterations mirrored RHEL, albeit with modifications to eliminate the Red Hat branding and other minor updates. The presence of open source CentOS Linux facilitated swift installation of a free RHEL variant, rendering it accessible for diverse purposes spanning from development to production environments.

    In January 2014, Red Hat joined the CentOS project. Under a new CentOS governing board, they became the main sponsor and driver of the CentOS project. They continued to be an open source downstream alternative to RHEL.

    On December 8, 2020, the CentOS project and Red Hat set a new end-of-life (EOL) date for CentOS Linux 8. They shifted focus and investment into a new Linux distribution, CentOS Stream, with a rolling release model. EOL means that the community stops releases regardless of the severity of a bug or a vulnerability. Today, CentOS versions 6 and 8 are already EOL, and version 7 is the last, with EOL set for June 30, 2024. This announcement immediately sparked new projects to fill the CentOS gap. New open source projects such as Rocky Linux and AlmaLinux took off quickly, gaining contributors, sponsors and users.

    Fast forward to June 21, 2023, when Red Hat announced it would no longer publicly publish RHEL on git.centos.org.

    Previously, the source code was accessible to all, and it was used by various RHEL-compatible alternative open source projects such as Rocky Linux and AlmaLinux. It also affected other distributions, including Oracle Linux, which was a RHEL derivative for many years. All of these open source Linux distributions offered an alternative for applications; they were equally compatible with both free open source Linux and the commercial RHEL offering.

    According to the 2023 State of Open Source Report, 15% of all organizations and 20% of large organizations globally still have CentOS Linux deployed in their environments. Organizations have to move off EOL CentOS 6 and 8 and, in less than a year, off CentOS 7. Running EOL versions of any software can pose a substantial risk and cause failure in IT internal and external compliance. New vulnerabilities are constantly disclosed, and without updates or patches to CentOS, it is critical to plan for the “Great CentOS Linux Migration.”

    CentOS Migration Planning and Challenges

    Migration can be challenging. If organizations have legacy applications, they might encounter significant challenges making them work properly on a different Linux distribution. Even a small change in the individual packages that form the Linux distribution can impact and delay testing. While every application is different, and many are not dependent on low-level Linux functions, others could be significantly impacted. The number of CentOS deployments and applications has an exponential impact on the migration efforts. Evaluating different Linux distributions also takes time and will depend on the use cases, the skills developers have within each organization and the results of testing. The actual installation of a new Linux distribution is the easy part—the testing of all the layers on top of the operating system is what will take time. Some might be straightforward while others will require significant changes. Those are the reasons why it is helpful to stay with compatible distributions that will minimize the migration challenges.

    As organizations navigate the CentOS EOL and the migration period, it will be helpful to find options to extend CentOS long-term support. This means finding the expertise to generate patches that address newly disclosed high-severity vulnerabilities post-EOL. In other words, organizations must expand the community’s long-term support to address security.

    Wait for What’s Next

    The biggest question about alternative distributions is how closely they resemble RHEL. Are they going to continue to be bug-for-bug compatible? Or are there enough differences to no longer consider them application-compatible? The Rocky Linux Enterprise Software Foundation announced its plan to access RHEL source code and its intentions to continue to be bug-for-bug compatible. AlmaLinux OS Foundation announced a different approach. It is working with the CentOS Stream community while maintaining binary compatibility. This means not strictly bug-for-bug but focusing on applications to continue to be compatible.

    It is possible we’ll see other potential changes from Red Hat with regard to the access to RHEL’s source code. Today, it’s only available to customers under a commercial license agreement.

    The big test will be the next minor version, RHEL 9.3. It will be interesting to review the corresponding 9.3 versions of Rocky Linux, AlmaLinux, Oracle and others, including SUSE, who announced their intention to offer an open source compatible Linux distribution. The analysis and comparison of how applications run with the new minor version will reveal how close they are to RHEL.

    To mitigate uneasiness, organizations have to plan and test alternatives. Finding post-EOL support and patches will allow organizations to have a runway for migrating CentOS to different Linux distributions.

    As everyone in the industry with CentOS deployments waits for the next release or the next few releases, extending long-term support becomes a very viable solution. It is wise to make sure security and IT compliance aspects are addressed. Perhaps more open source Linux distributions will appear in the near future and offer another alternative to CentOS Linux.

  • 3 Ways to Achieve Faster App Development Without Compromising Security

    3 Ways to Achieve Faster App Development Without Compromising Security

    Bringing products to market quickly, efficiently and safely is key to brand success, and elite DevOps teams minimize the lead time for changes by quickly and efficiently moving new products and software updates from concept to deployment. DevOps teams often measure lead time in hours, not days, weeks or months, which underscores the centrality of speed in today’s hyper-competitive online environment. Customer experience and brand loyalty are constantly changing as new products and services come to market, and DevOps teams are under immense pressure to stay as agile and efficient as possible. Increased technology development velocity can lead to heightened security risks. As of early 2023, as many as nine out of 10 companies have detected security risks in their software supply chain. This is why companies cannot ignore the rising number of attacks targeting software development teams.

    High-profile incidents at SolarWinds, NetBeans IDE, Kaseya and Codecov demonstrate the risks facing software development teams at every company.

    These threats exploit the continuous integration and continuous delivery (CI/CD) process to sneak harmful software into authentic applications and install risky and harmful components whenever possible.

    The risk of code injections makes safeguarding internal and external dependencies crucial. If not appropriately protected, compromised software pipelines can lead to data leaks, code tampering and system exploitations, putting the entire business at a heightened risk.

    Simply put, DevOps teams must maximize development speed without compromising security. This is an undoubtedly tall order, but one that’s achievable with the right processes in place. Here are three strategies DevOps teams can implement immediately to reach this goal.

    Streamline Privileged Access Management

    Streamlining privileged access management is vital for enhancing cybersecurity in DevOps teams, particularly with the growing threats to software supply chains. This requires adopting stringent security practices, including temporary access permissions that can be granted and revoked as needed—a strategy ideal for managing temporary services in DevOps workflows.

    This approach facilitates automatic management of access privileges, including revoking password permissions when team members leave the organization or project and thorough scrutiny of who has access to what.

    At the same time, enforcing least privilege access, a principle that aims to minimize the attack surface by eliminating unnecessary permissions and adjusting overly broad ones, is also essential, reducing the chances of account hijacking or theft of static API keys.

    Similarly, zero standing privileges are also essential, relying on just-in-time access management that ensures minimal active permissions at any given moment, enhancing security by reducing potential vulnerabilities.

    Leverage AI Solutions for Security

    The cybersecurity AI sector is soaring alongside escalating cybersecurity threats to DevOps teams.

    Deloitte expects cybersecurity AI solutions to become a $19 billion market by 2025, as the technology’s “ability to adaptively learn and detect novel patterns can accelerate detection, containment and response, easing the burden on SOC analysts and allowing them to be more proactive.”

    AI can help DevOps teams detect and prevent cybersecurity incidents by quickly identifying and monitoring applications at risk, ensuring greater resilience in their DevOps processes through CI/CD, applying analytics to streamline data challenges, and identifying potential hot spots before they escalate and present real risks.

    AI can also help combat alert fatigue within security teams, reduce analyst workloads and cut down on false positives, saving valuable time. According to a 2022 IT industry study, 60% of respondents receive more than 500 cloud security alerts every day, and alert fatigue is “causing critical alerts to be missed at an alarming rate.”

    By leveraging AI for cybersecurity, DevOps teams can enhance their defensive posture without diluting their team’s impact, allowing them to best balance speed and security in the app development process.

    Enable Communication and Collaboration in DevOps Teams

    In the realm of DevOps, success relies not only on implementing the right tools and technology but also on fostering an adaptive culture that encourages seamless communication and collaboration among team members.

    Effective communication forms the bedrock of this cultural shift. By establishing clear lines of communication, development and operations teams can better understand each other’s challenges and perspectives. Open dialogues can foster mutual respect and create a shared understanding of common goals, thereby encouraging a collaborative problem-solving approach.

    Meanwhile, fostering a collaborative culture is equally vital. When teams collaborate effectively, they can identify and resolve issues more quickly, improve the quality of the software, and accelerate delivery times.

    Embracing Speed and Security in App Development

    Achieving faster app development without compromising security is a complex yet achievable goal in today’s competitive environment.

    By investing in streamlining privileged access management, leveraging AI and fostering a culture of effective communication and collaboration, DevOps teams can enhance both speed and security.

    To be sure, in the face of escalating cyberthreats, speed and security are not mutually exclusive but, rather, two sides of the same coin. By implementing these strategies, DevOps teams can navigate this delicate balance, accelerating development timelines while ensuring robust security.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    staging-devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it 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 being offered.

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

    LinkedIn

    Icertis
    Phoenix, Arizona
    Principal Azure DevOps Engineer
    $132,000 to $199,000

    SimplyHired.com

    Decision Sciences International
    Remote
    DevOps Engineer
    $130,000+

    Indeed.com

    Hewlett-Packard Enterprise
    Durham, North Carolina
    DevOps Engineer
    $124,500 to $286,300

    CareerBuilder.com

    CACI
    Oklahoma City, Oklahoma
    DevOps Platform Engineer
    $104,200 to $229,200

    Dice.com

    SPECTRUM
    Greenwood Village, Colorado
    DevOps Engineer
    $78,900 to $139,500

  • Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    In today’s fast-paced world of software development, when continuous deployment and frequent releases are the norm, DevOps teams are essential to facilitating smooth communication between development and operations. In a blog post on LinkedIn, I talked about the importance of service level objectives (SLOs) for the testing team to improve the overall product quality. On top of that, let’s look at how adding SLOs to your DevOps team can improve productivity, dependability and client happiness.

    The Role of SLOs for DevOps Teams

    • Aligning DevOps Goals with Business Objectives:

    SLOs help DevOps teams coordinate their efforts with business objectives. The DevOps team can concentrate on delivering real business value by setting precise performance indicators, such as deployment success rates or infrastructure provisioning timeframes.

    • Promoting Collaboration and Accountability:

    By implementing SLOs, several stakeholders—including development, operations, quality assurance and business teams—are encouraged to work together. Over each stage of the software development life cycle, this shared responsibility promotes a sense of ownership and accountability.

    • Driving Reliability and Stability:

    SLOs play a key role in ensuring the stability and dependability of the system. You can be sure that your services consistently fulfill client expectations when your DevOps pipeline adheres to defined SLOs.

    • Proactive Issue Mitigation:

    Monitoring and alerting systems are used together with SLOs. The DevOps team could avoid service outages and downtime by aggressively identifying possible problems and resolving them before they become more serious by regularly monitoring important indicators.

    • Data-Driven Decision Making:

    Decision-making is driven by quantitative data. With the help of such indicators, the team is able to identify bottlenecks, prioritize improvements and streamline processes based on quick feedback.

    Now, let’s explore some key areas where DevOps teams can set SLOs to improve their performance:

    1. Continuous Integration (CI):
    SLO: “xx% of builds complete within Y minutes.”
    Measurement: Monitor build times and queue times regularly.
    Action: Optimize CI infrastructure and configurations to meet the SLO.

    2. Continuous Deployment (CD):
    SLO: “xx% of deployments are successful.”
    Measurement: Track deployment success rate.
    Action: Improve the deployment process to meet the SLO and reduce deployment failures.

    3. Infrastructure Management:
    SLO: “xx% of infrastructure is provisioned within Y minutes.”
    Measurement: Monitor infrastructure provisioning time.
    Action: Optimize infrastructure provisioning scripts to meet the SLO.

    4. Monitoring and Logging:
    SLO: “DevOps tools and system uptime should be at least xx%.”
    Measurement: Monitor the availability of the DevOps pipeline, deployment system and other tooling, including monitoring and logging systems.
    Action: Ensure high availability for DevOps tools and components.

    5. Artifact Management:
    SLO: “Artifact retrieval time should be less than x seconds on average.”
    Measurement: Monitor artifact retrieval time and availability.
    Action: Optimize artifact storage and distribution mechanisms.

    6. Testing and Quality Assurance:
    SLO: “Code must have at least xx% unit test coverage.”
    Measurement: Track test coverage regularly.
    Action: Encourage developers to write more tests.

    7. Security and Compliance:
    SLO: “xx% of compliance checks must pass.”
    Measurement: Monitor the results of compliance checks.
    Action: Ensure necessary security measures to meet the compliance SLO.

    8. Standardized Tools Selection:
    SLO: “xx% of teams must use the approved CI/CD tools stack.”
    Measurement: Track the percentage of teams using the approved tools stack.
    Action: Encourage teams to adopt standardized tools and provide necessary training and support.

    9. Training and Skill Development:
    SLO: “xx% of team members should undergo relevant DevOps training annually.”
    Measurement: Monitor training completion rates.
    Action: Provide training opportunities and resources to help team members enhance their skills.

    Initially, teams should baseline which percentage values to track by observing the current state. In the event they don’t have the bandwidth to baseline, start with any reasonable arbitrary number over a period of time, and it will be automatically refined.

    Implementing service-level objectives empowers DevOps teams to focus on delivering reliable and high-performing services that meet user expectations. By setting clear performance and reliability targets, teams can proactively identify and resolve issues, leading to improved collaboration, efficiency and overall user satisfaction.

    SLOs are not rigid constraints but are a means to drive continuous improvement and foster a culture of excellence within the DevOps ecosystem. As organizations strive to keep up with the ever-changing demands of the digital world, embracing SLOs is a crucial step toward achieving DevOps excellence and ensuring a competitive edge in the market.

  • How Platform Engineering Can Drive Digital Sobriety

    How Platform Engineering Can Drive Digital Sobriety

    If we’re being honest, the “green issue” currently isn’t the priority it needs to be for a lot of companies. At best, they are ticking the box marked ‘sustainability’ and paying lip service to a trendy topic. At worst, they are engaging in nothing more than greenwashing.

    Considering carbon emissions from cloud computing have now overtaken those from commercial aviation, this is disheartening for the IT sector. Unsurprisingly, most of these emissions come from inefficient use of the cloud due to overly complex processes and a lack of centralized oversight over cloud infrastructures. And if “emissions” sounds a bit vague, here’s a translation into dollars–$147 billion was wasted in 2022 in cloud spend.

    So, when it comes to reducing an organization’s cloud carbon footprint, there is clearly a financial incentive. Even for those who don’t believe in individual responsibility or worse, simply don’t care what kind of world we’ll leave future (and some present) humans to live in, there is money to be saved.

    The truth is that companies need to put sustainability first across the whole enterprise, and they need to do it now.

    A New Kind of Business

    Tackling departments one-by-one or singling out individual processes to make them more sustainable is not going to work. What organizations need is to stop thinking of sustainability as an afterthought and start incorporating it in the decision-making process from the get-go, maybe even as part of their very business model.

    This is the sort of business that places its people and the planet above profits. Progressive, modern companies that want to stay in business longer need to invest in their people and take care of the planet instead of chasing endless growth and ever-increasing profit because that, simply put, cannot last.

    As a culture, we’re currently at a turning point–late-stage capitalism is running its course, and more people are realizing that constant growth at the expense of well-being and the planet’s dwindling resources is not sustainable (in all senses of the word).

    For this to work, it’s about looking at business through a new prism.

    Driving Digital Sustainability From the Ground Up

    It’s not too late for businesses to become more sustainable. In fact, it is the best time to make life-saving changes. When it comes to tech specifically, there are a couple of things you can do, starting with two key things that need to change.

    First, cloud waste has been costing companies billions of dollars for years now. Organizations are set to spend nearly $600 billion on the cloud in 2023, but it seems that most people are still in the dark about the real environmental impact of cloud usage. As with most big corporate changes, it’s all about a change of mindset. We need to accelerate awareness and promote digital sobriety to inspire transformation and decision-making with GreenOps on the enterprise level.

    A cloud-first approach has long been the holy grail of IT. However, what we couldn’t anticipate is the sheer volume of resource usage and complexity that comes with it. We simply do not have the planetary resources to support this growth much longer. It’s time to become smarter, leaner and more environmentally conscious by using the “consume better” approach.

    Second, think about the KPIs. Change without success parameters will not work. While organizations have a key role in decreasing global cloud spend, they must have the right tools and references. They need to be able to assess the environmental impact of their digital choices at all decision levels.

    For the IT sector, this is where platform engineering comes into play. An internal developer platform can act as the critical piece that connects DevX, deployments, governance, security and observability.

    With green best practices and cloud carbon footprint visibility at every stage–from the dev deploying a new environment on the cloud to the CFO checking the monthly cloud bill–a platform engineering approach ensures not only organizational but also individual responsibility. When all tools are accessible and processes transparent, nothing gets lost in translation. This means less room for error and cloud waste.

    Ultimately, it’s About Consuming Better and Consuming Less

    Right now, these KPIs will be financially motivated, and rightly so. But there will come a time when progressive organizations will put their environmental impact at the forefront of their mission statement.

    The B-Corp certification, which evaluates companies in terms of their social and environmental performance, grew 63% in 2022. This shows the trend toward moving to a more inclusive and sustainable economy. Partly because it’s in the interest of the businesses’ long-term success and reducing costs, but partly because it is simply the right thing to do.

  • The Differences Between DevOps, DevSecOps and SRE

    The Differences Between DevOps, DevSecOps and SRE

    DevOps, DevSecOps and SRE are all quickly gaining traction within the tech world due to their effectiveness and promise of reliability for companies. Each framework provides various levels of safety and scalability—DevOps is agile, DevSecOps prioritizes security above all else and SRE focuses on performance optimization. Together, these are changing how software gets deployed from conception to production. We’ll break down each one in detail.

    What is DevOps?

    DevOps is a set of practices that combines software development and IT operations, which aims to shorten the software development life cycle (SDLC).

    DevOps bridges the gap between those two areas by bringing together different people–developers, operators, testers and system engineers–who are responsible for different parts of the software delivery process, from planning to deployment into production environments.

    A core tenet of DevOps is to automate manual processes within each stage of the SDLC, eliminating much of the redundant work that used to take weeks or even months. This automation significantly drives down costs, as well as reduces problems posed by human error when running manual tasks.

    The following are some of the core tenets of DevOps:

    1. Collaboration
    2. Quality and reliability
    3. Automation
    4. Scalability
    5. Security

    What is DevSecOps?

    DevSecOps (or DevOps security) is an emerging field within the DevOps practice that focuses on strengthening software security within the development and operations process.

    These three distinct groups often have different priorities when it comes to building software applications. Developers are focused on speed-to-market objectives from their employers or clients, operations focus on reliability and scalability, while security teams prioritize safety from malicious actors or data breaches. At the same time, with DevSecOps, these goals become united under one umbrella: Build fast and reliable applications with built-in protection against attacks.

    DevSecOps focuses on implementing security as code—or automating many routine tasks involved with identity management, like user authentication and authorization. To ensure that security is properly integrated into your DevOps pipelines, below are some key DevSecOps practices:

    1. Automate security processes whenever possible
    2. Encourage continuous testing
    3. Prioritize remediation over detection
    4. Create a culture around secure coding principles

    What is SRE?

    SRE stands for site reliability engineering. The basic idea behind SRE practices is that software engineers should be responsible for both the development as well as the reliability of their product as a whole. This means having an understanding of not only how users will interact with the application or service but also how it interacts with other services in its operating environment, such as databases, firewalls, cloud environments, etc.

    To maintain uptime while meeting these requirements, SRE applies various techniques like automation and continuous deployment processes to ensure high availability.

    A key goal of site reliability engineering is service-level objectives (SLOs), which measure how consistently a service meets its goals over a given period of time—such as how often it’s available, how quickly it responds to requests made by users or customers—and establishing goals around those SLOs. Achieving objectives like these helps organizations build customer trust in their products and services since it ensures that they have stable and reliable day-to-day operations.

    Here are some of the most important SRE principles:
    1. Automation
    2. Proactive monitoring
    3. Fault tolerance
    4. Measurement and analysis
    5. Service-level objectives (SLOs)

    DevOps Vs. DevSecOps Vs. SRE

    The differences between DevOps, DevSecOps and SRE can be summed up in three main areas: Scope, roles and objectives.

    DevOps focuses on improving the speed of releasing software by automating processes and optimizing collaboration between development and operations teams. This helps organizations create a continuous delivery pipeline to quickly deploy code into production with minimal risk. As such, it is typically focused on development or operations activities and has become synonymous with agile methodologies such as continuous integration/continuous delivery (CI/CD).

    DevSecOps expands upon these concepts to include security considerations from the very beginning of a project’s life cycle instead of tacking them on after the fact. By shifting security left in the process–meaning bringing security earlier into the design phase–teams are able to reduce risk early on while achieving faster results overall through continuous feedback loops.

    As part of this shift left process, DevSecOps practitioners focus heavily on automating security compliance activities as part of their job function rather than waiting until after deployment has occurred.

    Meanwhile, SRE focuses more broadly on keeping the user experience consistent across various products an organization offers by responding to customer needs quickly while creating automation processes that allow common tasks to be repeated without manual intervention from engineers or developers.

    Then there is also platform engineering, which is a closely related yet distinct discipline with its own unique responsibilities. While both DevOps and platform engineering involve automation and working with the infrastructure that supports software development, there are some key differences between them.

    Platform engineering can be defined as a practice that involves developing a standardized platform on which all applications will run. Platform engineers build the underlying infrastructure to support applications, including servers, databases, virtualization layers and networking components using standardized toolsets. An important task for this field is designing an application’s architecture in such a way that allows it to scale easily with increased demand or usage levels. Additionally, they create self-service tools that enable developers on their team to quickly spin up new environments without requiring outside assistance.

    Wrapping Up

    In conclusion, while all three approaches have similar goals–ensuring reliability, speeding up the software delivery process and securing user data–they do so using different strategies:

    ● DevOps favors automation.
    ● DevSecOps puts focus on proactive security measures.
    ● SRE prioritizes optimization, reliability and scalability.

    Each one can contribute significantly when appropriately implemented into any organization’s workflow, depending upon its own specific needs.

  • Rebellion Against Changes to Open Source Terraform License Mounts

    Rebellion Against Changes to Open Source Terraform License Mounts

    A segment of the community that has embraced open source Terraform software, originally developed by HashiCorp to provision infrastructure as code (IaC), has published a manifesto calling on the company to reverse recent changes made to licenses that determine how the software can be used.

    If that demand is not met, the group plans to launch its own fork dubbed OpenTF under the terms of the previous license that governed the usage of Terraform.

    Pawel Hytry, CEO of Spacelift, a provider of a platform for orchestrating the management of multiple IaC tools, said the issue comes down to restrictions that Hashicorp has put in place restricting use within platforms that have embedded it, in addition to limitations on how Terraform can be used in production environments.

    HashiCorp is shifting from a Mozilla Public License v2.0 (MPL 2.0) to a Business Source License (BSL) v1.1 in all future releases of its software including Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer and Vagrant, as part of an effort to maintain maximum control over its intellectual property.

    This shift will have a chilling effect on Terraform innovation because fewer individuals and organizations will want to contribute to advancing the tool, said Hytry.

    However, Hytry added, historically HashiCorp has not been perceived as not being overly receptive to contributions from external developers, so the bulk of the code used to create Terraform has come from developers working for HashiCorp.

    It’s not clear to what degree this firestorm impacts DevOps teams, but the fragmentation of open source projects stemming from issues that come down to revenue streams is increasing as it becomes more difficult for vendors that create open source software to continue to increase the number of subscription services for the support they provide. Red Hat, for example, recently decided to no longer make the source code for the Red Hat Enterprise Linux (RHEL) edition of its operating system available. The decision led to Oracle, SUSE and CIQ pooling their resources to create a fork of RHEL that they promise will be compatible with future updates to RHEL.

    It remains to be seen how many vendors might throw their weight behind OpenTF. HashiCorp, in addition to having partners that built the business on the open source edition of Terraform, also has plenty of rivals that offer IaC tools.

    It may be a while before this conflict is resolved, but for now, the situation remains fluid, said Hytry. DevOps teams that make extensive use of Terraform will need to monitor events to make sure any future usage of Terraform complies with BSL terms that supporters of the manifesto claim are at this point too vague.

    In the meantime, organizations that rely on open source software should brace themselves for any abrupt changes to licensing terms that may be forthcoming in more challenging economic times. In fact, one of the hidden costs of using open source software is the different terms and conditions under which it is licensed. Resources to monitor each additional instance of open source software for compliance, with terms and conditions that are not always as simple or clear cut, need to be dedicated to a task that doesn’t make any meaningful contribution to return on investment.

  • Why Multi-Cloud Cost Optimization is Harder Than it Looks

    Why Multi-Cloud Cost Optimization is Harder Than it Looks

    If your business is like most businesses that use the cloud today, you’ve gone multi-cloud. Nine out of 10 large companies have already adopted multiple clouds, and IT analysts expect that even more businesses will embrace multi-cloud architectures over the next several years. Now, the challenge facing those companies is how to optimize spending across multiple clouds. Many will find that, despite common narratives suggesting that cost savings are an inherent benefit of multi-cloud architectures, reducing spending when using multiple clouds can be a lot harder than it looks.

    This is, fortunately, a challenge that can be conquered easily enough. Keep reading for tips on updating your cloud cost optimization strategy to support multiple clouds.

    Multiple Clouds Don’t Guarantee Reduced Cloud Cost

    Before diving into strategies for reducing spending when using multiple clouds, let me dispel a common myth about the relationship between multi-cloud architectures and spending.

    Contrary to popular belief, using multiple clouds doesn’t guarantee that your business will spend less overall in the cloud, or even make it very easy to do so. Although advocates of multi-cloud strategies often promote the idea that using multiple clouds makes it simpler to find the most cost-effective cloud services because you have a larger menu of offerings to choose from, the reality is that cost-saving is not a common outcome of going multi-cloud.

    Sure, in theory, having multiple clouds does give you more opportunities to reduce costs. But in actuality, migrating workloads between clouds typically takes significant time and effort. Given that most mainstream cloud services–like VM hosting and object storage–have been commoditized to the point that there are rarely major pricing differences between them, few businesses are actually going to migrate workloads back and forth between clouds on a frequent basis in order to save a few dollars.

    To Reduce Multi-Cloud Spending, Focus on Cloud Provider Relationships, not Workloads

    That said, adopting a multi-cloud strategy does place you in a position to reduce overall spending–but it’s not because you can migrate workloads between clouds. It’s because you can leverage relationships with multiple cloud providers to negotiate pricing reductions.

    If your teams are actively using multiple clouds, you have a strong ability to negotiate enterprise pricing deals with the providers of each of those clouds. Each provider that you work with will be eager to earn as much of your business as possible, and if they know that your company is already also using a competitor’s platform, they’ll probably be more forthcoming with discounts in exchange for a commitment on your part to run more of your workloads on their cloud.

    How to Keep Multi-Cloud Cost-Efficient – but Also Flexible

    The caveat is that if you want to retain the flexibility that a multi-cloud architecture nominally provides, it’s important not to over-commit to any single cloud provider. If you do, you may find yourself locked into one cloud for certain workloads due to pricing discounts that you’ve negotiated for those workloads with that cloud provider.

    An effective approach for finding the right balance between pricing discounts and flexibility is to decide which percentage of your overall cloud spending you want to avoid tying to a particular cloud. For example, you might decide that it makes sense to commit 30% of your spending to one cloud provider and 30% to another in exchange for pricing discounts that negotiate with each provider. But the remaining 40% of your cloud spending won’t be linked to enterprise agreements with cloud providers, so you’ll be free to spend it in whichever cloud you like.

    Maintain Workload Portability to Minimize Multi-Cloud Spending

    As you work to optimize multi-cloud spending, strive to adopt portable workload technologies, like containers in place of ones that are harder to migrate between clouds, like VMs.

    This is important not just because portable technologies help to maximize the flexibility of your multi-cloud strategy, but also because they give you more leverage when negotiating with cloud providers. The providers realize that some types of workloads are harder to migrate than others, and they’re less likely to offer serious pricing discounts if they know it’s going to be very difficult for you to move your workloads to a competitor.

    But if you can say, “70% of what we deploy runs in Kubernetes and can migrate from your managed Kubernetes environment to your competitor’s offering next week,” you’re in a much stronger negotiating position.

    Conclusion

    In short, don’t assume that simply adopting a multi-cloud architecture will yield enormous cost savings just because you can easily move workloads from one cloud to another to take advantage of pricing differences. In most cases, you can’t.

    What you can do, however, is leverage your relationships with competing cloud providers to negotiate discounted enterprise pricing agreements. And the more portable your workloads are, the better able you’ll be to obtain serious cost savings while simultaneously enjoying the flexibility and agility that multi-cloud architectures stand to offer.

  • System Initiative Open Sources Digital Twin Tool for DevOps

    System Initiative Open Sources Digital Twin Tool for DevOps

    System Initiative (SI) today announced it is making the digital twin tool it developed to manage DevOps workflows available under an open source Apache 2.0 license.

    Company CEO Adam Jacob said the approach will enable third parties to contribute to a project that is still early in its development cycle while SI provides commercial support via a subscription service.

    SI has developed a tool that creates a digital twin of a DevOps environment that provides a level of abstraction that makes it simpler to manage complex workflows at scale.

    At the core of that effort are models of IT environments created by the SI platform accessed via a visual interface. The automation framework built into the platform uses the relationships between models to infer configuration dynamically and generates typescript code that a DevOps team can then apply to automate a task.

    Feedback loops are provided in real-time to give insight into the viability of a configuration, in addition to eliminating the need for state files to track and ‘plan’ versus ‘apply’ stages.

    This approach streamlines a lot of the complexity that creates bottlenecks in DevOps workflows in what heralds the arrival of a new DevOps 2.0 era, said Jacob.

    In general, SI is making a case for an alternative approach to managing DevOps as the existing platforms and framework are fundamentally broken, added Jacob. Models that create digital twins of DevOps environments represent the arrival of a new era of software development and deployment, he noted.

    As more organizations realize their dependency on software to drive digital processes many are then looking to improve the productivity of developers and the DevOps teams that support them. Unfortunately, many DevOps teams are supporting DevOps workflows using custom code that varies widely in quality. Rather than rely on a DevOps engineer to write code, the SI digital twin tool will create code that can be applied more consistently to create DevOps workflows programmatically.

    One of the reasons few organizations today have fully automated DevOps across the application development and deployment process is that it’s simply too difficult to achieve using legacy tools and DevOps platforms. It’s not clear to what degree a digital twin approach to managing DevOps will resolve that issue, but when coupled with the arrival of artificial intelligence (AI) capabilities the way DevOps is managed is clearly about to transform.

    It may take a while for that transition to occur, but DevOps teams that have historically embraced automation are at the very least going to aggressively experiment with technologies that promise to eliminate much of the drudgery that makes DevOps more tedious than need be. The issue, as always, will be determining which technologies live up to the current level of hype being generated in a way that can be easily adopted.