devopsy.kinsta.cloud

Category: Enterprise DevOps

  • What DevOps Leadership Should Look Like

    What DevOps Leadership Should Look Like

    Implementing DevOps has become a major focus, but the practice’s attempt to provide organizational support and streamline production systems simultaneously leaves developers with no clear hierarchical structure. We know we need DevOps and we know it helps, but we also know that without proper leadership or structure, it can be misunderstood and undervalued. To build a strong collaborative culture, DevOps leadership, like most other leadership roles, requires a different type of skillset—a skillset that isn’t always prioritized in software development. The ability to understand programming languages, to be versatile and be attentive to detail will take a developer far in their career, but once they’re in a management position, what is needed to be an effective DevOps leader?

    First, what does an effective DevOps leader look like? To start, they need to lead. But to lead a DevOps team, it’s important to not only understand development—including reasonable goals and how to accomplish challenging tasks—but a DevOps leader needs to be able to create an environment that fosters collaboration between teams.

    This is why a DevOps culture is a core value for any high-performing DevOps team. This is due to the cross-functional nature of the practice. The stages of the DevOps cycle (plan, build, test, deploy and manage) rely on different teams with different skill sets.

    Build a Culture Of Ownership and Teamwork

    To effectively collaborate, a strong cross-functional culture of ownership, teamwork, intensity and smart application is needed.

    Clarity can transform a team, and it starts with ownership. Ownership is essential for cross-functional DevOps teams to understand their roles and what they are responsible for. In order for clarity to exist, leaders need to provide clear direction and guidance. It is a leader’s responsibility to set realistic goals and offer support. Group trust is built when a team has a common goal and clear roles and responsibilities are identified.

    Ownership is the foundation of teamwork, and with it, team members can see their individual contributions to a project and can celebrate their successes together. This teamwork then breeds collaboration, improved performance and a cohesive dynamic within the team’s culture.

    Lead With Strategic Intensity and Smart Application

    A DevOps leader can empower their team through ownership and teamwork, but we can’t forget the value of knowing the right level of intensity for a project. Leaders need to understand a situation, the context and how to approach it strategically to avoid burnout and bitterness. They must know when to apply intense sprints and when to pull back and move resources—a leader must know how to play smart with the resources they have.

    Use Soft Skills

    People management skills can be overlooked in a lot of leadership positions. For example, we might see it when a startup chooses a CTO or an engineering lead position based on seniority or developer skills without regard for their ability to actually manage people or their desire to be in such a position. Often, the person in charge of a DevOps team is given this role because of their previous development accomplishments, but they lack the necessary soft skills of communication, conflict management and/or teamwork. Using the four principles above can help accelerate the foundation of culture as well as help compensate for a leader’s lack of soft skills

    DevOps leaders need soft skills. Soft skills include the ability to think critically and project manage while having enough emotional intelligence to inspire, motivate and retain a team of smart engineers. Every leader needs to be able to see their team’s strengths and weaknesses, listen and influence and further develop their members to succeed. The challenge for this role is that, to be successful, it takes both technical expertise and soft skills and knowing how to balance the two.

    Unfortunately, soft skills haven’t been prioritized in the training and career development of most software engineers. Only recently have soft skills been seen as a differentiator in the engineer hiring process or seen as a value-add to an organization. For years, technical skills took precedence and we ignored the areas that would take a software engineer to the next level – the soft skills that will lead to leadership. But it’s a bigger problem; employers say most college grads aren’t learning these soft skills in school.

    Remember the Not-so-Secret Sauce

    Soft skills empower a leader to thrive both within a DevOps team and in collaboration with other departments. The ability to work across teams can exponentially improve business operations. A strong DevOps leader can offer solutions and problem solve for internal issues and customer-facing problems. They are able to bring DevOps into new areas of the company in a strategic and effective way. Collaboration requires working with others, seeing the bigger problem, understanding the business goals and using soft skills to get things done.

    It’s the not-so-secret sauce that makes all the difference when running a powerful DevOps team. A culture of collaboration starts with the leader. A leader’s relationship skills can increase the likelihood of bigger budgets, more tools and recognition. DevOps leaders can build a strong team by leveraging the soft skills within themselves and their team members, applying the right level of intensity and encouraging a culture of ownership, teamwork and collaboration. If these things are missing, whether DevOps or another team, the unit will fall apart.

    This is why a DevOps leader needs to take personal ownership and responsibility for the success of their team and see motivating others, setting a standard of operational excellence and representing the DevOps team as an integral part of their role. Luckily, there are resources to learn and exercise these skills so every leader, newly appointed or veteran, can ensure their team can excel.

  • Things We Should Acknowledge, Part One: Hiring Sucks

    Things We Should Acknowledge, Part One: Hiring Sucks

    I was talking to some friends about hiring the other day, and a common thread seems to run through all of their hiring activities: It is hard to find “good” DevOps people.

    This thought got me thinking that we assume a lot in DevOps, and that we should stop assuming and openly discuss those things. For all the streamlining and shift left it can do, DevOps could use some streamlining and shifting left, itself. So, this is the first of what I think will grow into a series of blogs about DevOps assumptions we make and openly discuss them. At least if we acknowledge our assumptions and the realities that we try to ignore, we can adjust.

    Today’s blog is about finding “good” people. I put good in scare quotes because while there are common threads, the definition of good is definitely dependent upon the organization and even on the team. If a team needs someone with Azure chops to rev up their work and help the rest of the team become more proficient in Azure, then a GCE expert, no matter how great they are, is not “good.” This is true of every field of endeavor, but we in DevOps often pretend it is not true for us. Particularly the pundit class, but management is also severely guilty of “It’s DevOps, everyone is everything,” which any active practitioner will tell you is not true. There are still specialties, we just hand wave and blather about “It’s all DevOps.”

    Unfortunately, there is often a disconnect here. DevOps roles are not well-filled by filtering on technology and they’re not well-filled by just using “DevOps” in the job title. That leaves HR struggling to find candidates to interview that techs will find appealing. How does HR filter on “can learn on the job, and do so rapidly”? Simply put, they don’t. That’s what interviews are for. But if HR filters on “must know Jenkins,” that is diametrically opposed to “must learn on the job.” Which is it? Must know certain skills and have X years of experience in them, or must be able to pick up new things on the fly? Because filtering on already having the skill would seem to imply you don’t really care about the ability to learn fast, would it not? Because there are great fast learners that have never worked in a Jenkins shop, but they could, if they’re truly fast learners, pick up Jenkins.

    So ‘good’ is relative, but beyond that, what I hinted at above is also impactful. We are–nearly all of us–on-the-job trainees. There are certifications and universities are starting to catch up, but most of us? We learned either on the job or on our own time, trying to do some pet project. This, too, hurts HR filtering. Demanding a four-year degree is something that HR can measure. Demanding on-the-job training? Not so much. So, if HR gets filters they can measure, they will not be filtering based upon reality.

    This is how we get things like, “Must have 30 years of Rust experience,” even though Rust is 20 years old if you count from inception. Far less if you count from the start of its usable life. HR is not an efficient or effective filtering system for DevOps, and we are somewhat flailing. Until we have improved systems and processes, I would suggest having HR send too many applicants through, and DevOps engineers or managers–those who will have to work with (and count on) those new hires–do more of the filtering than normal. There are honestly people out there with no relevant degree and no certifications that are better than most of us. Project work is the only way to gauge that measure, but project work cannot be effectively evaluated by HR because they’re not technical specialists. I know—the org is hiring people because they need help, so offloading some of HR’s duties on the team that needs the help is not a great solution. It is better than going through an entire outreach/interview/hire process only to settle for ‘good enough’ (or, worse, ‘not good enough’) because the process is flawed based upon the current environment.

    This brings us to the scenario we see today–where more technical people have hit the market than in recent history, but hiring managers are still struggling. Have the DevOps team take a more active role in the process until new standards can be settled on that suit the needs of your organization. You’ve worked hard to make an astounding infrastructure and build apps that can handle the needs of your organization, make sure the people you put next to you are the best you can find and the organization can afford.

    And keep rocking it. Teach them about the systems you shepherd and learn from them what they bring to the team.

  • HPE to Acquire OpsRamp to Gain AIOps Platform

    HPE to Acquire OpsRamp to Gain AIOps Platform

    Hewlett-Packard Enterprise (HPE) this week revealed it is acquiring OpsRamp to gain access to a platform for embedding artificial intelligence in IT operations (AIOps).

    Latha Vishnubhotla, chief platform officer in the office of the CTO for HPE, said the company would embed the machine learning technology developed by OpsRamp across its entire portfolio in addition to leveraging it to automate IT processes the company manages via its GreenLake service for HPE customers.

    Ultimately, HPE will be applying machine learning across the entire IT stack, including applications, to reduce the total cost of IT, she said.

    The acquisition of OpsRamp is expected to close in the third quarter of this year. Terms of the deal were not announced, but it comes at a time when more organizations are getting comfortable with AIOps.

    A recent OpsRamp survey polled 138 IT leaders working for enterprise IT organizations and 127 representing managed service providers (MSPs) that generate at least $25 million in revenue and have more than 500 employees. The survey found the primary reason organizations are embracing AIOps is to improve service and application availability and performance (60%), followed closely by automation of operations (58%) and processes (54%).

    The survey found that the greatest IT operations challenge for enterprises in 2023 was automating as many operations as possible (66%), followed by driving greater efficiency and productivity of IT operations teams and processes (61%). Application-to-infrastructure dependency mapping is the top incident management challenge (64%), the survey found.

    The primary operational benefit cited was reducing open incident tickets (65%), followed by reducing mean-time-to-discovery (MTTD) and mean-time-to-remediation (MTTR), tied at 56%, and automation of tedious tasks (52%).

    In general, organizations are choosing one of two AIOps paths, said Vishnubhotla. Some are waiting to evaluate the recommendations made by the AIOps platform before implementing, while others are looking to completely automate processes so they can focus more of their time and effort on application development and deployment, she said. In much the same way a driver of an autonomous vehicle learns to trust the AI over time, there is a similar transition occurring with AIOps, noted Vishnubhotla.

    The challenge is that it takes an AIOps platform a few months to learn an IT environment. The more dynamic that IT environment is, the longer that process can take. At the very least, however, AIOps platforms have the ability to automate many low-level IT tasks today that conspire to increase the amount of toil DevOps teams would otherwise encounter.

    It’s difficult to determine how pervasive AIOps may be within IT environments, but there is no doubt as organizations look for ways to manage IT at scale, there will be increased reliance on automation. Most organizations can’t afford to continue to hire armies of IT personnel, especially as the global economic outlook remains uncertain.

    In fact, one of the benefits of an AIOps platform is that, unlike an employee, it does not take any days off or suddenly decide to take another job. It also, for better or worse, doesn’t forget anything once it’s been learned. As such, it’s now only a question the degree to which AIOps platforms will be trusted over time to manage increasingly more complicated IT tasks.

  • Oracle Makes Java 20 Platform Generally Available

    Oracle Makes Java 20 Platform Generally Available

    At an Oracle DevLive Level Up event, Oracle today announced the availability of a Java 20 update that makes a range of innovations more accessible to application development teams.

    Georges Saab, senior vice president of development for the Java Platform and chair of the OpenJDK Governing Board for Oracle, said the latest version of the venerable programming language builds on previous extensions made to the Java development kit (JDK) that exemplify how the pace of Java innovation is now increasing.

    Specifically, seven JDK Enhancement Proposals (JEPs) are now supported in Java 20, including OpenJDK project Amber for record patterns and pattern matching for switch expressions and statements; enhancements from OpenJDK Project Panama to interconnect Java Virtual Machines (JVMs), features related to Project Loom that streamline the process of writing, maintaining and observing high-throughput, concurrent applications and a Function & Memory application programming interface (API) and Vector API.

    Oracle also revealed Java 20 is supported by Java Management Service, an Oracle Cloud Infrastructure (OCI) native service that provides a single pane of glass to help organizations manage Java runtimes and applications on-premises or on any cloud.

    Finally, Oracle is making available an Oracle Java Universal SE Subscription that provides access to a pay-as-you-go offering that includes entitlement to GraalVM Enterprise, the Java SE Subscription Enterprise Performance Pack, access to the advanced features of the Java Management Service and the flexibility to upgrade at any pace an organization prefers.

    Oracle Java Standard Edition (SE), GraalVM Enterprise and the Java SE Subscription Enterprise Performance Pack are also now available free of charge on OCI.

    Despite the number of programming language alternatives that exist, many enterprise IT organizations remain committed to Java. Rather than opting to retrain developers, it’s simply been more cost-effective to enable developers to continue to build applications using a programming language they already know.

    Java itself, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under an open source OpenJDK license. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications that are being modernized. As part of those efforts, the rate at which Java applications are being deployed in the cloud has substantially increased.

    As part of those efforts, many organizations are currently in the process of shifting to Java 17. It’s not clear how many organizations will skip Java 17 and jump to Java 20 from previous versions of Java, but DevOps teams should expect to be supporting a wide range of versions of Java for years to come.

    In fact, most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a programming language that has persevered through two decades and appears to have enough staying power to stick around well into the next.

  • How Database DevOps Fuels Digital Transformation

    How Database DevOps Fuels Digital Transformation

    In today’s real-time, hyperconnected reality, data is a core driver behind most digital strategies. User data is constantly gathered and shared across various technology backends and platforms—as is system performance data to inform engineers. Data is pivotal for everything, from generating machine learning models, refining user experiences and even supporting new data-centric services. But although data is a clear backbone to many enterprises, there is no clear winner regarding which database to use.

    Large organizations often find themselves supporting different database styles, from relational databases to NoSQL and distributed SQL. And as organizations continue to adopt multiple databases, safely managing the processing and storage of data becomes more challenging to enact at scale.

    I recently met with Jakub Lamik, CEO, Redgate Software, to understand the role DevOps, specifically database DevOps, is playing in advancing data-driven digital transformations. According to Lamik, applying DevOps practices for database management can improve performance, increase productivity and help organizations stay compliant. Below, we’ll consider the state of today’s data-driven digital transformations and highlight ways to improve how DevOps is applied to database management.

    State of Data-Driven Digital Transformations

    The 2022 StackOverflow Developer Survey found the most popular databases to be MySQL, PostgreSQL, SQLite, MongoDB and Microsoft SQL Server. But most often than not, businesses deploy more than one of these in production. Redgate’s 2021 State of Database DevOps report found that 70% of businesses had more than one DBMS in use, and 48% had teams working on three or more different databases.

    Engineers operate in increasingly hybrid and distributed technology environments. This isn’t for no reason—in fact, 90% of organizations said multi-cloud is helping them achieve their business goals. Lamik also notes a diverse array of software technologies in practice today, from multiple clouds to decoupled microservices architectures and database types. But the desire to work with diverse toolsets causes fragmentation, which could hinder software delivery efforts. For example, organizations want to deploy the same framework and similar methodologies across different databases, said Lamik, and have it be database- and cloud-agnostic.

    Tips to Improve Database DevOps Operations

    To increase the pace of software delivery, infrastructure automation is often needed. And like other roles, database professionals are increasingly trying to automate operations and free themselves from mundane tasks. So, what are some ways to streamline database DevOps? First off, Lamik encourages adopting a common approach across multi-database environments, using standard toolsets that are flexible and portable. “The organizations that standardize deployments across different database environments can increase the frequency and reliability of deployments,” he said.

    Catching and resolving errors quickly is also becoming increasingly essential to meet objectives. And although DevOps brings many advantages, the CI/CD pipeline has gaps. “Observability supported by intelligent automation is key to closing those security gaps,” said Lamik.

    Thus, he encouraged additional oversight and tracking of changes to ensure stability throughout the database deployment pipeline. Also helpful is encouraging collaboration with security professionals (also known as DevSecOps) and integrating security principles into the DevOps workflow to ensure the process is secure by design.

    Another element of database security involves the proper observability and classification of sensitive data. As Lamik describes, organizations must be careful to distinguish between data used for production purposes and data used for development purposes. Ensuring sensitive data is cataloged correctly is imperative to avoid production data from being breached or accidentally publicly exposed.

    Final Thoughts

    In summary, applying DevOps ideals to database management could be a boon for development efforts. For those who haven’t yet considered it, a DevOps transformation will pay dividends, says Lamik. Furthermore, a common management layer could help wrangle multiple database types and help adopt new emerging database types, such as Snowflake and Postgres. Yet, when acquiring new database toolsets, Lamik admitted it may not be a quick transition. He recommends a land-and-expand strategy rather than a top-down approach (which typically isn’t as effective in empowering individual developers).

    Commenting on the industry’s recent move toward platform engineering, Lamik sees it as the next evolution of DevOps. Whereas DevOps brought helpful toolsets to streamline deployment and digitization, platform engineering is taking these practices and productizing them to be reusable at scale across teams and departments, he explained.

    Also, in the new cloud-native stack, containers are designed to be ephemeral, causing engineers to craft workaround solutions to enable stateful storage on platforms like Kubernetes. Regardless of deployment, data must have proper backup and recovery controls as well. In this new cloud-native paradigm, the role of database professionals is changing, explained Lamik, and “APIs are becoming the focal point of communication.”

  • Large Organizations Are Embracing AIOps

    Large Organizations Are Embracing AIOps

    A survey of 265 IT leaders found the primary reason organizations are applying artificial intelligence to IT operations (AIOps) is to improve service and application availability and performance (60%), followed closely by automation of operations (58%) and processes (54%).

    Conducted on behalf of OpsRamp, a provider of an AIOps platform, the survey polled 138 IT leaders working for enterprise IT organizations and 127 representing managed service providers (MSPs). The organizations surveyed generated at least $25 million in revenue and have more than 500 employees. The survey found monitoring/native instrumentation (55%) ranked as the most important feature of an AIOps platform.

    Bill Talbot, chief marketing officer for OpsRamp, said the survey suggested the initial reason organizations appear to be adopting AIOps is to improve monitoring and overall observability as IT teams continue to find simple tasks—such as discovering what is in their IT environments—challenging to achieve.

    Overall, the survey found the greatest IT operations challenge for enterprises in 2023 was automating as many operations as possible (66%), followed by driving greater efficiency and productivity of IT operations teams and processes (61%). Application-to-infrastructure dependency mapping is the top incident management challenge (64%), the survey found.

    The primary operational benefit cited was reducing open incident tickets (65%), followed by reducing mean-time-to-discovery (MTTD) and mean-time-to-remediation (MTTR) tied at 56% and automation of tedious tasks (52%).

    The survey also found 80% of respondents reported it took less than six months to implement an AIOps platform, with more than two-thirds (68%) noting it takes more than six months to hire engineers with the right skillsets for AIOps. Well over 90% of respondents said AIOps is delivering the level of value they expected.

    Despite advances in AIOps, however, two-thirds of respondents said they are concerned about the accuracy of the data being used to train AIOps platforms. A little more than a third (36%) are also concerned about AIOps deployment causing job loss.

    While there has been a lot of initial skepticism concerning AI applications in IT operations at scale, adoption has now crossed the proverbial chasm, said Talbot. IT teams are finding a wide range of static application environments that lend themselves to being automated using machine learning algorithms, he added.

    Less clear, of course, is the degree to which AIOps can be applied to highly dynamic IT environments where changes to code are frequently made. However, the more routine processes that are automated, the more time DevOps professionals will have to manage more challenging issues.

    At this juncture, it’s not so much a question of whether AIOps will be employed to manage DevOps processes as much as it is to what degree. It remains to be seen how generative AI platforms such as ChatGPT might be applied to IT operations, but it’s apparent that AI will automate a wide range of tasks. It’s not likely those capabilities will eliminate the need for humans any time soon, but it does mean that many of the rote tasks that make working in IT tedious may soon disappear.

  • DevOps Adoption in Salesforce Environments is Advancing

    DevOps Adoption in Salesforce Environments is Advancing

    A global survey of DevOps professionals building apps in Salesforce environments found 44% of respondents reported their organization has a continuous integration/continuous delivery (CI/CD) platform in place, with another 39% planning to adopt one.

    The survey, conducted by Gearset, a provider of a DevOps platform for building custom applications in Salesforce environments, polled 1,254 DevOps professionals that are building and deploying custom applications on top of the Salesforce software-as-a-service (SaaS) platform. The survey also found nearly half (49%) implemented change monitoring, with another 33% planning to follow suit. More than half (52%) implemented source-drive workflows, with another 33% similarly planning to follow suit. A total of 41% of respondents noted that, over the last 12 months, they have more custom code to manage.

    Overall, the survey found 54% of respondents reported increased productivity, followed by improved quality and faster releases at 41% each. Nearly three-quarters (72%) reported they are able to deploy changes from one environment to another within four hours. Well over a third (39%) of this group are able to complete a deployment in less than an hour. Just under a quarter (23%) are also able to release code multiple times a week.

    However, only 18% can release a new feature to production in less than a day. Nearly half can complete the release within one day to a week. A total of 43% claimed that less than 10% of releases include a bug or error, with 46% reporting they can roll back a release in a day or less, if needed. Just over a third can restore a process in a day or less.

    The biggest obstacle to DevOps adoption is lack of experience (41%), followed by a third (29%) of respondents that reported difficulties with collaboration and another 29% that experienced limited buy-in from the rest of the application development team. Only 30% received DevOps training once a month, with 50% citing additional CI/CD and automation training as their biggest need.

    Despite these issues, a full 98% are generating a return on their DevOps investments, with 59% of teams reporting returns of over $10,000 per month and 40% reporting returns in excess of $50,000 per month. The top two priorities for the next 12 months are to consolidate systems and processes and improve flexibility, tied at 47% each, followed closely by 43% that noted that digital business transformation is a top priority.

    David Runciman, technical content manager for Gearset, said that while Salesforce applications are based on unique object architecture, it’s apparent that organizations are extending those applications using, for example, low-code tools more quickly. The issue that creates is, as organizations move to deploy these applications, they are encountering bottlenecks that conspire to slow the pace of innovation, he noted.

    The maturity level of DevOps teams building these applications will naturally vary. However, as the number of applications being built—especially by professional developers—increases, it’s only a matter of time before more organizations embrace DevOps best practices to bring order to the chaos, noted Runciman. While there may be some citizen developers building applications in Salesforce environments, the bulk of enterprise-class applications are built by professional developers that typically appreciate DevOps best practices, he added.

    The issue remaining is just how quickly those DevOps teams will be able to implement DevOps best practices as demand for additional applications grows.

  • How Open Source Can Benefit AI Development

    How Open Source Can Benefit AI Development

    Enterprises are increasingly reliant upon open source software. A full 95% of IT leaders say open source tools are key to their enterprise infrastructure. Simultaneously, we’ve witnessed a sharp increase in the adoption of artificial intelligence (AI) and machine learning (ML). Most IT divisions want to take advantage of AI in some form, and open source technologies will likely be vital to these efforts.

    I recently met with Moses Guttmann, co-founder and CEO of ClearML, to understand the benefits of adopting open source software within the sphere of artificial intelligence. To Guttmann, open source has many benefits—the visibility it grants can equate to helpful feedback from the developer community, and transparency can inform new feature development and identify potential security gaps. There are also countless open source tools to help organizations develop and deploy ML models.

    Below, we’ll consider the benefits and potential drawbacks of incorporating OSS in AI development and explore ways to optimize the use of AI within an organization.

    Benefits of Using Open Source for AI

    AI has evolved in leaps and bounds. What was pure sci-fi a few years ago has become a reality through ChatGPT and other AI-powered platforms. The capabilities of AI are awe-inspiring, but Guttmann believes it still requires fine-tuning to move from entertainment purposes into a valid business driver.

    For example, custom ML models are difficult to construct from scratch, and generic APIs aren’t always that customized to the use case at hand to be valuable. Instead, Guttman foresees more and more organizations downloading open pre-trained models and retraining or customizing them to meet their specific needs.

    For software providers, there are many benefits to adopting an open source strategy. The visibility it creates helps evolve a project with feedback from the community, said Guttmann. This, in turn, helps organizations build better, more stable products. For example, ClearML adopts plenty of OSS to power their user interface, backend and other components, in addition to providing a popular open source CI/CD framework for ML workflows. “We’re true believers in the power of community and like to work with open source and contribute back to these projects,” said Guttman.

    Use Cases for Open Source in AI Development

    Open source software is powering innovation in many ways. And when it comes to AI, there are numerous open source projects to help accelerate AI development. Such projects encompass pre-trained models, data-structuring tools, frameworks to train models and AI deployment pipelines. For example, many open source machine learning frameworks can help engineers build and train their models from scratch. These free-to-use tools include TensorFlow, Keras, PyTorch, H2O, XGBoost and others.

    However, training models from scratch is time-intensive and complicated, said Guttmann. Instead, another option is to use pre-trained models accessible on GitHub or other repositories. Some popular examples are PaddleNLP and Natural Language Toolkit for natural language processing, OpenCV for machine vision and DeepFaceLab for deepfakes. There are also many open source Python packages that can structure and clean data for ML model training purposes.

    Open source software can also be applied to streamline the ML DevOps pipeline itself. AI requires intense processing and is typically deployed to its own computing environments. Infrastructure management around running and training AI is a promising area where open source could assist, said Guttmann. “Automating this process with an abstraction layer to allow data science and ML engineers to access product-grade hardware is a must,” said Guttmann.

    Potential Downsides of Open Source Usage

    Yet, of course, there are some potential downsides to using open source software within the field of AI. Supply chain attacks are still a persistent threat, and numerous open source software risks can present themselves. These include bad actors compromising a legitimate package, name confusion attacks, unmaintained software and untracked dependencies. License restrictions could also potentially block the inclusion of OSS in certain projects.

    Thankfully, the benefits of OSS appear to outweigh these concerns. Automated vulnerability scanning techniques can help detect known issues. It also helps that 89% of technology leaders see enterprise open source as more secure or as secure as proprietary software, according to a Red Hat report.

    Tips For Getting the Most From AI

    Open source is powering digital innovation on many fronts, including AI. But, simply looping in OSS isn’t the only aspect of fully leveraging AI—another will be the operationalization of ML management. The right automation infrastructure in place could enable the agility necessary to continuously retrain models. And since there are potential gaps in the CI/CD process, Guttmann recommended separating AI/ML from your normal CI/CD for security reasons.

    Guttmann also believes that, in general, companies should be more transparent around ML models, including sharing details behind their creation and visibility regarding the datasets fed into them. Overlooking this could lead to ethical concerns. Furthermore, limiting the “hallucinations” generative AI produces is another huge gap that must be bridged, said Guttmann. This could be solved by simply allowing the system to respond with “I don’t know,” instead of confidently spouting nonsense.

    In summary, open source could bring many benefits to bespoke AI/ML adoption. Many mature open source tools exist to enable engineers to create advanced AI and oversee the management and deployment of custom ML models. But the real test will be retaining this open creed by upholding visibility and transparency into the end creations.

  • Modern DevOps is a Chance to Make Security Part of the Process

    Modern DevOps is a Chance to Make Security Part of the Process

    I’ve mentioned before, and many of you have lived through, the slowly changing beliefs around DevOps versus security. We are past the days of “Security slows us down” and into “How can we bake security into the development process?” which is essential. Indeed, I would say it’s more essential every day as the number of threat actors and their use of automation to perform more attacks increases.

    So where can we slip in a little security to protect those sweet, innocent apps from the Big Bad Wolf? Let’s make a list, then chat about it.

    • Source code
    • Inclusions–libraries, shared objects, etc.
    • Container/cloud images
    • Network
    • Running applications and APIs

    This is honestly not an exhaustive or detailed list, but we’re writing a blog here, so let’s stop there so we have time to discuss.

    Source code security is greatly enhanced by putting in any of a dozen development security tools, which include static and dynamic security scanners along with a variety of other features.

    Inclusions are often nested and confusing. A mod that developers include relies on other mods and libraries—sometimes so many that the developer can’t even list them all. So, this type of security starts with software composition analysis (SCA), then uses the list that generates to pursue vulnerabilities—normally by looking for the included libraries in a vulnerability database. Several prominent source code security solutions bundle at least the SCA part, and some also help nail down included vulnerabilities. Check with your vendor if you’re just getting started here.

    Container images are akin to the “golden images” of old. Build one that has what most applications need, add on the security that an organization wants most applications to support and then have every project start there and only add what this specific app needs. That allows for scanning of the base image so all applications start out at least somewhat secure. Cloud images can be done much the same, but beginning at a higher level. Look into registry security or image scanning tools to meet this need. It is worth asking your source scanning vendor if they offer this functionality; some do.

    The network on which an application will be exposed needs to be locked down. While the access points into the org probably are protected, portability of applications means that the application itself should be locked down wherever it uses that network. Tools are specific to the platform and networking in use, so look into it—I can’t offer much more generic advice.

    Security has long tried to lock down running applications—generally with pushback from developers and even ops, a bit. Between web application firewalls (WAFs) and API security, we have the ability to stop a whole host of attacks on their way in … But you have to use WAFs and API security best practices. If you’re starting from scratch, consider tools in the application and API security space that protect against both the web UI and API attacks with a breadth of technologies. For those with a WAF, look at API security tools that protect APIs. For those with API security covered, consider a next-generation WAF.

    My usual encouragement applies. You are rocking it, and all of these tools are increasingly integrated into the DevOps toolchain, so it’s worth the time investment to get them set up and let them run. If you’re just starting out, start with source code security. Honestly. It will make the overall app more secure by tightening its source. But don’t ignore the ops side, as that is part of the attack surface. Protect those apps you built and/or maintain that are keeping the org running.

  • Eclipse Foundation Touts Java SE Temurin Certification Momentum

    Eclipse Foundation Touts Java SE Temurin Certification Momentum

    The Eclipse Foundation revealed today the number of downloads for Java Standard Edition (SE)—dubbed Eclipse Temurin—certified using both a technology compatibility kit (TCK) and compatibility tests for evaluating associated runtimes reached 12.3 million in February.

    Tim Ellison, a project lead for creating compatibility tests for the Eclipse Foundation, said that level of activity suggests the governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based OpenJDK source code from multiple providers is gaining traction. Members of the Adoptium working group include Alibaba Cloud, Bloomberg, Google Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, Red Hat and Rivos. Eclipse Temurin has also become the default Java option for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

    OpenJDK is a free and open source implementation of Java SE provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that allows it to run compatibility tests to ensure conformance to the Java specification.

    One of the reasons Eclipse Temurin is gaining traction is organizations are looking to reduce Java licensing costs during uncertain economic times by relying on an open source platform. At the same time, a consistent set of certified runtimes also reduces the level of DevOps friction that might otherwise be encountered when building and deploying Java applications, noted Ellison. There will, of course, always be multiple Java runtimes, but the level of incompatibility that would exist without testing them could be substantially higher, he noted.

    Despite the plethora of programming languages developers use, after more than 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Developers may be building and deploying applications faster, but most of them will continue to rely on the programming language they already know rather than master another. In addition, many of the Java applications that have been deployed over the last two decades are now being modernized within the context of a cloud migration.

    Arguably, Java is experiencing a renaissance following efforts to make it simpler for multiple organizations to contribute code to open source projects and increase the pace of innovation. The rate at which organizations can absorb that innovation will naturally vary, but it’s clear that more organizations are now running later editions of Java that improve both performance and cybersecurity overall.

    In the meantime, DevOps teams should expect to see more Java projects moving through pipelines in the months and years ahead. While not every legacy Java application may need to be updated before being retired, it’s apparent that the bulk of Java applications are still relevant. As such, it’s probable the efforts to modernize those applications will keep DevOps teams occupied well through the end of the decade.