devopsy.kinsta.cloud

Tag: devops best practices

  • System Initiative Employs Modeling to Reinvent DevOps

    System Initiative Employs Modeling to Reinvent DevOps

    System Initiative (SI) today made available in private beta a platform that creates simulations of IT environments. The platform leverages a built-in framework to generate the code needed to update an application environment.

    Fresh from raising $18 million in funding, SI CEO Adam Jacob said the ultimate goal is to provide a level of abstraction for DevOps environment that eliminates much of the complexity that creates bottlenecks in DevOps workflows.

    For all intents and purposes, DevOps is fundamentally broken; there are too many manual processes that need to be performed, he added. The SI platform represents an ambitious effort to reimagine how DevOps processes are constructed and maintained, said Jacob.

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

    Feedback loops are also provided in real time to provide insight into the viability of a configuration and eliminate the need for no state files to track and no ‘plan’ versus ‘apply’ stages.

    As more organizations realize how dependent they are on software to drive digital processes, many of them are looking to improve the productivity of developers and the DevOps teams that support them. After a wave of initial progress, many DevOps teams find themselves supporting DevOps workflows using custom code that varies widely in quality. SI is making a case for a digital twin platform that generates a set of code that can be applied more consistently, rather than relying on a DevOps engineer to write code.

    Ultimately, the goal is to launch a new DevOps era to eliminate most of the silos that slow down application development and deployment, noted Jacob. In fact, one of the reasons few organizations today 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, he added.

    A recent survey conducted by the Continuous Delivery Foundation (CDF), for example, found only 22% of respondents are using CI and CD approaches to automate all building, testing and deployment of code in a production environment. Instead, many organizations are using a combination of DevOps and waterfall processes to manage application development and deployment.

    It’s not clear how many organizations are willing to fundamentally change the way they have implemented DevOps. But at a time when more organizations are moving to centralize the management of DevOps, many of them are evaluating their options, at the very least. The issue, of course, is that multiple DevOps teams within the same organization have committed to disparate platforms. Enticing them to centralize on a common platform will require not just a compelling technical advantage but also a significant amount of political capital.

  • How Open Source Can Enhance Developer Experience

    How Open Source Can Enhance Developer Experience

    Developer experience (DX) is becoming more and more of a competitive advantage among developer-facing tools and platforms. A great developer experience that’s easy to follow and implement can truly help a software tool stand out from the crowd.

    Simultaneously, open source software is all the rage. In fact, a recent StackOverflow survey found open source software (OSS) to be, by far, the most revered and proven technology trend.

    With that in mind, what are the synergies between developer experience and open source? And how can building in an open source format aid the developer experience for your public-facing toolsets and internal development platforms?

    I recently met with Adam Frank, SVP of product and marketing at Armory, to explore the state of developer experience and open source adoption. According to Frank, open source can bring numerous DX benefits. Below, we’ll explore these areas and consider why organizations might benefit from adopting more open source within their developer-facing initiatives.

    The State of Developer Experience and Open Source

    So, what is the state of developer experience, and why is it important now? Well, DX is continually leveraged to help improve agility and competitiveness in the market. In addition to granting differentiation, DX also enables more flexibility, helping users switch from one tool to another if necessary.

    “Developer experience is at the forefront right now because technology and change are moving faster than ever before,” said Frank. “Companies need to focus on DX as a competitive advantage to survive and thrive.” At the same time, open source can help organizations move quickly and iterate more efficiently.

    Yet, historically, open source has not been associated with fantastic DX. Most of us have at least one horror story of an open source project simply going belly-up without warning. It’s common for an OSS tool to lack comprehensive documentationor suffer from a lack of funding for ongoing maintenance, zero customer support and deprecated modules. Some tools that developers directly download and contribute to may not possess a quality DX emphasis, says Frank.

    However, the status quo for OSS has undoubtedly evolved over the years, he adds. Nowadays, there are more established groups, like Linux Foundation’s Cloud Native Computing Foundation (CNCF), with specific Technical Oversight Committees (TOCs) to oversee individual projects. The maturity of OSS ownership now ensures core projects stay relevant and receive continual support—not to mention ongoing developer experience enhancements.

    On the other side, OSS is often absorbed by a platform team to enable their internal developers to move faster or ship more code, says Frank. From this perspective, open source communities give platform engineering the opportunity to contribute back to the project, helping them solve deeper-level problems that are more specific to their environments.

    How Open Source Can Enhance Developer Experience

    Not all IT leaders are sold on the idea of building in a transparent, open source model. Yet, this enhanced transparency can bring dividends in the long run, especially where developer experience is considered. Frank shared some of the benefits of adopting open source.

    Receiving Feedback From The Community

    “As a product manager, you want as much feedback from your users as you can gather,” said Frank. Receiving user feedback is a great way to fix DX issues, and OSS gives you that on a larger scale. By adopting open source, you benefit from collecting insights from your customer base and the developer community at large. This can translate into a broader range of use cases, which can significantly improve projects and overall experience.

    Increasing Ecosystem Transparency

    Building in a more transparent and open fashion so that everyone has the ability to submit pull requests can also help you work together with potential partners. This makes it easier to develop third-party integrations that ensure the broader ecosystem can work together. By decreasing the barrier to entry through OSS, you provide others with the ability to solve more problems around developer experience.

    Streamlining the Developer Toolchain

    “Developers want to innovate; they want to solve problems,” said Frank. Open source can also help expose inefficiencies in the developer toolchain and, notably, many open source CI/CD tools are often leveraged to automate deployment and increase efficiency. The end result is that developers can focus on innovating their own competitive advantage. “Making the deployment aspect of the developer lifecycle really seamless can significantly improve their experience,” he said. Therefore, any tools or extensions around CI/CD are an excellent area to consider open-sourcing.

    Increasing Flexibility

    Another benefit of the open source model is that you have far more flexibility than off-the-shelf proprietary software. As a customer, you don’t have to wait to submit enhancement requests. With OSS, you can fork a project or quickly collaborate with the maintainers. This equates to making fixes far quicker and providing the ability to customize developer experiences to the tasks at hand.

    Best Practices to Ensure Open Source Improves DX

    Open source provides many key benefits that can enhance software development and delivery. But, this should be taken with a grain of salt, as best practices still must be followed to ensure open source enhances, not hinders, developer experience.

    For example, Frank mentions that simplicity should be a guiding light. “Have simplicity for the user experience design in the forefront of everything you’re building and thinking about,” said Frank. Adopting simplicity should help ensure developer-facing materials are structured well and documented in an easy-to-comprehend manner.

    On that note, open source projects will require standards around areas like good documentation and well-written APIs that abide by contracts, said Frank. Anything less will hinder developers and confuse them with disparate data formats. On that note, he has witnessed OpenTelemetry emerge as a common way to unify data that systems produce with standard formatting, which increases the observability of these environments.

    Lastly, it’s critical to hire talent with experience in open source. Bringing in folks that have knowledge of how OSS communities operate will make onboarding easier and encourage safer open source security practices as well.

    What the Future of DX and OSS Holds

    Open source appears to aid developer experience in many ways, from driving more innovation, opening software up to feedback and developing a closer-nit developer community. But what does the future of developer experience and open source look like?

    According to Frank, we will likely see increased data standardization that makes it easy to work with various projects and data formats. OpenTelemetry, for example, makes aggregating logging easier. We’ve also seen standardization around OpenAPI Specification for describing web APIs. Another example is FinOps Foundation’s FOCUS specification to unify cost analysis.

    Open source tends to leverage open source. And as the industry continues to coalesce around open standards, we’ll likely see more robust, compatible layers of abstraction emerge throughout the market, Frank predicts.

  • Despite DevOps, Software Supply Chain Security Challenges Persist

    Despite DevOps, Software Supply Chain Security Challenges Persist

    A survey of 397 IT, cybersecurity and application development professionals conducted by Enterprise Strategy Group (ESG) found that while most respondents work for organizations that have adopted DevOps practices, multiple software supply chain security issues and DevSecOps concerns have yet to be addressed.

    The survey, conducted on behalf of Data Theorem, a provider of a platform for securing application programming interfaces (APIs), the survey also found 82% of respondents have adopted DevOps, with 51% reporting they make extensive use of DevOps workflows (51%). Nearly three-quarters (73%) are deploying code weekly and 31% are deploying code daily.

    However, securing DevOps workflows remains a work in progress, with 41% reporting security teams lack visibility and control of development processes. Other issues include new builds deployed to production with misconfigurations, vulnerabilities and other security issues (40%), developers skipping security processes (39%), software released without going through security checks and/or testing (38%), lack of security process consistency across different development teams (38%), security team can’t keep pace with release cadences (34%) and developers’ reluctance to work with security (29%).

    API security is also becoming especially challenging, with 92% of respondents dealing with at least one API security incident in the last 12 months. Well over half (57%) have dealt with multiple API security issues in the last 12 months.

    On the plus side, the survey also found that more than half (54%) of teams responsible for securing APIs are involved with development as soon as or before the APIs are published. A full 97% said developers either have a good (22%) or high level (71%) of API security knowledge. A total of 89% reported their organization provides formal API security training to their development teams. More than three-quarters (78%) can remediate an API vulnerability within a day, and 39% reported they can do so within hours. A total of 60% reported a dedicated budget has been specifically allocated to API security, with another 30% identifying it as a discrete item within their cybersecurity budget. Two-thirds (66%) said spending on API security would significantly increase in the next 12 to 18 months.

    The use of APIs is only going to increase in the months and years ahead. Well over one-third (36%) of respondents are using APIs across all their applications, with 50% expecting this to be the case in two years. Another 44% reported most of their applications are using APIs., with 32% expecting this to be the case in two years. More than three-quarters (76%) of organizations reported that they have an average of 26 APIs per application and 53% have more than a quarter of their APIs facing the internet.

    More than a third (35%) are updating APIs daily while another 40% do so weekly. A full 61% are using APIs to connect microservices.

    Data Theorem COO Doug Dooley said those APIs are now being targeted by cybercriminals that routinely test the weaknesses of every API after each deployment and update. The most common types of API attacks reported by survey respondents included exposure of data (32%), account takeover (31%), denial of service (DoS) attack (31%), attack on misconfigured API (30%), fake account creation (28%), API injection attack (28%), ransomware (27%), data breach (26%) and content scraping (26%).

    Despite these issues, however, nearly three-quarters (74%) of survey respondents said they believe their organizations have a robust API security program in place, with 22% reporting they have some process in place. Organizations are using a mix of approaches including API security tools (59%), web application firewalls (WAFs) (57%) and API gateways (50%), distributed DoS mitigation (48%) and bot management solutions (42%).

    Challenges included managing multiple tools (29%), visibility into and control of APIs (28%), inventorying APIs (27%), inconsistent adoption of APIs (27%), API security testing (27%), data governance/exposure (26%), discovering and remediating misconfigured APIs (26%), keeping pace with threats (26%) and accurately tracking API usage (25%).

    Significant API security concerns included API authentication issues (41%), account takeovers (39%), identifying and tracking third-party APIs (38%), using tools not purpose-built for security (38%), shadow/undiscovered APIs (38%), abusive behavior bypassing app security tools (38%), denial of service attacks (38%), data governance and/or data exposure issues as a result of insecure APIs (37%), abusive behavior bypassing bot management (37%) and outdated/unneeded APIs, also known as zombie APIs. (33%).

    The type of vulnerabilities that are of the greatest concern are sensitive data exposure (34%), access control vulnerabilities (31%), API business logic flaws (31%) and DDoS attacks (30%).

    More than 79% of respondents, however, are relying on manual testing and review processes to ensure APIs don’t expose sensitive data (79%), with 63% having automated alerting capability for when sensitive data is exposed.

    Overall, it’s apparent that more resources as being applied to securing software supply chains in general and APIs specifically. However, given the amount of software being built and deployed, it may be a while before organizations see the return on those investments.

  • Continuous Testing: The Key to Quality Assurance in the DevOps Era

    Continuous Testing: The Key to Quality Assurance in the DevOps Era

    Continuous testing has emerged as a critical aspect of quality assurance in the DevOps era. In recent years, there has been a rapid transformation in software development methodologies. With the advent of DevOps, there has been a significant shift toward automation and continuous integration and delivery (CI/CD). The traditional approaches to quality assurance are no longer adequate to meet the needs of modern software development practices. Continuous testing is the key to ensuring that the software is delivered on time, with quality and reliability.

    Definition of Continuous Testing

    Continuous testing is a process of executing automated tests continuously throughout the software development life cycle to provide rapid feedback on the quality of the code. It is an essential component of DevOps that ensures that the software is always ready for release. Continuous testing allows for the detection of defects and errors at an early stage, which reduces the risk of production issues and enhances the overall quality of the software.

    Importance of Continuous Testing in DevOps

    To understand the importance of continuous testing in DevOps, it is essential to understand the evolution of quality assurance in software development.

    Traditional Waterfall Method

    The traditional waterfall model of software development had a sequential approach to quality assurance. Testing was only performed after the development phase was completed. This approach often led to delays and increased costs due to detecting defects later.

    Agile Methodology

    The Agile methodology introduced an innovative approach to quality assurance. Testing became an integral part of the software development lifecycle, and the focus was on continuous feedback and improvement. However, even with Agile, testing was still done in batches, and there was a significant amount of manual testing involved, which could be time-consuming and prone to errors.

    DevOps Model

    The DevOps model took the concept of continuous feedback and improvement to a new level. With DevOps, testing became automated, and continuous integration and delivery became the norm. This approach significantly reduced the time to market, increased collaboration between development and operations teams, and enhanced the overall quality of the software.

    The Role of Continuous Testing in DevOps

    Definition of DevOps

    DevOps is a software development methodology that emphasizes collaboration and communication between development and operations teams to deliver software products rapidly and reliably. It involves the integration of development, testing and operations into a continuous process, with automation as a key enabler.

    Importance of Continuous Testing in DevOps

    Continuous testing is a critical component of DevOps. It enables the testing of software continuously throughout the development lifecycle, which helps to identify defects and issues early on.
    This early detection of issues is essential in reducing the risk of production issues, and it allows for timely feedback, which facilitates faster decision-making.

    Benefits of Continuous Testing in DevOps

    There are several benefits of continuous testing in DevOps, including:

    · Faster time to market: Continuous testing enables the rapid release of software, reducing the time to market significantly.
    · Improved collaboration: DevOps emphasizes collaboration between development and operations teams, and continuous testing facilitates this collaboration by providing continuous feedback on the quality of the code.
    · Enhanced quality: Continuous testing enables the early detection of defects and issues, which reduces the risk of production issues and enhances the overall quality of the software.
    · Reduced costs: Continuous testing can help to reduce costs by identifying defects and issues early on, which reduces the cost of fixing issues later in the development cycle.

    Implementing Continuous Testing in DevOps

    Choosing the Right Test Automation Tools

    The selection of the right test automation tools is critical to the success of continuous testing in DevOps. Some of the popular test automation tools for DevOps include Selenium, Appium, Cucumber and JUnit.

    It is essential to choose a tool that is easy to use, integrates well with other DevOps tools, and has strong community support.

    Building an Effective Test Automation Framework

    An effective test automation framework is essential to implementing continuous testing in DevOps. A test automation framework is a set of guidelines and standards that help in the creation and execution of automated tests.

    A good framework should be modular, flexible, and scalable. It should also be easy to maintain and extend as the project grows.

    Integrating Continuous Testing Into the DevOps Pipeline

    To implement continuous testing in DevOps, testing should be integrated into the DevOps pipeline. The DevOps pipeline is a series of steps that automate the software development process, from code commit to production release.

    Continuous testing should be integrated into every stage of the pipeline, from unit testing to acceptance testing.

    Best Practices for Continuous Testing in DevOps

    To achieve the full benefits of continuous testing in DevOps, it is important to follow best practices. Some of the best practices for continuous testing in DevOps include:
    · Test early and often: Testing should begin early in the development cycle and continue throughout the development process.
    · Automate everything: Automation is essential for continuous testing in DevOps. All tests should be automated, including unit tests, integration tests and acceptance tests.
    · Integrate testing into the DevOps pipeline: Testing should be integrated into every stage of the DevOps pipeline, from code commit to production release.
    · Use the right test data: Test data should be relevant and representative of real-world scenarios.
    · Collaborate across teams: Collaboration between development, testing and operations teams is essential for the success of continuous testing in DevOps.

    Challenges and Solutions for Continuous Testing in DevOps

    There are several challenges to implementing continuous testing in DevOps, including:
    · Test data management: It can be challenging to manage and maintain relevant test data that accurately represent real-world scenarios.
    · Test environment management: Ensuring that the test environment is consistent and reliable can be a challenge, especially in complex applications.
    · Test automation maintenance: Test automation scripts can become complex and challenging to maintain, especially as the application evolves.

    Strategies for Overcoming Continuous Testing Challenges

    There are several strategies for overcoming the challenges of continuous testing in DevOps, including:
    · Test data management: Creating synthetic test data can help ensure that the data is relevant and representative of real-world scenarios.
    · Test environment management: Using containerization technology such as Docker can help ensure a consistent and reliable test environment.
    · Test automation maintenance: Regular maintenance and refactoring of test automation scripts can help keep them up-to-date and relevant.

    Conclusion

    Continuous testing is the key to ensuring quality in the DevOps era. It enables the rapid release of software, reduces the risk of production issues and enhances the overall quality of the software. Implementing continuous testing in DevOps requires choosing the right test automation tools, building an effective test automation framework, integrating testing into the DevOps pipeline and following DevOps best practices. Although there are challenges to implementing continuous testing in DevOps, these challenges can be overcome with the right strategies and practices. By implementing continuous testing in DevOps, organizations can achieve faster time to market, improved collaboration, enhanced quality and reduced costs.

  • Orgs Shift Toward Centralizing Automation Initiatives

    Orgs Shift Toward Centralizing Automation Initiatives

    A survey published today found that 75% of respondents recognized that automation silos hamper their ability to unify cloud operations across functions.

    Conducted by CloudBolt Software, the survey polled 350 senior IT and DevOps leaders at organizations with more than 3,000 employees. On a positive note, the survey found 57% of respondents were starting to pursue a more centralized approach to automation, with a total of 88% acknowledging that having all previous and new automation centralized for the entire organization would ensure compliance, bolster security, enable business continuity, encourage reuse and reduce risk.

    Rather than taking a more holistic approach, well over half of respondents (57%) reported automation efforts are limited to specific silos. On average, organizations are employing 27 different automation tools their organizations have deployed, using one or a few as they see fit, with little to no consistency across teams. More than half (55%) of respondents said they have four or more separate automation teams, with 95% noting that each of those teams operates in their own silo.

    CloudBolt CTO Rick Kilcoyne said that lack of continuity clearly creates inefficiencies and redundancies that conspire to raise the total cost of IT. The challenge is that each team tends to favor one approach to automating a silo with little to no regard for a larger overall strategy to create an automation standard, he said.

    That approach also creates issues whenever a member of one of those teams leaves an organization, he noted. In fact, the survey found 77% of respondents reported that continuity is at risk any time a vital member of the team leaves.

    CloudBolt has been making a case for a federated automation platform that can be invoked either via application programming interfaces (APIs) or a graphical user interface (GUI) that provides access to low-code tools. The goal is to make the platform equally accessible to DevOps teams or IT administrators that tend to lack programming skills, and do so in a way that doesn’t require individual teams to replace their automation platform of choice. Instead, each of the automation platforms can be programmatically invoked via a central framework, said Kilcoyne. That approach eliminates any political debate over the potential need to replace one team’s favored automation platform with another, noted Kilcoyne.

    Regardless of who is accessing the platform, most organizations would be well-advised to develop a center of excellence for automation, he added.

    DevOps teams have always been committed to ruthlessly automating as many IT processes as possible, but in many cases, that has resulted in a plethora of automation tools being employed. In effect, automation may have become too much of a good thing. One approach to regaining control over those platforms is to create a platform engineering team that centralizes the management of DevOps workflows.

    Regardless of approach, Kilcoyne said the most important thing for any team to do before automating an IT workflow is to first understand how to manually set it up. Too many IT teams are trying to apply automation to processes they don’t really understand with mixed results, he added.

    The one thing that is certain, especially with the rise of artificial intelligence (AI), is the management of IT is going to become more automated.

  • Blameless Integrates Incident Management Platform With Opsgenie

    Blameless Integrates Incident Management Platform With Opsgenie

    Blameless this week announced it has integrated its namesake incident management solution with the Opsgenie alerting platform from Atlassian.

    Aaron Lober, director of product marketing for Blameless, said the Blameless platform is now integrated with both Opsgenie and PagerDuty, the two most widely used platforms for managing alerts.

    Blameless provides an incident management platform that normalizes data collected from a wide range of DevOps tools and platforms to determine how best to respond to different incident classes. Armed with those insights, it then becomes possible to quickly assemble the best team to respond to an event, said Lober.

    That capability reduces stress because Blameless also surfaces recommendations for resolving incidents based on the data it has collected, he added.

    The Blameless platform is tailored to organizations that have hired site reliability engineers (SREs) to manage IT operations using DevOps best practices, noted Lober. The overarching goal is to eliminate rote processes that, over time, conspire to burn out incident management teams that often experience high turnover rates, he added.

    Opsgenie has been connected to the Blameless platform via the service catalog and alerting functions. Blameless users responding to or managing an incident can escalate issues to any teams defined within Opsgenie. The service catalog and alerting data generated throughout the life cycle of an incident is automatically captured and stored on the Blameless Incident Timeline. That capability makes it possible to identify appropriate service owners and the escalation protocol that was followed by that team. Blameless can also display the actual user name of each responder that has been notified.

    When accessing Blameless via Slack or Microsoft Teams, Opsgenie can automate both when an incident channel is created and pre-select relevant services that should be made available. Alerts can also be manually triggered using commands from the Blameless chatbot for those who prefer to trigger alerts from within Slack or Teams themselves.

    As IT environments become increasingly more complex, more organizations are making a concerted effort to apply DevOps best  practices to incident management. The goal is to reduce downtime and increase overall resiliency at a time when organizations are more dependent on software than ever. As part of that effort, IT teams should identify the repetitive processes that span multiple incidents and then move to automate as many as possible.

    In the longer term, it’s not clear what impact artificial intelligence (AI) will have on incident management. At some point, though, IT teams should expect their efforts to be augmented by machine learning algorithms capable of identifying issues before they balloon into a major crisis. However, there will always be some human intervention required to manage incidents for the foreseeable future, noted Lober.

    In the meantime, most IT teams should continue to expect the unexpected at a time when IT environments have never been more dynamic and change multiple times a day.

  • 5 Tips to Consider When Introducing Infrastructure Automation

    5 Tips to Consider When Introducing Infrastructure Automation

    Although we discuss infrastructure automation often, the fact is that a lot of manual processes still exist throughout DevOps. Whether it’s rewriting scripts to spin up new servers, updating cloud-native policies or configuring computing environments, manual toil is an all-too-common reality. To make matters worse, engineers commonly create lengthy scripts that work in isolation but are too bulky to be reusable by other developers working with slightly different constraints.

    More infrastructure automation is the key to increasing deployment agility, but setting aside time to automate your daily workflow can easily take a back burner, especially when developers are already behind on their long list of to-dos. So, for the time-pressed, where should they start? What exactly should be automated? And how can we effectively reuse and share automation to help other areas of the business?

    I recently connected with John Laffey, technical product marketing director, Puppet. Laffey has thirty years’ worth of tech support and engineering operations knowledge under his belt and was “doing DevOps before it was called DevOps.” He shared with me five helpful tips to think about when introducing more infrastructure automation into your workflows. Below, we’ll expand on each of those points and consider other best practices around automation as the industry moves toward platform engineering.

    1. Automate Things That Interrupt Your Day

    First, Laffey recommended starting with the things that are easy to fix. These are the tedious actions that interrupt your day. Perhaps a disk runs out of space and troubleshooting takes 15 or 20 minutes. Minor interruptions like this might seem like part of the job, but they definitely add up over time.

    2. Automate Things You Can Reuse

    Secondly, try not to automate things for an ultra-specific purpose, said Laffey. Instead, focus on building automation that is more generic and can have more value to others. This follows the DevOps mantra of teamwork and collaboration. One-off automation that is too verbose or specific to a certain condition won’t apply well across groups.

    3. Automate Stuff That Doesn’t Change Much

    Next, automate the infrastructure that isn’t prone to change. These are fairly reliable things that you’re sure will be part of your systems for the foreseeable future. Because if a component does end up having to be updated often, supporting the automation could be more hassle than it’s worth. “Don’t trade fixing problems for fixing automation,” said Laffey.

    4. Start Small

    Here’s some sage advice applicable to most new projects with a big scope—start small. Laffey recommended starting by automating the easy stuff that has proven immediate value. These tasks should be modular and do one specific thing, like rebooting a machine or draining a log file. “Automate things in chunks that you can put into a toolchain.”

    Too often, teams try to automate everything all at once. But by taking big bites, you can quickly get off track and potentially add to technical debt. If you keep things modular, you’ll find it easier to change and reuse this automation.

    5. Share and Be Open

    This last tidbit is more of a cultural change—don’t code so that you’re the only one who knows about it! Sometimes, engineers don’t necessarily want the world to know about the automation they create. They might worry about automating their job away. Yet, Laffey said, these worries are misplaced. There will always be more work to do, and automating toil away can free up time to help you focus on more exciting projects.

    So, Laffey encouraged DevOps and SREs to be open about the automation they create. Ensure they’re well documented and stored in a centralized repository to allow other departments to reuse your code. This can avoid the duplication of having five different versions of the same script written in different languages within the same organization!

    Next Step: Move From Scripts to Industry-Standard Tooling

    It can be challenging to argue for investing time and energy into infrastructure automation, especially when engineers are hard-pressed to keep the lights on. Yet, small gains in automation can make huge waves in the long term.

    Eventually, said Laffey, you’ll want to move away from using scripts within your toolchain, which he describes as a low-end DevOps maturity. But as you update your process, you’ll want to replace these scripts with more modern industry-standard tools like Terraform or Puppet’s DSL. He recommended slowly revamping scripts in a toolchain as you update them one by one. “Start where you are and avoid a monolithic approach.”

    In essence, platform engineering, Laffey explained, is wrapping DevOps principles at a higher level to make them more efficient. And we will likely see an increased emphasis on infrastructure automation as platform engineering gains more mindshare. “It’s going to become a necessity.”

  • Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    A global survey of 606 IT, security, application development and DevOps decision-makers found that the biggest barrier to adoption of DevSecOps best practices is cultural rather than technical. However, the survey, which polled organizations with more than 500 employees and was conducted by Progress, also found only 16% of respondents planned to prioritize addressing those cultural issues in the next 12 to 18 months.

    A full 71% of respondents cited culture as the biggest barrier to DevSecOps progress, with only 30% expressing confidence in the current level of collaboration between security and application development teams currently being achieved. In contrast, 46% of respondents were not particularly confident while nearly a quarter (24%) were not at all confident.

    Nevertheless, well over half of respondents (57%) said security threats are the number-one technology factor driving the evolution of DevSecOps, even though just over half (51%) admitted they were only somewhat familiar with how security fit into a DevSecOps workflow.

    Overall, 86%of respondents said they are experiencing security challenges that include prioritizing externally facing applications over internal applications (47%), securing different types of workloads that were using different development and delivery methodologies (46%), meeting delivery deadlines (45%) and meeting audit requirements specified by the security team (39%). Just over three quarters (76%) recognized they could be more strategic in managing DevSecOps.

    The top three initiatives needed to support a shift to a more strategic DevSecOps approach identified are more investment in continuous learning for developers and engineers (61%), upskilling of developers and engineers to move into site reliability engineering (SRE) roles (60%) and improved communication between developers, security and operations (60%).

    Survey respondents also identified a need to define a clear set of policies and procedures (66%), define the role and responsibilities of staff across teams (62%), create a continuous feedback loop (49%) and automate recurring security tasks (41%).
    Despite that level of awareness, however, only 40% said they believed implementing security training and upskilling efforts across multiple stakeholders was very important when implementing DevSecOps.

    Prashanth Nanjundappa, vice president of product management for Progress, said given all the cultural and technical challenges organizations face, it’s apparent that both a top-down and bottom-up approach to implementing DevSecOps best practices is required. Attempting to shift responsibility left toward application development teams is not going to suffice on its own, he noted.

    The survey also suggested that many organizations are trying to address application security issues as they modernize their application portfolio. A total of 59% said they struggled to attain buy-in/funding for refactoring efforts that didn’t provide new user capabilities. However, only 39% said they had adopted a comprehensive modernization approach based on cloud-native architecture principles, while another 22% felt they lacked one entirely. Just under a quarter (24%) said their approach to modernization is to largely rip-and-replace applications.

    The top business factor driving the adoption of DevSecOps was a focus on business agility enabled by fast and frequent delivery of application capabilities (59%). Just under half (45%) said it had taken six to 12 months to achieve a return on DevSecOps investments, while 31% said it had taken longer than a year. However, only half (50%) of respondents were familiar and interested in both infrastructure and policy-as-code.

    There is no doubt that the DevSecOps journey ahead will be long and arduous. However, there are also a wide range of small process changes that could have a massive impact in terms of improving application security in the short term. The challenge is to quickly identify those opportunities while at the same time employing a more systematic approach that ultimately makes it a lot simpler to implement a set of DevSecOps best practices consistently.

  • DevOps World 2022: DevOps is Not Just CI/CD

    DevOps World 2022: DevOps is Not Just CI/CD

    There was a time when pundits said that DevOps was the symptom and CI/CD the cure. While that may or may not be true, there is no denying that CI/CD is the very heart of DevOps. While that might still be true, DevOps today is so much more than CI/CD; it has evolved, far beyond just its core of CI/CD.

    In my preparations for the upcoming DevOps World 2022, held in Orlando, Florida, September 27 to 29, I’ve been briefed on upcoming product announcements by the CloudBees product team. I find it fascinating to see where the CloudBees product line is going. In many ways, CloudBees product evolution mirrors the evolution of DevOps itself.

    Today, DevOps includes areas such as observability, security and compliance, GitOps, cloud-native and more. Developing, integrating, testing and deploying software is only one aspect of today’s DevOps. Without divulging any specific product announcements that CloudBees will be making at DevOps World, I can tell you that CloudBees is on a journey that closely mirrors that of DevOps itself.

    In my opinion, this is as it should be. CloudBees was one of the pioneers of the DevOps movement. By harnessing Jenkins—the original DevOps killer app—CloudBees helped move DevOps into the mainstream. Of course, Kohsuke Kawaguchi (KK), the creator of Jenkins, has moved on from CloudBees and the Jenkins community was always independent of CloudBees. Nevertheless, many of us in the field see CloudBees and Jenkins as inextricably linked.

    While Jenkins is still widely deployed and used, it is no longer the epicenter of the DevOps universe. Over the last couple years, CloudBees has transitioned to become much more than just Jenkins or Enterprise Jenkins and remains at the center of DevOps innovation.

    This year‘s DevOps world will be a great opportunity for CloudBees to showcase just how far they’ve come from being solely the enterprise Jenkins company while remaining a preeminent end-to-end DevOps tools provider. If you want to know just how far, well, stay tuned for our coverage of DevOps World where we will be covering all of the product announcements as well as speaking to CloudBees executives and customers about the new products and product lines and capabilities that will be announced.

    I have written before that the theme for DevOps World this year is DevOps Remix. Our own DevOps Experience virtual event, coming in November, has a theme of DevOps Everywhere. I think both of these themes speak to the same general idea: DevOps is going where it’s never gone before. It has evolved beyond CI/CD to a new way of developing, delivering and managing software that includes securing it and testing it. Over the next few years, I think we’ll see we’re entering a new golden age of DevOps.

    If you can, join us in Orlando for DevOps World. Techstrong.TV will be broadcasting live from the event; if you can’t make it, we’ll keep you updated on all of the developments announced there. Also, join us in November for our own DevOps Experience virtual event, which will highlight DevOps Everywhere: The Edge and Beyond. Hope to see you soon!

     

  • TechStrong Con: Downturn Brings Additional Sense of DevOps Urgency

    TechStrong Con: Downturn Brings Additional Sense of DevOps Urgency

    Regardless of whether the overall economy is experiencing a correction or is on the cusp of a recession, organizations are going to prioritize some projects over others as resources become more constrained.

    During the “DevOps: Has the Bubble Burst?” panel made up of DevOps executives and investors from venture capital firms that kicked off the virtual TechStrong Con event today, panelists said organizations will need to continue to invest in DevOps automation and cybersecurity to ensure their long-term survival.

    However, the number of IT projects that organizations will be able to simultaneously invest in is likely to decline, said Chenxi Wang, general partner for Rain Capital. “We are starting to see a slowdown of projects, for sure,” she said.

    Fundamentally, organizations will need to decide not so much whether they will modernize legacy monolithic applications but rather at what rate. More than 70% of organizations’ codebases are still based on legacy monolithic architectures, noted Wang.

    No one knows for sure how long the current economic contraction might last, but, as in any downturn, organizations will seek to conserve cash, said JFrog CEO Shlomi Ben Haim. DevOps initiatives will continue to be prioritized because otherwise, organizations risk falling far enough behind that they may not be able to ever recover, he added. “DevOps is in a good place,” said Ben Haim.

    In fact, thus far many DevOps companies have yet to see a decline in demand because organizations are investing in automation to reduce their technical debt costs, noted Thomas Krane, managing director for Insight Partners. “It’s a matter of life or death,” he said.

    At the same time, Krane said organizations might want to take a hard look at the profitability of the vendors they are counting on to drive that innovation. Vendors that have been counting on venture capital funding to maintain operations may soon find that money much harder to come by as capital becomes scarce, he noted.

    The core issue will become how quickly returns on investment (ROI) are generated, added Incredibuild CEO Tami Mazel Shachar. “There is going to be a lot more focus on ROI,” she said.

    In the meantime, the debate over what constitutes DevOps continues. Some narrowly define DevOps as a set of development activities that revolve around continuous integration/continuous delivery (CI/CD) platforms. Others definitions of DevOps include everything from application testing to observability and application security. No matter how big the proverbial DevOps tent is defined to be, however, the number of organizations that are embracing DevOps—and now DevSecOps—workflows more deeply only continues to increase.

    The challenge is focusing those efforts on the projects that deliver the most value for the business in the face of executive uncertainty about the future. Of course, nothing quite focuses the mind like an impending crisis; for better or worse, it will require more organizations to honestly assess their current capabilities.