devopsy.kinsta.cloud

Tag: devops tools

  • HCL Software Expands DevOps Portfolio

    HCL Software Expands DevOps Portfolio

    HCL Software has launched a DevOps practice and portfolio along with three updates to HCL tools.

    Version 2.0 of HCL Accelerate 2.0 adds support for policy management and out-of-the-box reports to the value stream management platform, while version 7.1 of HCL Launch automates the application of corporate governance rules to the continuous delivery platform.

    HCL Software has also updated HCL OneTest 10.1 to include OneTest Server, a wizard-driven test authoring environment and OneTest Data, a data fabrication tool that ensures the right data is on-hand for testing, along with support for Kubernetes and Red Hat OpenShift application development and deployment platform.

    Finally, HCL Software is making available HCL Software DevOps Power Pack, which bundles HCL Accelerate, HCL Launch and HCL OneTest, along with 40 hours of services for installation, configuration and team adoption into a single offering.

    Steve Boone, head of product management for HCL Software DevOps, said the goal is to make sure IT organizations that adopt HCL tools as part of a DevOps initiative are successful.

    Boone said HCL Software is focused on extending the value of investments made in continuous integration (CI) platforms. Most organizations today have multiple CI platforms installed, some of which even come from different vendors. The HCL Software portfolio enables DevOps teams to scale deployment processes across multiple platforms along with tools such as value stream management software to better manage DevOps processes.

    In contrast, CI/CD platform providers often offer many of the same capabilities, but those offerings are optimized for a specific CI/CD platform.

    The HCL Software portfolio of DevOps tools traces its lineage back to IBM, which sold its AppScan, BigFix and Lotus Notes technologies to HCL at the end of 2018. Since then the company has expanded its portfolio to include DevOps tools and services but it is no longer committed to developing those offerings in lock-step with IBM. As a result, IT organizations should expect to see more frequent updates, Boone said.

    In the meantime, interest in DevOps tools and processes has increased in the wake of the COVID-19 pandemic, as organizations accelerate multiple digital business transformation initiatives, he said. As part of those efforts, those same organizations are starting to appreciate the need for DevOps tools that go beyond providing basic CI capabilities.

    Different organizations are, of course, going to achieve a level of DevOps maturity at varying rates. It’s not uncommon for different teams within the same organization to differ widely in terms of DevOps maturity. Rather than simply providing software, Boone said HCL Software is committed to providing the expertise in the form of services that enable organizations to maximize the potential of any DevOps investment.

    It’s not clear to what degree organizations will want IT vendors to include professional services engagements with the acquisition of software. However, the less proficient any organization is in terms of their DevOps processes, the more valuable those services generally become.

  • Participate in the Checkmarx 2020 Survey

    Participate in the Checkmarx 2020 Survey

    Checkmarx, the global leader in software security solutions for modern enterprise software development, and devopsy.kinsta.cloud are conducting a survey about the implementation of DevOps and related automation and security tools.

    The purpose of the survey is to help organizations evaluate their DevOps maturity, find out what are the most used DevOps tools and the most common challenges organizations are facing with their current DevSecOps model.

    The survey consists of 16 short multiple-choice questions. The results will depend on several factors including:

    • The organization’s progress on their DevOps adoption journey.
    • The role of the respondents in their organization and their responsibilities for DevOps transformation.
    • Automation and security tooling capabilities respondents are using for DevOps and cloud-native applications.
    • The respondents’ ability to overcome challenges and obstacles standing in the way to successfully implementing DevOps.

    We urge everyone in the DevOps space to participate in this survey. The more data we can gather, the more we’ll find out about the adoption of DevOps and AppSec tools. We’re counting on you to make this report even more valuable. Invite your friends and colleagues to contribute to the survey, too — the more the merrier.

    Click on this link to complete the survey.

    We will make an announcement when the report is ready. Stay tuned!

  • Atlassian Unfurls Bevy of DevOps Updates

    Atlassian Unfurls Bevy of DevOps Updates

    Atlassian today made a dozen updates to its DevOps portfolio as part of an effort to better unify workflows spanning disparate tools.

    Suzie Prince, head of product for Bitbucket at Atlassian, said the latest updates are intended to enable DevOps teams to streamline workflows without requiring everyone in the organization to standardize on the same set of tools.

    Updates to the Atlassian DevOps portfolio include DevOps Automation Triggers, which makes it possible to create automation to keep development activities synchronized, such as reassigning issues surfaced in the Jira project management application from Atlassian to code review or sending a message to a Slack channel.

    Atlassian DevOps

    The Bitbucket repository from Atlassian has also been updated to make it easier and faster to review code changes after a pull request. New features such as a consolidated list of tasks, integrated Jira issue creation and activity feed filters make it possible for developers to complete their code reviews faster and juggle multiple pull requests at once, said Prince. A Your Work dashboard in Bitbucket Cloud has also been expanded to include assigned Jira issues.

    The Atlassian VS Code integration is also being made available to make it easier for developers who use the Microsoft integrated development environment to more easily track and visualize Bitbucket Pipelines.

    A Code Insights in Bitbucket Cloud has also been added to bring scanning, testing and analysis tools into the code review process, including Mabl for test automation and Sentry for automated monitoring. Bitbucket is also now providing integration with Snyk scanning tools to make it easier to discover vulnerabilities.

    Available in a preview mode is an automated change management capability across Jira Service Desk Cloud and Bitbucket Pipelines that can be used to pause CI/CD processes, create a change request in Jira Service Desk and trigger deployment once it is approved.

    A Risk Assessment Engine in Jira Service Desk Cloud also allows IT teams to score the risk of a change and automatically approve and deploy low-risk changes. A Change Management View has also been added to Jira Service Desk Cloud to streamline approvals for high-risk changes by pulling all of the relevant information together in traceable change requests.

    Atlassian has also tightened integration between its Opsgenie incident management software and Bitbucket Cloud to centralize alerts and filters. Via an Incident Investigation Dashboard, members of a DevOps team can look at the deployment that happened right before the incident, add it as a potential cause, and contact the developer who made the change if it needs to be rolled back.

    The company has also extended integrations with Slack and Statuspage to facilitate both members of DevOps teams and external stakeholders.

    Finally, Atlassian is making available a resources hub to make it easier to share DevOps best practices, templates and guides.

    Prince said it’s not ever going to be feasible for most organizations to standardize on one set of DevOps tools. The goal should be to enable organizations to construct DevOps processes in ways that allow developers to employ whatever tool is their favorite at the moment. Only then will organizations get developers to buy into a DevOps process that doesn’t necessarily change the way they are most comfortable working, she noted.

    The challenge, of course, is often getting IT leaders to be as equally comfortable with what, from their perspective, might be an experiment in controlled chaos.

  • 5 Reasons Your Legacy IT Management Tools Are Holding You Back

    5 Reasons Your Legacy IT Management Tools Are Holding You Back

    Even before the onset of a global pandemic, IT professionals were coming to the conclusion that their legacy tools were no longer fit for the demands of today’s modern organizations. Their tools have likely met the needs they were originally purchased for, but chances are they’re insufficient to help organizations grow, innovate and move their IT teams from a cost-center to an engine for digital transformation and business success for one simple reason: those tools weren’t built for it.

    If you look at typical legacy IT monitoring and management tools, you’ll find point solutions that were built in-house are more likely purchased from smaller, point-tool companies. They’ve been augmented, updated and patched as far as they can stretch. Any integration is most likely of the swivel-chair variety, relying on your IT team to jump back and forth among different tools and screens in an attempt to piece together the bigger picture. Bolting afterthought add-ons onto an outdated system is not an effective way to deliver a unified, predictive, automated, machine learning-driven IT management system that can meet the challenges and demands of today’s increasingly digital enterprises.

    So, with that being said, let’s take a look at five reasons why your legacy tools are holding your IT team back. 

    Legacy Tools Weren’t Built for the Cloud

    Legacy tools were built for a physical or virtual IT infrastructure that resided within the walls of your data center and under the control of your IT team. They were designed to manage monolithic applications — a single system that scales or changes very slowly and is disconnected from other services and systems. Plus, they were built to deliver data the IT department cared about, not the key performance indicators (KPIs) that drive your organization’s success. The tools you use today that provide domain-specific capabilities already struggle to track and manage complex systems. This difficulty increases when those tools need to manage an infrastructure that comprises multiple hosted cloud solutions or loosely coupled microservices.

    Whether your IT operations are completely or partially on-prem, you know your future investments will be in the cloud, and senior leaders are keeping a keen eye on that investment. You’re committed to the cloud journey, but your current tools don’t map your new application destinations. You need to make appropriate investments in tools built to monitor and manage more than physical and virtual IT infrastructure. The tools you invest in today must be able to keep you and your business informed regardless of where your key applications reside and operate, and be future-proofed for whatever technological disruptions come next.

    Legacy Tools Have Stretched as Far as They Can

    Have the demands on your IT department and your network changed since your current tools were planned and implemented? Legacy tools weren’t designed to handle the demands you face every day. The tools themselves are likely operating at the limit of their capabilities, and they certainly weren’t built to take advantage of the new world of data. Today’s environments produce data from increasingly diverse sources — including containerized workloads, microservices and unique SaaS provider APIs. Applications themselves are now highly distributed, making it even more difficult to collect and use incoming data to gain actionable insights in the environment.

    Inflexibility in tools often becomes a key limitation in your organization’s ability to rapidly adopt and operationalize new technologies. And if they’re already struggling today, what does that mean for next year, or three years from now? What happens when your tools prevent you from capitalizing on your business’s most critical services? They become barriers to success. The tools you use will often dictate your outcomes. Modern tools need to be as agile and flexible as the demands you put on them. They can bend, but they should not break.

    Legacy Tools Were Not Built for Empowering Digital Transformation

    If we’re honest, many of the legacy tools still in use today aren’t very different in design or function than the first IT monitoring and incident management tools that defined the market. In fairness, the demands on those tools did not change much once they adapted to virtualized workloads. Back then the demands on IT were simpler and mirrored the organization’s mission: keep everything up and running.

    Management tools gave you numerous dashboards to identify specific issues in limited context. You would seldom be able to get an end-to-end perspective on your applications and infrastructure. If the environment was large or complex, you typically had to choose between moving between numerous instances or having significant gaps in coverage.

    These days you may find your IT organization judged by very different criteria, including cost metrics and revenue goals, in a much more complex and diverse landscape. That’s because the mission has changed. You’re expected to be a primary driver of digital transformation, including the adoption of new technology distributed across multiple environments. You won’t be able to do that effectively with tools designed before broad cloud adoption and mobile customer engagement. Modern tools must empower both the IT organization and the business, because technology has become a critical component of every organization and a direct line to the customer.

    Legacy Tools Are Domain-Centric

    Systems built over time often include a variety of tools, most of which were designed to only handle specific tasks. Combine this with the tooling sprawl that occurred with the adoption of agile development and DevOps and you have a kaleidoscope of complexity, making it very difficult to collect, aggregate, correlate and analyze all the data necessary to view and manage overall business service health and performance. IT departments need a single tool that can handle diverse use cases and provide the right information for the right context. True AIOps platforms were built specifically to address that need.

    Legacy Tools Lack Intelligence

    Legacy tools are still mostly reactive rather than proactive, let alone predictive. The “AI” in AIOps stands for “artificial intelligence” (even if the functionality is actually machine learning-based). The value of machine learning for IT is pretty well established. The machine learning at the core of AIOps solutions allows them to automate repetitive monitoring and incident management activities and, as they learn, predict an incident before it happens.

    While some vendors will tell you they can graft AI-like features onto their legacy systems, at best they’re trying to fill gaps and plug leaks. Only a system built from the ground up with machine learning at its core is able to offer true AIOps functionality and quickly adapt to meet future needs. Learning systems must not be an afterthought, but core to your tooling strategy with intelligence present at every stage of the operational life cycle.

    Now Is the Best Time to Investigate AIOps

    This is a difficult and challenging time for everyone that raises unique challenges for IT professionals. Recent events have highlighted both successful technology implementations and lingering legacy challenges. I would suggest it’s never been more important for IT teams to ensure alignment with the overall business and show their value beyond the basics.

    An AIOps approach can help you succeed in today’s complex technology landscape and reduce cost by consolidating outdated tools that have been holding you back from your true potential. AIOps is the best option to make your IT department more efficient and cost effective while improving your overall customer experience. I’d argue that these are the KPIs that matter most to your organization during these uncertain times. Most of us have a new perspective on the impact unexpected conditions can have on our technology systems. If you think you’ll be asked to reconsider your IT priorities and goals in the next few months, now is the time to build an informed plan.

  • Five Attributes of a Great DevOps Platform

    Five Attributes of a Great DevOps Platform

    As we move toward 2020, the expectations are high, the software industry is moving faster and the demand for rapid and continually improving digital experiences have raised the standard. To match the needs and demands of the market, firms around the world are embracing the DevOps culture to ensure and streamline the development, packaging, testing, deployment and maintenance of software at scale. 

    Every DevOps organization is defined by its own leadership, culture, practices, policies, leadership style, structure, talents, skills, technical capabilities, processes and tools. However, there are certain common characteristics that are important to consider before deciding a better DevOps platform to use in your organization. Today, we will discuss such important features that can help you while selecting your DevOps platform. 

    What is DevOps?

    DevOps is a mindset in an organization that enforces a set of collective practices to ensure easy collaboration between dev and ops so the business can run smoothly without any hassle. DevOps aims to fasten the time to market through frequent and incremental improvements to deliver quality software updates to customers. 

    The meaning and definitions of DevOps can vary from company to company. Automation being the focal point, firms want to focus on achieving zero-touch automation, with utmost security and governance as a priority in the delivery pipeline.

    Even though the meaning of DevOps varies, several inherent DevOps principles cannot be replaced, and they repeatedly insist on collaborative relationships, developing early, failing early, shared learning and continuous feedback. These DevOps principles enhance quality with improved deployment rates while simultaneously improving predictability, scalability and security of the production environment. Tech leaders in the company need to view DevOps as a holistic approach rather than a small set of guidelines for the teams, and DevOps guidelines should be aligned with the company’s long term technology vision and objectives. 

    Here are some facts to consider while deciding a better DevOps platform for your organization.

    A Mindset of a Unified Culture

    Culture plays a significant role in establishing the guidelines while embracing DevOps in any organization. Through DevOps culture, companies seek to bring dev and ops teams into harmony to promote collaboration, automation, process improvements, continuous iterative development and deployment methodologies. But above everything else, a sound DevOps culture fundamentally solves one of IT’s biggest people problems: bridging the gap between dev and ops teams to get them to stop working in silos and have common goals. 

    According to Gartner estimation, DevOps efforts fail 90% of the time when infrastructure and operations teams try to drive a DevOps initiative without nurturing a cultural shift in the first place. It is not just about the efficient tools or experts working; it is about the behavioral modifications and mentality necessary to effect cultural change.

    Hence, it is important for the firms to consider the culture of the company before selecting its tool as a potential DevOps tool for their development. 

    Automation Inside and Outside

    Automation is one of the key principles of a strong DevOps team because it has such a high return on investment. 

    Automation makes up as a large part of DevOps culture to standardize production platforms, and even firms believe it as true because standardization and automation help make deployments more predictable, easy and less prone to human errors. 

    Automate everything as part of the workflow process, including infrastructures, compliance and continuous delivery pipeline. For example, tools such as Artifactory can manage and control all your binary repositories to help your developers and ops collaborate and automate build and deploy tasks easily. Similarly, Docker allows development teams to containerize applications and automate application deployments with speed.

    By reducing manual, non-important and repetitive tasks, you will increase your development and testing speed while cutting down on human and unnecessary errors. Additionally, by automating tedious and repetitive tasks, firms free up team members to work on higher-level and more important tasks.

    Important to note here, JFrog Pipelines is an innovative DevOps automation solution that well integrates and connects all critical processes in the software delivery lifecycle in the company, from development to testing to production. Using minimum code, it allows you to create smart and event-driven workflows across tools and teams easily, to speed up the release of software applications. This helps you achieve continuous integration, continuous delivery, continuous deployment and continuous monitoring in DevOps.

    Support Both Hybrid and Multi-Cloud

    What is Multi-cloud?

    Multi-cloud is the use of cloud computing from two or more public cloud providers in single network architecture to meet their business objectives. A multi-cloud strategy has many advantages. It avoids vendor lock-in, decreases latency, enhances business continuity, overhead cost reduction and maximizes flexibility for development teams. However, multi-cloud management comes with some challenges that require careful orchestration, and needs to pay close attention to security and governance issues.

    What is Hybrid-cloud?

    A hybrid cloud is a mixture of on-premises and off-premises IT resources. Based on business and compliance requirements, the hybrid cloud allows firms to move data and applications between private and public environments. 

    Hybrid cloud computing allows instant transfer of information between public and private environments, allowing enterprises to experience the benefits of both environments efficiently. 

    Flexibility, scalability and cost savings are some of the top benefits of hybrid-cloud. 

    Considering a platform that supports both multi-cloud and hybrid-cloud is the best solution for the enterprises moving toward the digital transformation ladder.

    Continuous Updates 

    Frequently rolling out updates, in a continuous sequence, to bring service improvements to consumer devices more rapidly and efficiently is what every firm is trying to do these days. The customer wants new features as early as possible and continuously. That is one reason why companies embrace automation and follow practices like continuous integration, continuous deployment and continuous delivery through tools such as GitHub, Artifactory, Circle CI, Docker, Kubernetes, etc. 

    The DevOps platform should be able to manage your DevOps pipeline from a single pane of glass. A platform that can provide a universal end-to-end solution that integrates with your ecosystem to orchestrate and optimize all critical processes in your CI/CD pipeline. Boosting fearless updates continuously from code to the edge in self-managed, on-prem, hybrid and multi-cloud environments.

    A Robust Community 

    All successful companies have built their own communities through their products and services. DevOps is all about the culture shift. Changing existing culture and moving forward is one of the hardest things to do—despite the benefits that DevOps offers, such as speed and agility. No matter what changes a team implements, embracing DevOps often comes to a halt once the companies realize it requires a change in culture and mentality of all the teams involved. This is where the value of community comes in, by fostering the development of a more open communication, easy and supportive feedback, and collaborative culture within teams, companies can be able to drive this DevOps culture. This mindset should come from within and outside of the organization by tapping into this sense of community-based collaboration. Communities are required because they ensure the well being of many of the technologies we use daily.

    Your favorite DevOps platforms—Jenkins, Docker, Kubernetes, Artifactory—and their popularity is because of the communities they have created around the tools. 

    A well-focused DevOps platform gives power to people who listen carefully to what the market is saying, gets the feedback and utilizes it effectively. Hence, community is a very important feature of a DevOps organization. 

    Conclusion

    Companies around the world are embracing DevOps, and the demand for DevOps skills soars as organizations spend their time and money on digital transformation. DevOps has become a modern approach to IT that helps companies to think and execute broader business strategies. DevOps can drive significant brand value by accelerating speed to market, better collaboration, ensuring better testing and automation. A DevOps platform should have all the qualities mentioned above to succeed in this highly competitive market.

  • GitHub Makes Private Repositories Free for Unlimited Users

    GitHub Makes Private Repositories Free for Unlimited Users

    GitHub this week announced is making available private repositories for an unlimited number of collaborators available to all GitHub accounts for free.

    Kelly Stirman, vice president of product strategy and marketing, said that subsidiary of Microsoft could make this move because it is now generating enough revenue from the enterprise edition of its platform to sustain its business model.

    Previously, organizations that wanted to use GitHub for private development needed to subscribe to a paid plan. DevOps teams that need access to advanced features such as code owners or secure access markup language (SAML) support will still need to upgrade to a paid plan. However, the cost of a paid Team plan has been reduced to $4 per user/month from $9 per user/month, effective immediately, as part of an effort to increase the use of paid plans around the globe. Existing customers of paid plans will also see their bill reduced, added Stirman. Alternatively, existing customers can downgrade their current plan to take advantage of a free service.

    The overall goal is to increase the number of projects being developed on GitHub, said Stirman. Many open source projects generally get started by small groups of developers that are not initially ready to share their code publicly. GitHub provides an affordable way to launch those projects among a core set of developers that may not have ever met one another.

    Stirman also noted private repositories on GitHub provide a much more cost-effective alternative to standing up a private repository in an on-premises IT environment that requires IT teams to provision and manage their own infrastructure.

    GitHub also tracks all the vulnerabilities that are discovered in open source projects hosted on the platform, which is information that is shared with every developer on the platform, added Stirman.

    Additionally, GitHub provides access to a content delivery network (CDN) to more easily share code across geographically distributed teams of developers, Stirman said.

    It’s hard to forecast how much pent-up demand there is for access to a free private repository for an unlimited number of collaborators. GitHub has previously made private repositories available for a limited number of collaborators. Nevertheless, Stirman said there was a massive spike of adoption on the first day the new plan was available.

    In addition, Stirman noted there has been a marked increase in the number of teams that are working on projects related to COVID-19 research.

    Of course, the more development teams that are exposed to repositories such as GitHub the more likely it becomes more of those teams will find themselves to varying degree embracing best DevOps practices. Invariably, those bet practices will then find their way into a larger number of enterprise IT projects. Undoubtedly, GitHub views making private repositories available for free as a method to create increased demand for the enterprise edition of its platform down the line. Of course, rival providers of continuous integration/continuous delivery (CI/CD) platforms will be seeking to convert as many of those projects into enterprise customers as well.

    — Mike Vizard

  • GitLab Responds To GitHub Making Teams Free – We All Win

    GitLab Responds To GitHub Making Teams Free – We All Win

    Microsoft’s GitHub recently announced that it was going to make a change to its product lineup by making the team version of GitHub free and lowering the price on a full-featured version. The move seemed aimed squarely at matching GitLab’s offering. Well, now GitLab has responded to GitHub.

    While both of these excellent offerings compete to bring the best product to market, the real winners here are all of us. True market dynamics are at play resulting in both GitLab and GitHub lowering prices and adding more features (and not just GitHub and GitLab but also their competitors, including Atlassian among others).

    I had a chance to sit down with Sid Sijbrandij to discuss GitHub’s move, what GitLab will do and what this means for the market. (BTW, I have to apologize to Sid—it seems I have been mispronouncing his name for years and he is too much of a gentleman to correct me. The proper pronunciation of his name is “See Brandy.”) The video of our conversation appears below, and a blog on the GitLab site explains it all.

    In our interview, Sid was very clear that GitLab owes a huge amount of gratitude to GitHub, as it was GitHub that spurred on the early development of GitLab. He truly respects what GitHub has done, as well as the great job Microsoft has done since acquiring GitHub.

    The GitLab blog post lays out very clearly what the GitHub offering is and how it compares to the GitLab offering. It’s no coincidence that the new GitHub paid teams offering is the same price as the GitLab bronze offering.

    Price aside, according to Sid, the real advantage of GitLab is that its vision of an end-to-end total DevOps solution and the features it adds to achieve this vision give GitLab customers more than they can get from GitHub. While I agree that is true today, I don’t think GitHub is going to be content with its current lineup for long. I think the Microsoft entity already envisions a total DevOps solution as being part of GitHub’s future.

    On top of that, I think GitHub and Microsoft are already thinking of how they can leverage Azure to give GitHub an advantage. To Microsoft’s credit, though, at least until now there has not been any special advantage of using GitHub with Azure. Azure remains an open platform that all vendors seem to get fair access to and support from.

    All of this aside though, we are all the real winners here. What a great time to be a developer/DevOps professional. While GitLab and GitHub compete with each other to bring more features to market for less money, as I mentioned other companies are competing to bring end-to-end DevOps solutions to market as well. We benefit from all of this competition by getting better tools and solutions at better prices. That’s true market dynamics at work.

    It should get only better in the months and years ahead as well. In spite of COVID19 and the rest, it is a great time to be alive.

    — Alan Shimel

  • DevOps Chats: CloudBees Remains at Top of DevOps Market

    DevOps Chats: CloudBees Remains at Top of DevOps Market

    In this special DevOps Chats video edition, we speak with Sacha Labourey, CEO of CloudBees. From the very beginning of the DevOps movement, CloudBees has been one of the companies at the top of the DevOps market and, based on its latest business metrics, the company remains there.

    Being the enterprise Jenkins company helped CloudBees early on to be a leader at the top of the DevOps market. But with Jenkins and Jenkins X handed over to the Continuous Delivery Foundation (CDF), CloudBees can no longer count on its Jenkins connection to stay on top.

    Sacha, like any good CEO, did not allow CloudBees to rest on its laurels. An aggressive acquisition strategy including acquiring Electric Cloud, Rollout.io and others, has kept CloudBees on top. At the same time, Sacha has led the product and engineering teams as they roll out a new generation of DevOps products and services including the upcoming Software Delivery Management (SDM) and Software Delivery Automation (SDA).

    In this video, Labourey lays out what the past year has seen for CloudBees and what the coming year could bring. Of course, with Covid19 everyone is sailing into unchartered waters. But Sacha has the course in mind for CloudBees to follow.

    Have a listen to our conversation with Sacha to understand CloudBees’ plan to stay at the top of the DevOps market.

    [video src="https://videos.files.wordpress.com/TNgFIQ9x/2020-03-19-interview-with-sacha-labourey-1_hd.mp4" /]

    — Alan Shimel

  • DevSecOps: A Renewed Commitment to Secure Delivery, Part 2

    DevSecOps: A Renewed Commitment to Secure Delivery, Part 2

    If done right, DevSecOps eliminates the cultural roadblocks that often prevent organizations from getting IT security proactively involved with development and operations. Barriers are the last thing any organization should contend with when comprehensive security is an absolute priority at a time when data breaches, intellectual property theft and other cybercrimes can almost immediately cripple a business.

    Still, companies are far from perfect. Misunderstandings, ill-defined policies and turf wars can prevent development and operations from collaborating in a way that naturally bakes-in security into their work. To effectively transform a DevOps pipeline into a DevSecOps one, organizations need to change the way people work and collaborate; make processes inclusive of quality, security and compliance activities; and integrate the right tools.

    Those three steps are the focus of this two-part series on becoming a true DevSecOps enterprise. We reviewed processes in part one and now we’ll cover people and tools in this article.

    For enterprises with deep-rooted DevOps, a renewed focus on security might entail modernizing the release pipeline and involving IT security people even more. For enterprises that are modernizing heritage-monolithic application portfolios and moving to cloud native architectures, pipeline modernization should include a DevSecOps approach that considers containers, microservices and APIs. 

    DevSecOps done right gives organizations a level of visibility and accountability that helps accelerate coding, testing, production deployments, problem determination and defect resolution–all accomplished because of an organization-wide acceptance and commitment to security that should shatter any and all roadblocks.

    Don’t Forget About the Humans in DevSecOps

    When was the last time you heard a developer say, “Hey, let’s get the security guys in here, to hear what they have to say?” Reality is far harsher. Collaboration with IT security often triggers visceral reactions that are not exactly positive. IT security is often stereotyped as the organization of “no” and “you can’t do that.”

    DevSecOps aims to tear down those cultural barriers. DevSecOps is all about embracing your IT sec organization and even inviting auditors to collaborate early on in the release process. 

    Ultimately, security is everyone’s responsibility. Being a developer, there was nothing like the mention of security to make me feel super uncomfortable. I don’t believe that developers set out to purposely create insecure code. However, when IT sec is not involved in a collaborative, cooperative relationship with dev and ops, there is an uncertainty that creeps in, and trust and confidence are shattered.

    We know developers develop and release code, while operators control and manage the runtime environment. What is the expectation of IT security in this process? What are they looking for? What risks do they need to mitigate when a digital product is delivered? Understanding the objectives of IT security in the delivery process will clarify the steps that must take place in the process and reveal which tools should be used to create a product that’s secure and delivered with velocity and quality.

    Understanding what stakeholders do along the pipeline reconciles personal and organizational accountability with tangible value-add in the release process. DevSecOps can be a catalyst to re-examine and provide clarity on who is doing what, when it is being done and why the effort is being exerted.

    Clarity might reveal that personas need to be updated to more modern roles. For example, an operations system administrator might become more of a site reliability engineer (SRE). The SRE role involves more proactive activities, earlier in the release pipeline, to infuse greater fault tolerance in code and greater resilience in the environment configurations–and to solve problems by engineering solutions with developers and IT security.

    Determine who does what and where. Develop personas that outline responsibilities along the pipeline, from the sourcing of code to production, to create necessary transparency. Value-stream mapping is a good way to capture the current state of a release pipeline and an excellent way to construct a desired state pipeline with the necessary people performing value-add activities to releasing a product. 

    Use Tools that Provide Necessary Visibility

    Tools are the enablers. These are the cogs in the machine that will be running test cases, static analysis, vulnerability scans and integration tests. Tools will automate DevSecOps processes and provide the most critical function: visibility. The ability to observe all DevOps processes and determine their origins in the pipeline is critical. Visibility lessens risk and supports compliance and audits. The process that defines how code is governed through the promotion path should drive the tools that will be integrated into the release pipeline. Most tools serve to automate build, testing, scanning, movement through the promotion path and integration with other tools. It only makes sense that end-to-end visibility in the release pipeline should be engineered in.

    Tools, though, must integrate and communicate to achieve end-to-end visibility. In the heritage era of DevOps (basically, the time before cloud native), it was tough to gain visibility because tools came from different vendors and often couldn’t talk with one another. Fortunately, cloud native platforms offer more integrated capabilities. Build and CI tools naturally share information because these capabilities are being refactored into the cloud platforms themselves.

    An example of this is the cloud native CI/CD capabilities of Tekton, which leverage and extend the operator framework in Kubernetes. Translation: CI/CD tools are starting to look like extensions of the cloud native platform, in stark contrast to heritage CI/CD tools which were standalone third-party software products. The result of this tool trend is tighter integration and better visibility built into the platform–you don’t have to engineer it.

    Companies need to review how effectively their tools communicate and close any visibility gaps. When possible, consider some of the next-gen automation tools and technologies such as Tekton, Kabanero.io and Jenkins-x that bring greater visibility, integration and consideration for cloud native apps which heritage tools have struggled with.

    DevSecOps Is a Catalyst for Pipeline Modernization

    A modern security framework will let companies take full advantage of the cloud native technologies that are changing DevOps. Granted, most companies won’t completely shift their entire infrastructure to the cloud, nor should they. Most organizations need to identify a partner to help them assess which processes and tools are worth moving to the cloud, and which ones–like a mainframe that runs core business functions–should be left alone. 

    For those enterprises that have a large heritage application portfolio, DevSecOps could mean retrofitting automation into systems and applications that were often designed and developed without the scaffolding of a secure DevOps pipeline. DevSecOps applies to heritage application, too. After all, what pipeline wouldn’t benefit from the visibility and traceability of tracking a user story to its production release? By automating the delivery of these heritage apps, you’re optimizing the effort of manual activities such as build, test and deploy, and retrofitting the capability of pipeline visibility.

    Cloud has changed the DevOps game, newly defining the fundamental technical underpinnings of what an application really is. And it is cloud that’s driving companies to look at the security of DevOps in an entirely new way. With much on the line–the purity of products, compliance, brand reputation–companies need to rebuild their security frameworks so they can take full advantage of cloud and their on-premises programs. They don’t have to do DevSecOps alone.

    — Andrea C. Crawford

  • SolarWinds Strengthens AppOptics APM Platform

    SolarWinds today updated its AppOptics application performance management (APM) platform by adding both service- and trace-level root cause analysis capabilities.

    Jim Hansen, vice president of products, application management for SolarWinds, said the goal is to provide most of the same capabilities any IT organization would find in an APM platform that would cost 10 times more than AppOptics.

    That’s critical at a time when thanks to the rise of microservices-based applications based on containers more IT organizations are discovering they need to apply APM platforms more broadly, added Hansen. Previously, IT teams tended to reserve usage of APM platforms to their most mission-critical applications because of the costs involved. However, as SolarWinds moves to drive the cost of accessing an APM platform delivered via a software-as-a-service (SaaS) application, Hansen noted APM platforms are becoming more affordable.

    The service-level root cause analysis module is also designed to more accessible to the average IT administrator by reducing the number of steps and clicks required to identify the specific performance problem or issue. A complementary AppOptics trace-level root cause analysis then makes it possible to drill down into application metrics all the way down to specific lines of code and transactions. The goal is to make APM platforms more accessible to IT generalists, said Hansen.

    Those service- and trace-level root analysis features are available both in the core platform as well as a free AppOptics Dev Edition tool that SolarWinds makes available for developers.

    While AppOptics is the core APM platform provided by SolarWinds, the company also makes available a Loggly log management platform and Pingdom performance monitoring tools for websites. Collectively, those platforms make it easier to manage IT environments that are becoming increasingly complex to manage, said Hansen.

    In general, Hansen said IT organizations are starting to converge application and infrastructure management, especially if they have embraced best DevOps processes. In some cases, one member of a DevOps team is managing both, while other organizations are having teams of IT professionals collaborate around the same APM platform.

    At the same time, Hansen noted IT organizations want to be able to employ the same APM platform to manage both monolithic and microservices-based applications versus having to acquire separate APM platforms for both types of applications.

    It’s too early to say to what degree SolarWinds might be able to usurp rival providers of APM platforms that have been available for more than two decades. However, Hansen noted that in terms of market penetration, fewer than 10% of IT organizations have standardized on an APM platform.

    As organizations transition to microservices-based applications, APM platforms become a necessity. The overall IT environment is simply becoming too complex to manually monitor and manage. At the same time, businesses are starting to have a greater appreciation for how dependent digital processes are on software. The issue now isn’t so much whether those organizations need an APM platform as much as it is figuring out which APM platform can they afford.

    — Mike Vizard