devopsy.kinsta.cloud

Category: Blogs

  • Gotta Fix ‘Em All: AWS BugBust 2021

    Gotta Fix ‘Em All: AWS BugBust 2021

    Software bugs are vexing. Code reviews and error finding aren’t a particularly fun part of a developer’s job description. Finding bugs is tedious, time-consuming and hard on your eyes. Bugs not only wreak havoc on your code, they wreak havoc on your day. But what if bashing bugs could earn you a payoff greater than pride? That’s where AWS BugBust comes in.

    AWS BugBust is the world’s first global competition for Java and Python developers. The contest has two overall goals:

    1. Fix 1 million bugs and
    2. Reduce technical debt by over $100M, globally

    Code reviews and monitoring are common practice; some organizations even hold bug bashes where members come together to reveal bugs and fix them. However, fixing code is still an arduous process and there is more that could be done to make bug-bashing efforts fun and fast. AWS BugBust does both by adding in gamified points/competition/prize components!

    How does AWS BugBust work?

    The more bugs you fix, the more points you earn and the higher up in the leaderboard you get. Using Amazon’s CodeGuru, developers will compete to fix the most bugs (identified by CodeGuru Reviewer) and the most expensive lines of code (highlighted by CodeGuru Profiler). Amazon CodeGuru eases the pain of code review and error finding by automating the process. Using Machine Learning, Amazon CodeGuru will scan code quickly, identify errors and provide fix-it recommendations.

    Here is more info about the contest:

    How do you earn points?

    AWS BugBust uses Amazon CodeGuru Reviewer to analyze applications’ code to identify bugs and CodeGuru Profiler for performance issues. The bugs and profiling groups are available on the challenge dashboard and are available for participants to claim them, fix, and score points. Points are earned based on the severity of the bug (low, medium, and high)

    To score points, participants make code changes in their repositories, create a code review request, and trigger a code build. CodeGuru Reviewer will analyze the code changes as part of the build process and notify whether the code that was changed addressed the bug.

    The collective number of bugs fixed and dollars saved will be stored in the AWS Global BugJar. The totals for both metrics will show on the global leaderboard.

    Participants will receive digital badges and bespoke swag at three key milestones: 100, 2,000, 10,000 bugs fixed. Swag includes pins, t-shirts, BugJars, backpacks, and hoodies/jackets.

    When will AWS BugBust take place?

    The contest will launch Thursday, June 24. You can get started by setting up an AWS BugBust for your team.

    What’s the ultimate prize?

    The top ranking developers of the global leaderboard by the end of September 30, 2021 will receive an all-expense-paid trip to re:Invent 2021. AWS will also award the top 10 enterprises who collectively contribute the most bugs to the global BugJar through their private events with two tickets to re:Invent 2021 for their top BugBusting developers. If you’re a Java/Python developer, this competition will be like doing your job while enjoying a game-like atmosphere!

    Here are important rules:

    1. An AWS account is required to participate in the challenge (participants can create one at the beginning of the challenge or any time during the contest period).
    2. Customers who have their code bases in Java and/or Python and stored in supported GitHub, GitHub Enterprise, Bitbucket and AWS CodeCommit repositories are able to participate in the AWS BugBust.
    3. Challenge registration and console experience, overall, are much better on the desktop. Links in the console will direct to code repositories which are more easily accessible on the desktop, as well. Mobile placements will be considered for awareness, but desktop should be prioritized.

    AWS BugBust isn’t your grandma’s bug hunt. You now have machine learning capabilities on your side, including the ability to automatically find bugs for you and present the list of bugs to you – even before the challenge begins. You can make the arduous inspection process fun, win some prizes, be the hero at busting bugs and find them, starting June 24!

    We have also provided additional information about the AWS BugBust competition on DevOps.com.

  • SREs Say AIOps Doesn’t Live Up to the Hype

    SREs Say AIOps Doesn’t Live Up to the Hype

    What can you expect when investing in artificial intelligence for IT operations (AIOps)? Real-time visibility across huge volumes of information. Lightning-fast event correlation and anomaly detection. Automated remediation and self-healing, without Ops personnel having to lift a finger.

    It all sounds amazing—at least, if you believe the marketing hype. But do those kinds of AIOps benefits actually translate to the real world? According to a recent survey of nearly 300 site reliability engineers (SREs), not so much.

    Among SREs surveyed—including engineers for some of the world’s largest, most innovative digital companies—just 12% use AIOps as a day-to-day part of their monitoring toolkit. Nearly 40% never use it at all.

    Why aren’t current AIOps solutions living up to the hype? And what can this gap tell us about the state of IT monitoring in general? Let’s take a closer look.

    Sprawling Complexity

    In theory, AIOps should be a perfect fit for SREs. These are, after all, the people with one foot in the world of operations, one in development, whose job is to make distributed software systems ultra-scalable and reliable. A solution that can turn mountains of data about those systems into actionable insights should be exactly what SREs need. And, in fact, 53% of SREs cite lack of unified visibility across the stack as their biggest cloud application monitoring challenge.

    And yet, if we gauge by utilization, today’s AIOps tools don’t seem to be delivering on that promise. Asked about the value of AIOps, just 7.5% of SREs, on average, view AIOps as “high-value”—even less than those SREs (9%) who perceive its value as low.

    Why is AIOps so slow to catch on? Ultimately, the barriers facing these tools are the same as those facing human engineers: massive and growing complexity in IT environments. As digital products become more dependent on third-party cloud services, as the number of things businesses want to track grows (from infrastructure to application to experience), the sheer volume, velocity and variety of monitoring data has exploded.

    Diverse Data Sources

    Compounding the problem, enterprises increasingly rely on multiple “same-service” providers for IT services. That is, they use multiple cloud providers, multiple DNS providers, multiple API providers, etc. There are sound business reasons for doing so, such as adding resiliency and drawing on different vendors’ strengths in different areas. But even when two providers are doing basically the same thing, they use different interfaces and instrumentation, and their data sources often employ different metrics, data structures, and taxonomies.

    Whether you’re asking a human being or an AI-driven tool to solve this problem, this heterogeneity makes it extremely difficult to visualize the complete picture across the infrastructure. It also creates gray areas around how best to take advantage of each vendor’s different rules and toolsets. All of which makes automating anything beyond the most superficial operations tasks hugely challenging, if it’s possible at all.

    Optimizing AIOps

    AIOps really is the solution to this problem—or at least, an important part of the solution. Machine learning is, after all, tailor-made to analyze large volumes of observational and engagement data and react in real-time, as well as to continually identify opportunities for improvement. But before we can get there, we need to change the way we think about AIOps.

    Don’t try to do everything at once.

    It would be great if we could deploy AIOps, let it learn about our environment and watch it magically start remediating issues on its own. But we’re not there yet. (And if a vendor tries to convince you we are, you should definitely be skeptical.) If we break down our expectations into smaller, more manageable chunks, however, AIOps can accomplish quite a lot.

    Event correlation, topology analytics and smart alerting, for example, are all areas where AIOps can provide significant value right now. For these more limited objectives, AIOps can absolutely reduce tedious manual effort for human operators, reduce mean time to repair, improve visibility and more, and digital businesses should be leaning on AIOps to do that.

    Invest in AI and ML training.

    Part of the reason adoption of AIOps tools remains sluggish stems from the fact that many teams still just don’t fully understand how they can use them. The more SREs are exposed to AI/ML training, the more opportunities they will identify for concrete, meaningful applications of AIOps. For example, only 27% of SREs said, “Experimenting or receiving training to expand knowledge or skills” was a major activity as part of their job.

    Embrace “Platform Ops.”

    The biggest step we can take is to rethink how we use AIOps within an organization. Today, AIOps tools—like SRE resources themselves—are often dedicated to a specific digital product or service. As a result, enterprises end up trying to apply their AIOps tools, and the SREs using them, to support everything associated with that product (DNS, API, CDN, cloud monitoring, etc). As IT environments continue to get even more complex, though, businesses will likely find that shifting to shared platform tools and teams yields better results.

    Instead of trying to apply AIOps across every part of a digital service, imagine applying it to one part of that service (for instance, focusing on just DNS, or just APIs). In this way, the AIOps tools, as well as the teams using them, gain in-depth expertise across all the different interfaces and instruments used for that function and get continually better at normalizing multi-provider data sources across them. At that point, this platform-specific AIOps capability can then be scaled and reused across the company—providing more advanced DNS AIOps (or API, or CDN, etc.) for multiple digital products and teams.

    Now, you’ve got an advanced, highly specialized toolset for optimizing an important platform function, regardless of which digital product happens to be using it. You’ve narrowed the scope of how you’re using a given AIOps implementation while going much deeper into that function than a more generic, broad-based implementation could achieve. All of a sudden, even more advanced automation and self-healing becomes possible. And the loftiest marketing claims of AIOps start to look less like hype and more like viable real-world outcomes for your business.

  • Hasura Extends Scope of GraphQL API Platform

    Hasura Extends Scope of GraphQL API Platform

    During its online an HasuraCon ’21 conference, Hasura today announced that it has made it possible for developers to employ GraphQL application programming interface (APIs) to launch queries against data residing in multiple databases.

    At the same time, Hasura announced a preview of schema sharing capabilities along with support for workflows based on GitOps processes that it will make generally available later this year. The Hasura Cloud platform can now deploy local migrations from staging to production with a simple git push in addition to accessing previews of applications on every pull request to the git repository.

    The schema sharing capability added to the Hasura GraphQL Engine is intended to bridge the gap between beginner and power users by allowing them to share and install samples of permissions, relationships and metadata. In addition to improving collaboration, the goal is to make it easier to onboard software engineers as projects evolve and become more complex.

    Originally developed by Facebook, GraphQL has emerged as a popular alternative to REST APIs because it enables developers to retrieve data at a more granular level, which results in improved performance.

    Hasura is a provider of an instance of a GraphQL engine the company has developed around a project that is now hosted by the GraphQL Foundation, an arm of the Linux Foundation. The GraphQL Foundation counts among its members Airbnb, Amazon Web Services (AWS), Apollo, Coursera, Elementl, Facebook, GitHub, IBM, Intuit Hasura, Paypal, Prisma, Shopify and Twitter.

    GraphQL provides a complete description of the data made available via an API and is organized in terms of types and fields rather than traditional endpoints. In addition to clarifying what data is available via that API, developers can employ types to avoid writing manual parsing code.

    Since last summer, Hasura has been making available a pilot of a GraphQL implementation that is capable of supporting remote joins across disparate databases. That capability is critical because data sets that are related to a specific business process may wind up being stored in multiple databases.

    Hasura

    Tanmai Gopal, Hasura CEO, said the open source Hasura GraphQL Engine has already been downloaded more than 250 million times this year. Downloads in 2020 reached 100 million. The challenge is that while GraphQL offers a superior alternative to REST APIs, most of the API tooling that exists within organizations is still designed around REST APIs, noted Gopal.

    To accommodate that reality, Hasura has made a tool available that will convert a query designed using GraphQL into a set of calls that are compatible with REST APIs. Developers still gain the benefits of being able to launch more granular queries, noted Gopal.

    REST APIs, in general, are becoming more problematic as organizations embrace microservices-based applications. It often takes minutes to refresh a simple dashboard because of the amount of data that REST APIs are trying to pull from various data sources. As organizations embrace digital business transformation, they are also encountering application latency issues that can be traced back to the amount of data being called from multiple microservices.

    Hasura says in addition to providing a more efficient method to access data, Hasura is also working on adding caching capabilities to its core engine to further improve performance.

    It’s not clear at what rate GraphQL might replace REST APIs, but DevOps teams should assume organizations will wind up employing a mix of both for years to come. The challenge is going to be determining when to make the transition as organizations become more dependent on APIs.

  • Salesforce Pilots Series of DevOps Initiatives

    Salesforce Pilots Series of DevOps Initiatives

    At its online TrailheaDX 2021 conference, Salesforce today unveiled a DevOps Center pilot that provides a portal through which organizations can track and manage changes to Salesforce applications along with a unified command line interface (CLI) for all its applications.

    In addition, Salesforce plans to add Salesforce Functions to enable developers to deploy code in a serverless environment.

    The company has also promised to extend its low-code App Builder tool to include support for Dynamic Interactions, a capability that enables both professional and citizen developers to add reusable components to any application. The company has also added a Customer Identity Plus tool that enables developers to consolidate and manage customer identities.

    Finally, Salesforce is adding an Einstein Automate tool that employs machine learning algorithms to both integrate data and automate workflows that can invoke, for example, an existing MuleSoft Composer tool for integrating applications using a Flow Orchestrator that will be made available as a pilot project this summer. MuleSoft is a subsidiary of Salesforce. There is also now an Einstein Data Detect tool that ensures organizations adhere to data privacy laws by employing machine learning algorithms to discover when developers might have inadvertently exposed sensitive data.

    Dynamic Interactions, Salesforce Functions and CLI unification are expected to be generally available in the winter of next year, while the Einstein capabilities are expected to arrive this summer.

    Ryan Ellis, senior vice president of product management for platform at Salesforce, said the company is making a concerted effort to make it easier for both professional and citizen developers to build applications within the same environment by fostering collaboration via a DevOps Center portal that is expected to be generally available in the spring of 2022. Today the skills that any citizen developer can bring to bear are generally limited, largely because they don’t typically know how to build a well-designed, secure application that will truly scale in an enterprise IT environment.

    Salesforce

    However, as more artificial intelligence (AI) capabilities are added to low-code tools the amount of developer guidance being provided will increase over time. That additional guidance will enable citizen developers to build robust applications more reliably, noted Ellis.

    In the meantime, the primary beneficiaries of low-code tools continue to be professional developers that employ them to build applications faster than they could otherwise using procedural code.

    In general, Ellis said the relative DevOps maturity of organizations building and deploying custom applications on top of the software-as-a-service (SaaS) platform managed by Salesforce continues to increase steadily. In the wake of the COVID-19 pandemic, many organizations opted to extend existing SaaS applications provided by Salesforce to accelerate digital business transformation initiative using low-code tools rather than developing every application from scratch using procedural code.

    Of course, as the rate at which those applications are being built continues to accelerate, the next big challenge is managing the application life cycles after they are deployed.

    It’s not clear what the ultimate mix of applications built using low-code tools versus procedural code will be. Millions of lines of code are now being regularly deployed on Salesforce platforms, noted Ellis. It may be a little while before Salesforce is able to bring DevOps best practices to all that code, but, starting today, the journey has begun.

  • AppSec Marketing in the Age of DevSecOps

    AppSec Marketing in the Age of DevSecOps

    A while back, I had a conversation with a friend I went to school with (currently a senior member of the engineering team at a large retail chain) who was tasked with the job of identifying potential application security partners (he addressed vendors as partners, which I personally liked) to collaborate with on various areas as part of their product security initiative. The following piece emerged as an extension of my immediate thoughts when he shared his views of what could have made his experience of interacting with front-line sales and marketing folks better.

    In the context of DevSecOps, much has been said about the need for engineering to speak security, security to speak code, DevOps to speak security, etc. But as a technology service provider (TSP) riding the current wave of application security, it’s almost mandatory for the sales and marketing teams to also speak relevant tech!

    Application Security Is Not One-Size-Fits-All

    Application security, as a practice area, is dynamic. No two applications are the same, even if they belong in the same market domain, presumably operating on identical business use cases. Some (of the many) factors that cause this variance include technology stack of choice, the programming style of developers, the culture of the product engineering team, priority of the business, platforms used etc. This, consequently, results in a wide spectrum of unique customer needs.

    Take penetration testing as an example. This is a practice area that is, presumably, well-entrenched both as a need and as an offering in the application security market. However, in today’s age, even a singular requirement such as this could make or break an initial conversation. While for one prospect, the need could be to conduct the test from a compliance-only perspective, another’s need could stem from a proactive software security initiative. There are many others who have internal assessment teams and often look outside for a third-party view. Others who are further along the maturity curve could be looking to up their game through a hybrid approach of tool automation with a complementary method of manual assessments. I’m not even considering the added complexity involved in the nomenclature of such a service—is it called penetration testing, security testing, vulnerability testing, VAPT (which actually is a combination of two independent practices) etc.?

    Each of these unique needs emerges from buyer personas which emerge from varying degrees of informed decision making. TSP’s would need to retrofit their positioning accordingly. They often run the risk of underwhelming a mature buyer or overwhelming an early practitioner, especially in high variance offerings such as security tooling, security regression and threat modeling, for example. While some might argue that losing an overwhelmed prospect could be the result of their accurate customer segmentation, there are other reasons for this.

    Scoping questions, such as the ones below, can significantly help technology marketers strike the right chord with their prospects and elevate the experience of the initial interaction.

    • What is the motivation for the penetration test? Is it compliance regulation, internal validation, business drivers, their customers’ needs, etc.?
    • What are they specifically looking from a third-party partner? Is it external certification, a specialized approach, uncovering logic flaws, etc.?
    • What is the current appetite (measured in resource bandwidth, commerce) to take on your advanced offering? (Such as automation, regression etc.?)
    • How security aware are the developers? Can they take the findings to their logical conclusion through successful remediation?

    DevSecOps Is About the Journey, Not the Destination

    Ever since the surge of DevSecOps, marketers and practitioners have been vocal about the possibilities and advantages that smart automation brings with it. Think tanks, too, have statistically alluded to its benefits in terms of cost savings and bandwidth efficiency, among others. Though recent marketing campaigns have rather effectively communicated the ‘what of DevSecOps and AppSec automation, more awareness of the ‘how’ of DevSecOps is needed. TSP marketers need to design and propagate content on use cases focusing on the implementation challenges and suggested how-tos. Such content not only helps build trust and credibility but also allows segues for tech marketing to collaborate with security engineering. Some of these include practical guides on open source tool automation and sample automation scripts and libraries, data sheets on resource optimization through automation and handbooks on vulnerability remediation, just to name a few.

    This collaboration between marketing and sales and security would provide an opportunity for the former to get themselves well entrenched in the practical workings of the service or solution that they are responsible for positioning. Ironically, this also allows them to appreciate constraints that would prevent them from over- or under-committing business value to their prospects through their messaging. This is especially more relevant with the numerous myths that surround application automation and DevSecOps in general.

    The DevSecOps Rolodex

    In 2012, I had the opportunity to meet with one of the senior CISOs in the industry. After some initial small talk, I was introducing what we did and how we thought we could help his team. I was 70 seconds into what was my planned 180-second pitch when he respectfully stopped me, pulled out a rather impressive Rolodex from his desk and said, “I could point you to 15 companies in a 20-mile radius who could help me with exactly what you’ve offered me. I wonder if there’s any secret sauce?”

    Startled, embarrassed, I managed to gather my thoughts and moved to the final 30 seconds of the pitch, though with much hesitation. As luck would have it, he found little bits of the secret sauce. The meeting obviously did not go exactly as I had planned, but it didn’t go badly, either. However, it made me realize that our customers and prospects often know just as much—or even more—about our competition than we do. Everybody is selling, all the time. So, someone else has already made their 70-second pitch. Not everyone gets lucky enough to be given an opportunity for a pause! It’s up to us to find the secret sauce and make that close in the final 30 seconds.

    We are riding a very healthy wave of application security focus right now, and it’s paramount that technologists and marketers collaborate to identify and nurture their own secret sauce in their messaging and positioning. After all, this is what is going to keep the person at the other end of the table from reaching out to others in their DevSecOps Rolodex!

  • Some Technical Debt is Self-Resolving

    Some Technical Debt is Self-Resolving

    But don’t count on it.

    Fellow DevOps.com contributor Bill Doerrfeld recently wrote, “Enterprises Face Growing Technical Debt,” a great article about trends in technical debt, and it got me thinking about some of the things that have been going on in the industry over the last few years.

    As I’ve mentioned before, the changes underlying our systems combined with the need to keep systems that existed before those changes alive are making for quite the debt ratio, and that debt is coming due, probably sooner than you think.

    We’ve got enhanced ways of tracking how much time technical debt is consuming built right into our CI/CD tools, but there are inherent weaknesses in those tools. The ability to track time spent on issue X, and to categorize issue X as debt, requires a solid categorization process and relies on staff to keep close track of their time. Right or wrong, the industry has currently (maybe permanently) moved away from tracking time in small increments and, instead, most organizations track results. But unless you know the percentage of time spent keeping a system that is outside your main-line development toolsets alive, you can’t determine how bad technical debt really is.

    There are some bright spots though, and while I (and others, to be sure) have been sounding the alarm about technical debt since DevOps teams were all allowed to pick their own toolchains (glad that’s mostly over with), we need to be aware that counter-forces will help alleviate technical debt issues, also.

    First is the trend of making things simpler. Let’s face it, on the DevOps side, Python became popular at an insane pace. There is a very good reason for that. Shell scripts written by master scripters to achieve a goal are impossible for even good IT folks to follow. What you can’t follow will take much longer to fix–because you have to break it apart, figure out the parts, parse through massively complex pattern matching, etc. Python simplified all of that. If you write a Python script to do the same thing as a bash script, a far higher percentage of IT will be able to glance at it and go, “I know what this does.” This trend exists across IT (bug dashboards are another good example at a much higher level), and as easier-to-understand tools are increasingly part of the mix, the old and arcane will be less of a debt.

    Second is that, while I have raised warnings about things like the growth in API usage and CI/CD toolset complexity, the fact of the matter is that both of these things reduce the amount of code that we, internally, are maintaining. Steps automated, be they by calling someone else’s API, or calling your CI/CD vendor to handle build or deploy steps, are less steps for us to worry about (as long as they work, of course–have trusted partners).

    But we still need to be aware of technical debt, because all of the things we’ve mentioned in the past—the increasing complexity of our environments, staff turnover, team-specific tools and languages—are driving up debt.

    Check with your CI/CD vendor to see what their offering for tracking debt looks like. Other measures that don’t require tracking actual time spent on individual activities include keeping a tally of the number of bugs. And a surefire way to get a great feel for where your weaknesses are is looking for the software no one wants to work on, or the software that someone warns the new people not to touch. That’s where your debt load is the heaviest. IT is full of tinkerers;”If it ain’t broke, don’t fix it …” only applies in IT if “…because no one here knows exactly how it works,” also applies.

    Ask your teams to list which tools in their area (be it silos or DevOps teams) need to be updated and/or replaced, and then to rank them. Then take that data to team leads, and ask them to decide where your limited hours and money should go. Provide data on relative debt that you gathered above, so a comparison of team rankings to debt cost can be made.

    And then, set aside time to alleviate debt. It doesn’t have to be massive, just keep moving forward on it. You set aside time for all sorts of things, even a few man-hours a week on debt will multiply. It will start slow, but once you are spending less time each week fixing “product X,” some of that time can be added to technical debt resolution, increasing what can be done. Look for low-hanging fruit; a small app or script that eats up an outsized amount of time, or a system that is insanely expensive to keep, while the market has moved past what it actually is used for in your department, etc.

    Then enjoy the fruits of your labor, and put those astounding skills and that extra time to use rocking even more new apps for your users.

  • Responsible Reproduction

    Responsible Reproduction

  • Plutora Dives Deeper into Value Stream Analytics Data

    Plutora Dives Deeper into Value Stream Analytics Data

    Plutora announced today it has extended the capabilities of its value stream management (VSM) platform to include a common object data model that more efficiently normalizes data collected from multiple DevOps tools and platforms.

    Jeff Keyes, vice president of product marketing and strategy for Plutora, said the goal is to expand the level of scale and depth at which the Plutora analytics engine embedded within the Plutora Platform can analyze flow metrics.

    VSM has emerged as a distinct DevOps discipline that provides a framework for enabling organizations to optimize workflow across DevOps environments in a way that allows them to accelerate application development. The core concept traces its lineage to lean manufacturing methods that continuously measure each step of a process to improve production.

    As organizations develop a deeper appreciation for their dependency on software, the level of interest in understanding how software is constructed has increased. Organizations, for example, want to better understand the impact of missed software development deadlines on revenue, which a business might not be able to generate as quickly as anticipated.

    Plutora is making a case for a dedicated analytics platform that pulls data from multiple platforms. Alternatively, more value stream analytics capabilities are now being embedded in everything from project management software to continuous integration. Plutora contends, however, that navigating multiple value stream dashboards surfaced by different tools that make up a DevOps workflow is not as simple or effective as relying on a single platform that collects data from every tool employed.

    Metrics that track lead and cycle times for projects as well as overall throughput become much easier to surface and comprehend, noted Keyes.

    One way or another, more transparency is coming to DevOps workflows. Historically, collecting this data has been challenging because it required DevOps teams to manually collect data from each tool being used. In effect, DevOps teams were wasting time copying and pasting data from one tool into an analytics application.

    As it becomes simpler to aggregate all that data, the data model provided by Plutora makes it simpler for multiple analytics tools to analyze the same data. A business user, for example, may prefer to analyze data using the Tableau analytics platform that is now owned by Salesforce.

    In general, analytics is being applied more widely across software development processes because organizations need to increase productivity while simultaneously reducing costs. It will be up to each organization to decide to what degree they may want to use that data to better train DevOps teams versus simply using it to remind those teams to stay focused on a specific set of key performance indicators (KPIs).

    In the meantime, the number of requests for reports being made to DevOps teams should decline as the process of collecting metrics becomes more automated. The challenge now will be making sure everyone reading those reports has the same firm understanding of what’s actually possible to achieve using not only the resources at hand, but also how any additional DevOps expertise might positively impact that equation.

  • GitLab Updates Approach to Integrating DevOps Workflows

    GitLab Updates Approach to Integrating DevOps Workflows

    GitLab today took the wraps off a major update to its continuous integration/continuous delivery (CI/CD) platform that embeds analytics tools in workflows to identify the root cause of inefficiencies, among other additional capabilities.

    David DeSanto, senior director for product management at GitLab, said that capability is part of an ongoing effort to include value stream analytics within the core GitLab 14 platform as an alternative to acquiring and deploying a separate platform. There are also additional charts and dashboards that enable DevOps teams to uncover bottlenecks over time.

    In addition, GitLab announced it is extending the security capabilities of the platform by adding integrations with open source Semgrep and Trivy vulnerability scanning tools as part of an effort to enable organizations to embrace DevSecOps best practices within workflows. GitLab has also added support for the fuzz testing tool it gained via the acquisitions of Fuzzit and Peach Tech to enable DevOps teams to test application security more thoroughly along with making available additional dashboards to track security metrics.

    As part of an effort to enable organizations to better secure their software supply chains, GitLab has also added support for immutable pipeline definitions that can’t be altered without specific levels of permissions being granted. That capability also enables DevOps teams to more easily achieve compliance with any number of regulatory frameworks, noted DeSanto.

    The company is also adding a pipeline editor that provides access to a visual tool for creating, managing and visualizing pipelines. That tool is designed to both make DevOps more accessible to novices and provide experienced DevOps teams with an alternative tool for managing pipelines in a way that doesn’t require them to write additional code.

    Finally, as part of its comprehensive approach to DevOps, GitLab is also making available agent software for Kubernetes clusters to eliminate the need for organizations to acquire a separate DevOps platform to build and deploy cloud-native applications based on microservices constructed using containers. The company now provides IT organizations with the option of crafting a GitOps workflow for Kubernetes using either an agentless or agent-based approach.

    Gitlab is betting that, as DevOps continues to evolve and mature, more organizations will prefer to replace the various tools they need to integrate themselves with a platform that lowers the total cost of DevOps. Gartner is forecasting that, by 2023, 40% of organizations will have switched from multiple point solutions to a DevOps value stream delivery platform to streamline application delivery, versus less than 10% using such a platform in 2020. Today, only 10% of organizations are employing such a platform, according to Gartner.

    There should also be many more organizations employing DevOps workflows to build applications. Organizations of all sizes now realize how dependent they are on software to drive a wide range of digital business transformation initiatives. The rate at which that software can now be securely developed and updated, in many cases, goes to the heart of their ability to compete. The issue is finding a way to achieve that goal without constructing a platform that ultimately takes time and resources away from building secure software.

  • How Containers Simplify DevOps Workflows and CI/CD Pipelines

    How Containers Simplify DevOps Workflows and CI/CD Pipelines

    DevOps enables organizations to capitalize on the flexibility of cloud resources in real-time, which is a huge game changer. Just as the adoption of Agile methodology can make a development team more responsive, DevOps revolutionizes implementation of IT objectives from end to end, from a waterfall-style process gating company productivity to a dynamic process that makes better-quality software fast and easy.

    Organizations have been taking advantage of increasingly flexible resources and moving away from conveyor belt-style project delivery with hardware and software resource planning, ordering and integration. DevOps provides a way to address the question, “If we can provision resources quickly and easily, how can we complete entire projects with similar responsiveness?”

    As DevOps lowers the wall between development and operations, staying sane and accountable doesn’t have to bog down processes. Structured communication still takes place, but in an iterative, incremental fashion, much like polishing a jewel.

    Instead of lofty goals set in the somewhat-distant future, practical solutions can be created, deployed and adjusted. The process gets applications in the hands of end users far sooner, smooths any rough edges using actual user feedback, and helps organizations not only become more responsive to changing needs but make much more efficient use of valuable software development and operations resources.

    Why Dev and Ops Teams Need to Collaborate

    It can be hard for an organization’s culture to adapt to this level of change. But both development and operations teams have some pain points that help motivate them to work together more dynamically.

    The development (Dev) side of the house wants to deliver more timely solutions, ensure greater acceptance of new applications and use its resources more efficiently. Operations (Ops) has challenges with hardware resource planning; they have maintenance and cost-reduction projects that are delayed. Ops also has insights into new features, efficiencies and integrations, but with no way to implement them.

    These and other pain points arise when traditional, waterfall-style processes constrain communication and implementation. Creating a new flow between the two teams helps to reduce these pain points.

    Rather than being tied to a specific technology, DevOps is a methodology aimed at making software development efficient. Containerization narrows the gap between development and IT Ops to a minimum. Containers are a great tool for enabling DevOps workflows and simplifying the development and delivery pipelines. Containers hold the code and dependencies required to run an application and reside in isolation. This enables teams to develop, test and deploy apps inside these closed environments. And this doesn’t affect different parts of the delivery, making the lives of testers and developers a lot easier.

    Enabling CI/CD

    DevOps has created a way to automate processes to build, test and code faster and more reliably. Continuous integration/continuous delivery (CI/CD) isn’t a novel concept, but tools like Jenkins have done much to define what a CI/CD pipeline should look like. While DevOps represents a cultural change in the organization, CI/CD is the core engine that drives the success of DevOps.

    With CI, teams must implement smaller changes more often, but they check the code with the version control repositories. Therefore, there is a lot more consistency in the building, packing and testing of apps, leading to better collaboration and software quality. CD begins where CI ends. Since teams work on several environments (prod, dev, test, etc.), the role of CD is to automate code deployment to these environments and execute service calls to databases and servers.

    The CI/CD concept isn’t entirely new, but it’s only now that we have the right tools to fully reap the benefits of CI/CD. Containers make it extremely easy to implement a CI/CD pipeline and enable a much more collaborative culture. Containers are very lightweight and can scale endlessly, run on any environment and are very flexible. It doesn’t get easier than this.

    Now, you can move code across containers–or container clusters, as is the case with Kubernetes–instead of moving code among various virtual machines (VMs) in different environments. VMs are static and leverage a monolithic application architecture, whereas containers use a distributed microservices model. This opens doors to new benefits when it comes to elasticity, high availability and resource use.

    As part of a DevOps team-oriented approach, team members can reach out to their peers and share innovation, feeding their knowledge and experiences into the evolving process. Development teams can put the new resources to use, taking advantages of technologies such as containers and Kubernetes to architect solutions. Working together, this cooperation lets Ops run with the solution, scale it, distribute and upgrade efficiently without delay.

    Putting it All Together

    DevOps has helped organizations reimagine their entire development lifecycle. And while DevOps brings cultural change, CI/CD is the core engine that makes DevOps successful. New tools like containers now make it easier for organizations to make the most of CI/CD. However, data storage must be taken into consideration, because it undergirds a dynamic DevOps environment. It also provides failover, disaster recovery and other essential availability and reliability features. Software-defined storage offers the flexibility that a dynamic DevOps environment needs. It’s a crucial element in the success of your DevOps program.