devopsy.kinsta.cloud

Category: Blogs

  • Free as in Beer

    Free as in Beer

  • Apollo GraphQL to Provide More Control Over APIs

    Apollo GraphQL to Provide More Control Over APIs

    Apollo GraphQL today previewed an update to its Federation platform for tracking and managing application programming interfaces (APIs) based on the GraphQL query language to give organizations more control over how APIs are reviewed and ultimately approved.

    Matt DeBergalis, founder and CTO, Apollo, said the alpha edition of the Federation 2 platform provides a unified view of distributed APIs based on GraphQL so they can be more easily governed.

    Federation is based on a unified graph created by Apollo GraphQL to initially provide more visibility into how APIs based on GraphQL are employed within an organization. That capability makes it simpler to increase collaboration among development teams that typically build APIs in isolation from one another, noted DeBergalis.

    The latest version of Federation also adds a shared ownership model that empowers teams to evolve unified graphs across smaller teams, he noted.

    In general, DeBergalis noted that Federation reduces the chances developers are going to create redundant APIs because they can more easily discover existing ones. They can then either employ those APIs as-is or modify them to suit their requirements as they increasingly compose an application using tools such as Apollo GraphQL Studio versus building every capability from the ground up themselves.

    GraphQL

    Overall, Apollo GraphQL claims that Federation is currently being downloaded more than one million times a week, with more than 30% of Fortune 500 companies such as Netflix, PayPal, Zillow, Walmart, Peloton and Priceline already using its tools.

    The company is also now making Federation and the rest of its tool portfolio available under the Elastic License 2.0 which provides the right to use, copy, distribute, make available and prepare derivative works of the software, but prevents organizations from offering a managed service, circumventing license key functionality or removing/obscuring features protected by license keys or remove or obscure any licensing, copyright or other notices.

    GraphQL, originally created by Facebook, is gaining traction as an alternative to REST APIs because it gives developers more control over how data is accessed via an API using a set of query capabilities. That capability is especially appealing when constructing digital business processes that require access by specific classes to large volumes of data. In fact, DeBergalis notes that, in many cases, it’s the existence of a rich set of APIs that enables organizations to construct digital processes that bridge the various isolated processes organizations previously had in place.

    Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight. However, there will soon be enough APIs based on GraphQL to have a significant impact on how applications are built and deployed. Many applications may wind up invoking external services via both REST and GraphQL-based APIs for many years to come.

    In the meantime, the rate at which applications are being built should substantially increase as tools such as Federation make development teams more productive. The challenge many DevOps teams will soon face is managing a large volume of deployments and associated application updates as more applications are deployed in production environments.

  • Oracle Adds AI Services to Cloud Portfolio

    Oracle Adds AI Services to Cloud Portfolio

    Oracle today unfurled Oracle Cloud Infrastructure (OCI) AI services, a collection of services that make it easier for developers to use application programming interfaces (APIs) to invoke a wide range of services based on algorithms trained by Oracle on their behalf.

    Elad Ziklik, vice president of product management for AI services and data science at Oracle, said the primary goal is to offload the data engineering tasks associated with machine learning operations (MLOps) from organizations that simply want their developers to include AI capabilities within their applications without having to necessarily hire and then retain a dedicated data science team.

    However, organizations also have the option of uploading their own data into OCI AI services to retrain the models provided by Oracle, he noted.

    Ultimate, the goal is to make OCI AI services a simple extension of DevOps workflows by making it simpler to employ AI models; these models become just another software artifact that can be stored and updated in a Git repository alongside all the other artifacts managed by a DevOps team, said Ziklik. In effect, Oracle wants to make AI ‘boring’ in the sense that these capabilities can now be readily invoked by any development team, he added.

    The OCA AI services include OCI Language, a text analysis capability that enables developers to add sentiment analysis, key-phrase extraction, text classification, named entity recognition and other similar capabilities to their applications, and OCI Speech, which converts file-based audio data containing human speech into text transcriptions.

    Oracle has also included OCI Vision for image recognition and document analysis tasks, OCI Anomaly Detection to create models that flag irregularities in processes, OCI Forecasting for tracking business metrics over time and OCI Data Labeling for creating datasets to train AI models.

    These services are designed to address the most critical AI requirements of the average enterprise rather than attempting to outperform on a set of AI benchmarks that don’t reflect the requirements of business development teams, said Ziklik.

    In addition, Ziklik noted Oracle has also made it easier to address AI compliance requirements that will eventually require organizations to document precisely how their AI models work.

    At some point soon, just about every application will be invoking AI capabilities to one degree or another. That shift creates a major workflow challenge for DevOps teams. AI models are typically created by data science teams that typically don’t successfully deploy an AI model in a production environment more than a handful of times a year. Those AI models, however, need to be integrated with applications that, in many cases, are being continuously updated via DevOps workflows.

    Oracle said that goal becomes easier to achieve using models it creates versus allowing data science teams to build out a set of custom MLOps workflows on platforms that then need to be maintained by IT professionals. Instead of having to set up, for example, a feature store to track and manage AI models, the models created using OCI AI can be stored in an existing Git repository.

    Naturally, each organization will need to determine the degree to which they will converge MLOps and DevOps best practices. Oracle, however, is betting that the simplest way to achieve that goal is via AI models surfaced via a cloud service that developers can readily invoke whenever required.

  • AWS BugBust Challenges Developers to Set World Record for Bug Busting at re:Invent 2021

    AWS BugBust Challenges Developers to Set World Record for Bug Busting at re:Invent 2021

    Software bugs are irksome, time-consuming and can be one of the most expensive software development costs for any company on an ongoing basis. Software Testing News cited a study that found the cost of poor software quality in the United States alone was estimated to be $2.8 trillion dollars. Let that sink in. $2.8 trillion dollars. And 18.22% of that cost was technical debt. Pair that with the fact that Watts Humphrey1 estimated in his book, A Discipline for Software Engineering, that, on average, software developers make 100 to 150 errors for every thousand lines of code.

    Suffice it to say that the costs of poor software quality are significant.

    Welcome to the First Annual AWS BugBust re:Invent Challenge

    AWS is making a commitment to help software teams around the world improve software quality with their global AWS BugBust Challenge. The first annual AWS BugBust re:Invent Challenge is right around the corner.

    The challenge, taking place from November 29, 2021 at 10 a.m. PST through December 2, 2021 at 2 p.m. PST, enlists Java and Python developers to collectively fix bugs and eliminate technical debt using Amazon CodeGuru. Within this time frame, registered participants across the globe—participating virtually—and those present onsite at the BugBust Hub at the AWS re:Invent Expo, can compete to fix as many bugs as possible to win prizes, glory and claim the title of the Ultimate AWS BugBuster. For each bug that you fix, you receive points based on the complexity of the bug. The more bugs you fix, the more points you will gain and the higher you will climb up the AWS BugBust Leaderboard. The live leaderboard will track each participant’s progress and showcase the number of bugs fixed and points received.

    Be a Part of Setting a Bug-Busting World Record

    At re:Invent, AWS also is looking to set a Guinness Book of World Records record for the largest code-fixing challenge ever. To date, there are no existing records for an event of this kind. Fix at least one bug to qualify to be part of setting the Guinness record. You can join onsite or online. Be part of the excitement of trying to set a world record while winning prizes and gaining recognition!

    Milestone Prizes

    While developers will go head-to-head to win the title of the Ultimate AWS BugBuster, they will also have the opportunity to win prizes for their milestone achievements. The Grand Prize will be $1,500 in cash. 

    There will be five key milestones that developers will be working towards:

    • First milestone—1 point—AWS BugBuster Fly Swatter
    • Second milestone—50 points—AWS BugBust branded sanitizer (BugSpray)
    • Third milestone—150 points—AWS BugBust glow-in-the-dark Bug Jar
    • Fourth milestone—300 points—AWS BugBust hoodie
    • Fifth milestone—500 points—AWS BugBust branded Echo Dot
    • Grand prize—$1,500 for the top BugBuster

    In addition to the milestone prizes, all developers who have contributed toward setting the record for the world’s largest code-fixing challenge will receive an exclusive AWS certificate. The bugs fixed at this live event will count toward the global total which the AWS BugBusting team will have front and center at the event.

    AWS BugBust Hub

    The BugBust Live Challenge will be hosted in the BugBust Hub. The Hub will provide a fun and relaxing environment for developers to fix bugs and ask questions of the AWS BugBust SWAT team as they get started on the BugBust Live Challenge. Not on-site at AWS re:Invent? No worries—developers can still participate and win prizes virtually, too!

    For more information and to pre-register for the AWS BugBust re:Invent Challenge, please visit the AWS BugBust website.

    1 Known as “the father of software quality,” Watts S. Humphrey is the author of numerous influential books on the software development process and software process improvement. Humphrey is a fellow of the Software Engineering Institute (SEI) at Carnegie Mellon University, where he founded the Software Process program and provided the vision and early leadership for the original capability maturity model (CMM). He also is the creator of the personal software process (PSP) and team software process (TSP). He was awarded the National Medal of Technology―the highest honor given by the president of the United States to America’s leading innovators.

  • Organized Architecture

    Organized Architecture

    I’ve mentioned IT pendulums plenty of times before, but today I’m going to use them to explore a different angle on IT: The age of containers and microservices. It’s time to ask yourself if the current architectural design of the overall product offering of IT is the best one you can afford to offer.

    Agile and the whole “developer is king” movement brought us a whole lot of independent app teams running off and doing their own thing. While the core of that movement was short-lived, we got a lot of good and bad out of it. The good included breaking the traditional “We change at glacial rates” process that some IT shops had—because a team absolutely wants the tools that will make their job easier, not the ones pre-approved by committee or whatever process a given org used. And the bad included the very things those of us who’ve seen this type of thing play out before warned about. Suddenly, we had critical apps and infrastructure relying on tools that one dev used in his hobby development. Sometimes that was good, and for sure it happened before Agile came along, but now we had an avalanche of it. Stuff that hadn’t been through security; often code/libraries/apps that no one outside the team (or the individual) knew was running in the organization. Some of that stuff is still happening.

    And then we hit true uptake of microservices. That drove us to break things up in non-traditional ways. A lot of good came of that process, but a lot of complexity did, too. Complexity shared across applications with a huge spike in API calls and operations with a spike in deployed processes and routing. Perhaps the worst thing to come out of the combination of the two is “Who cares why it failed? Just spin up another!” That movement is mostly dead (thank goodness), but it only died because of the number of high-profile “Oops” issues that it caused. It allowed attackers to go unnoticed; it caused paying customers to spread security details across the web; it caused users to suffer crashes that would have been fixed in any sane development environment … and some of those are still out there. Cases where there’s a script to restart an app or service every X hours because it crashes randomly. Not acceptable. Make all the excuses you like, but if you don’t know what’s causing the crash, you’re wrong to leave the app or service running.

    And we introduced a huge amount of complexity. Now we have double the infrastructure—one physical, one virtual (container or cloud). We have applications spread across a lot more systems (be they instances or physical systems) and often across platforms; even across data centers. We live in a very cool time, with some sweet stuff going on. But complexity is a very real problem we need to solve. One app/app portfolio may have limited complexity, but we still allow teams too much leeway in defining the environment the application lives in. We need to offer a happy medium—a world where there are options, but those options are defined, manageable, and secure.

    So we’re likely to see a resurgence in the importance of enterprise architecture teams again, with their focus being on organizing the mess we’ve made. Indeed, I know this is underway in a couple of Fortune 500 companies I stay in touch with. And I know of one organization that isn’t doing this and has all their UI functionality running through a single container … for multiple applications. That is no better architecture than each using a completely different UI toolset. So, I expect they’ll want coordinated solutions also. Just so something like that can’t happen again.

    You all are doing it, day in and day out. As I often say, just don’t let this bit drag you down. Confront it head-on, approach standardization with “Yes, where it is good; no, where it is not” as your credo. Security is the big one, but maintainability is another. Even with tools like Ansible at their disposal, managing 50 different environments is a bit much for ops if it could be done with five. And keep rocking it. Through a pandemic, meeting increased demand, giving users more and more. Thanks once again, from all of those users who don’t know to thank you.

     

  • Newly Independent VMware to Focus on Multi-Cloud

    Newly Independent VMware to Focus on Multi-Cloud

    As an independent company once again, VMware will focus its efforts on providing management planes that span multiple cloud computing environments after officially spinning out of Dell Technologies.

    Ray O’Farrell, executive vice president for the cloud-native apps business unit at VMware, said the company now has a unique opportunity to work closely with providers of cloud services, builders of on-premises IT infrastructure and providers of telecommunications services.

    The terms of the spin-off included an $11.5 billion special cash dividend that resulted in a $27.40 per share dividend payment to all VMware stockholders. VMware claims the simplified financial structure that arises from the deal will provide it with additional operational and financial flexibility.

    Going forward, much of the development work will focus on providing management planes that not only span multiple clouds but also address specific cross-platform requirements such as security. It’s not likely there will ever be one single uber control plane for all of IT, noted O’Farrell. Rather, IT teams should expect VMware to deliver a series of well-integrated control planes to automate specific tasks in a way that breaks down IT silos, he said.

    VMware, however, under terms of its existing alliance, will also continue to work closely with Dell to create server environments that are optimized for VMware hypervisor platforms, O’Farrell said.

    Key to the strategy is a portfolio of observability tools that VMware plans to continue to expand, noted O’Farrell. VMware will also address the requirements of both traditional monolithic applications running on virtual machines as well as cloud-native applications running on distributions of Kubernetes, such as VMware Tanzu, that may be deployed on top of a hypervisor or on a bare-metal server, he added.

    Given the complex state of IT environments today, it’s all but inevitable something will go wrong, said O’Farrell. The challenge and the opportunity for VMware is to provide IT teams with the observability tools required to discover as many issues as possible before they adversely impact the business, he added. Once those issues are discovered, IT teams should be able to automate the remediation process using the rest of the portfolio of VMware management frameworks, he noted.

    Those management frameworks will also provide the foundation for unifying traditional approaches to IT service management (ITSM) with DevOps best practices that are now being used more widely, especially to manage cloud-native applications, said O’Farrell.

    When it comes to on-premises IT environments, VMware continues to dominate. Its hypervisor is, by far, the most widely used on servers in local data centers. VMware has spent much of the last two years expanding its reach into multiple clouds to enable IT organizations to standardize on a series of management frameworks. The goal is to reduce the total cost of IT by reducing reliance on what would otherwise be a hodgepodge of isolated management frameworks. The challenge VMware regularly encounters is the IT teams that manage cloud computing environments are not always the same ones that are managing on-premises IT environments. As such, many IT teams that have deployed cloud applications tend to embrace the management frameworks provided by their cloud services provider.

    VMware, however, is betting that as more organizations look to reduce the total cost of IT, the economic pressure to converge IT management using its frameworks will be simply too great to ignore.

  • How AI is Changing DevOps for the Better

    How AI is Changing DevOps for the Better

    Managing a DevOps environment involves a high degree of complexity. The rapid proliferation of data has made it difficult for DevOps teams to effectively onboard, ingest and unlock data and implement information to make good business decisions and deliver delightful experiences. Imagine a team poring over troves of information to identify critical factors that triggered an event—they would end up investing long hours to interpret and analyze the information.

    The future of DevOps will be AI-driven. It’s fair to say that it’s challenging for human intelligence to harness large volumes of highly complex data. Consequently, AI-powered solutions will become the number one choice for integrating and analyzing data and transforming how teams develop, deliver, deploy and manage applications.

    By 2023, 40% of DevOps teams will leverage application and infrastructure monitoring solutions with built-in AI capabilities, Gartner noted. Currently, in times of disruption, Gartner predicts the AIOps market will grow at breakneck speed, between $300 million and $500 million per year.

    Let us explore how AI and DevOps are intertwined before we explore how AI is transforming DevOps.

    DevOps and AI are Intertwined

    AI and DevOps are intertwined. Integrating AI in a DevOps environment boosts the overall performance and efficiency of an organization.

    AI and ML-powered solutions enable DevOps teams to onboard, map and integrate large volumes of customer or partner data with accuracy and speed. That is to say, business users find it easier to drive processes like data onboarding, data mapping and data integration, thus improving ease of doing business and delivering improved customer experience (CX).

    Organizations that rely on AI-powered solutions no longer need to devote long hours to custom coding and EDI mapping to analyze large volumes of data. The time saved can be used to focus on more important, innovation-driven tasks.

    AI also boosts automation, allows users to address and resolve issues in both data and applications and facilitates better cooperation among teams.

    4 Ways AI is Transforming DevOps

    The efficacy of DevOps correlates with an upward shift in AI. It can empower even non-technical business users to create connections and drive transactions at the speed of business. As a result, it brings non-technical business users to the forefront of business, thus freeing IT and developer teams to focus on more important tasks. Business users can leverage machine learning algorithms to collect data from different parts of DevOps systems and then map and integrate it in minutes through predictions.

    Here are four ways AI is transforming DevOps:

    1. Improved data access: The lack of free access to complex data streams is a challenge for DevOps teams. AI enables business users to access all the siloed data and harness its true potential for better insights delivery and decision-making. AI-powered tools can gather data from various sources for consistent and repeatable analysis.
    1. Faster data integration: AI and ML-enabled technologies enable non-technical business users to execute data mapping and data integration in minutes instead of months. As non-technical users drive operations, IT becomes free to take up governance and instead focus on more high-value tasks. Thus, not only can AI help business users integrate data faster to deliver experiences and value but also enables IT teams to drive innovation and growth.
    1. Higher implementation efficiency: With the support of AI, businesses can perform more tasks with less human intervention and minimal coding. This reduces the burden laid on IT or developer teams, enabling them to concentrate more on innovation and creativity.
    1. Better security: As security is essential to facilitate a successful software implementation, DevSecOps is a fundamental aspect of software development. Organizations must bolster their security systems to guard against an increase in threats. AI can play a vital role here. It can enhance DevSecOps and boost security by recording threats and executing ML-based anomaly detection through a central logging architecture. By combining AI and DevOps, business users can maximize performance and prevent breaches and thefts.

    Accelerating development cycles while making sure data is interpreted and analyzed properly is a challenge faced by DevOps teams today. Artificial intelligence-powered solutions are helping organizations transform every stage of DevOps building cycles without burdening IT teams or adding costs. Ergo, AI can enable users to transform the DevOps environment, deliver delightful experiences and grow revenue.

  • GraphQL’s Greatest Strength is Also its Greatest Weakness

    GraphQL’s Greatest Strength is Also its Greatest Weakness

    Michael Scott: Why don’t I tell you what my greatest weaknesses are? I work too hard, I care too much and sometimes I can be too invested in my job.
    David Wallace: Okay. And your strengths?
    Michael Scott: Well, my weaknesses are actually strengths.
    David Wallace: Oh. Yes. Very good.

    GraphQL is a new query language that offers a simple way to interact with structured data. The best thing about GraphQL’s design is its convenient data fetching process which enables the requesting party to collect limitless data and perform multiple actions, all with a single API call. This interaction method makes it super useful and very easy to use. However, from a security perspective, its greatest strength could also be its greatest weakness.

    I recently met with Elad Koren, chief product officer, Salt Security, to understand the nuances of GraphQL security. According to Koren, GraphQL affords better usability than REST APIs, yet its bundled request model may compromise systems that don’t employ proper object-level authorization checks. Also, since developers interact with GraphQL services differently than typical web APIs, hackers could avoid detection by typical firewalls, requiring a new approach to security.

    These concerns aren’t dealbreakers for adoption; rather they are a reality check for those using GraphQL in production. Below, we’ll explore some potential weaknesses and look at some general mitigations that providers can take to improve the confidentiality of their GraphQL endpoints.

    What is GraphQL?

    GraphQL was initially developed by Facebook and open sourced in 2015. It’s a query language that makes data retrieval and manipulation with external sources very easy. Instead of programming and linking together complex calls with traditional HTTP API requests, GraphQL enables a client to bundle queries into a single request. This design pattern reduces the under- and over-fetching pattern that REST APIs typically suffer from.

    “You get exactly what you need, not more or less,” described Koren. This makes GraphQL a popular choice for modern database mechanics over REST, as it’s similar to SQL querying.

    Adoption of GraphQL is steadily growing; a 2020 RapidAPI survey found GraphQL usage had quadrupled. GraphQL is now used by 22.5% of API developers. But when it comes to overall API design patterns, REST is still the dominant architectural style used by 93.4% of APIs, found Postman’s 2020 State of API Report.

    GraphQL is promising and has a number of benefits, but remains in an early adoption phase. “It’s still a technology that early adopters are starting to look into—it’s not so widespread,” said Koren. Due to its age, GraphQL security practices are immature, exposing a few potential vulnerabilities for platforms that use GraphQL.

    Unique Security Concerns

    So, what are some unique security concerns in the GraphQL paradigm? Well, according to Koren, it begins with a lack of understanding. “Security is not necessarily top-of-mind most of the time,” he said. “When developers choose to implement GraphQL, they assume that they’re not using APIs anymore and that traditional REST API vulnerabilities do not apply.”

    In fact, the opposite may be true. GraphQL APIs can easily suffer from broken object-level authorization, OWASP’s number-one API vulnerability, just as REST APIs do. But, with greater ease of access to many underlying systems, a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could suffer from data overexposure.

    Another issue concerns spotting malicious behavior. Typically, when hackers perform reconnaissance on an API, they brute-force it with many requests; trying different namespaces and changing user agents in the process. With REST APIs, this sort of malicious behavior is easier to catch with standard web application firewalls (WAFs) since it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a hacker conducting query batching could completely fly under the radar of typical thresholds.

    This could easily lead to an account takeover, said Koren, who has seen this in production. He described a production payment service that used GraphQL; callers could perform mutations and capabilities they shouldn’t have been allowed to perform, such as pulling up other users’ account information and even initiating transactions.

    It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks once at a time. But, this playbook is thrown out the door in GraphQL. “When you’re using a single point to access the data, you may have some false sense of security,” said Koren. In practice, having a single access point requires hard work to retain its integrity. A usable GraphQL frontend may also often mask a convoluted backend made of disparate API styles, Koren explained, making it much harder to correlate user authorizations to specific resources and mutations across various microservices.

    Tips to Mitigate Weaknesses

    So, with these weaknesses in mind, how should GraphQL-based platforms respond? Koren provided the following advice to protect GraphQL APIs:

    • Adopt a security mindset in development: It’s vital to start with a security culture from the beginning. Usability shouldn’t compromise security; ideally, they should complement each other.
    • Ensure proper authorization checks are in place: Whenever an asset is provided to the user, you need to consider whether the user is authorized to access it—especially if they are hitting multiple resources at once.
    • Set a new baseline specific to GraphQL: GraphQL owners need to adapt their perimeter security systems to look for new queues. These validations should consider typical REST API security checks and nuanced thresholds that consider nested queries and batch queries.
    • Know your API inventory: Maintain a clear picture of the underlying architecture of what is beneath the GraphQL endpoint. Verify the data sources and ensure they correctly correspond to user privileges.
    • Increase visibility into API calls: If possible, increase your visibility into queries, mutations, attributes, variables and underlying specifications and how they interact with each other.

    Strengthening GraphQL Endpoints

    API attacks are rapidly increasing. Gartner estimates APIs will become a top threat vector in 2022, and Salt Labs data showcased a shocking 300% growth in malicious API traffic in mid-2021.

    “Like any other innovative tech that comes into the mainstream, it will rise in popularity, but it will not surpass REST in the foreseeable future,” says Koren. Perhaps in three to four years, GraphQL’s current 20% adoption rate will rise to 30% to 50%. While GraphQL is still a relatively niche tool, its use is growing, especially among API-first cloud-native tech companies. And with this adoption will come novel security concerns.

    According to Koren, query batching makes catching malicious attacks using ordinary firewalls tricky. Thus, training a new baseline to discover anomalies unique to GraphQL will be necessary to find and limit hackers while they are still in the reconnaissance phase. Thus, we’ll likely see future security investment go into spotting these atypical GraphQL interactions.

    In general, perhaps the best advice is to treat GraphQL with the same level of intensity you would with any other type of API—if not more. As a single doorway to many underlying systems, GraphQL requires added security forethought and careful application of user authorization.

    With that squared away, hopefully, GraphQL’s greatest strength will remain just that—a great strength.

  • FinOps 101: Demystifying Cloud Financial Operations for DevOps

    FinOps 101: Demystifying Cloud Financial Operations for DevOps

    In an ideal world, all organizations would have a dedicated FinOps team—or at least a single specialist who could work to ensure that the cloud was operating in a financially savvy way. Of course, in reality, most organizations are strapped for skills and are operating lean teams where responsibilities are spread thickly across employees. In that case, DevOps professionals are likely to get left holding the FinOps bag and tasked with implementing FinOps best practices into their everyday cloud operations. If that sounds familiar—here’s your guide to getting started.

    The Cultural Shift of Considering FinOps

    In many ways, it’s not that great a leap for DevOps to start thinking about FinOps. After all, the underlying goals of both strategies are to optimize, improve and streamline operations. The difference is that DevOps is focused on software development and technical skills, while FinOps looks at the financial costs of operating on the cloud.

    The biggest challenge is that sometimes these goals may be at odds with each other. If DevOps teams are tasked with getting new software releases and fixes out of the gate as quickly as possible, that can often come at the expense of the most cost-effective solution. Think, for example, about AWS on-demand instances in the cloud. It’s arguably more FinOps-friendly to look for reserved instances, savings plans and committed use discounts and to put into place right-sizing opportunities where possible. However, with the pressure on DevOps teams to keep up an agile release cycle and offer quick fixes, anything that stands in the way of their flexibility and freedom can feel worth the price tag.

    As a result, it can be a true paradigm shift for engineers and DevOps teams to start thinking about FinOps first, especially if they already feel that their plate is full. Here are some best practices that can help to smooth over any bumps in the road.

    Make Engineers Accountable

    Don’t simply add new stakeholders who are responsible for cost management and FinOps, as they will quickly become adversaries of your engineers. Instead, ensure that your technical teams and developers realize that they are responsible for their cloud costs. They need to know what they are using and they need to codify and document how they are looking to use their budget more effectively.

    Of course, the business has a role in this too, showing engineers best practices for FinOps, such as shutting down idle resources, right-sizing instances or making smart architecture decisions. 

    Explain That FinOps Isn’t a Cost-Cutting Initiative

    If DevOps teams have been given the equivalent of a blank check thus far, it can be a tough sell to start tightening the purse strings. Explain to DevOps teams that you aren’t looking to cut their budget. In fact, you might even be increasing it!

    FinOps is all about smarter financial operations, so if engineers can show that they can save money in one direction, they can channel that to new features, technologies and tools that make them happy. Giving DevOps teams control over FinOps decisions offers more autonomy and control—and that’s a great thing.

    Ease the Mental Load With Low-Hanging Fruit

    Once DevOps teams get much-needed visibility over their cloud usage and realize that they are gaining responsibility and autonomy over their behavior, you want to guide them to recognize where they can make changes. Challenge all your DevOps stakeholders with the same KPIs, and see who can come up with innovative ways to incorporate cost savings into business-as-usual. Some KPIs that could be a great start include:

    • Coverage: Use of reserved instances, savings plans, spot instances or committed use discounts.
    • Right-sizing: The opportunity value of downsizing or terminating instances that are idle or underutilized.
    • Orphan/idle status: Tracking the percentage of orphaned EBS volumes or snapshots; you can drill down into a specific time period, such as over one month.
    • Forecast metrics: Consider using the variance between a forecasted bill and the actual costs and aim to reduce this as much as possible.
    • Incorrect assignation: This would highlight oversized or incorrect instance types, S3 or EBS storage on the wrong tier, unattached elastic IPs or poorly tagged/ untagged resources.
    • Peak hours: What percentage of development resources are running during peak hours or running when they could be shut down; for example, on weekends?

    Automation Incorporates FinOps Best Practices in a Hands-Off Way

    If this all sounds like a full-time job in and of itself—you’re not wrong. You’d be forgiven for wondering when DevOps teams are meant to actually develop and build! To keep engineers and technical teams productive, make sure that you’re offering the right tools and technology to lighten the load where possible, especially where automation and AI can do a better job than a room full of DevOps or FinOps experts.

    One example is automating the purchasing and selling of reserved instances in real-time, so that you’re never left buying on demand. Another is automating the removal or rightsizing of idle or underutilized resources, respectively. When your DevOps teams see that you’re offering the technology to make FinOps simple, they are much more likely to do their part elsewhere.

    DevOps and FinOps

    In recent years, security teams have championed the idea of DevOps ‘shifting left’ on security best practices to get security included in the process of agile software development during the build stages.

    Well, you heard it here first: It’s time for a similar shift for finance and cost optimization.

    Just as engineers can no longer get away with ignoring security in the way that they work, financial optimization needs to be front and center of DevOps teams’ day jobs. For this to work and for DevOps to incorporate FinOps goals seamlessly, businesses need to champion visibility for cloud usage, a culture of cost-optimization and a strong foundation of automation that bakes best practices into everyday work.

  • Choosing the Right Software Testing Metrics

    Choosing the Right Software Testing Metrics

    A software testing metric is a criterion to track the effectiveness of quality assurance efforts. First, you establish success indicators throughout the planning stage. Then, compare them with the received metric after the completion of the process.

    However, many software QA and test experts tend to focus on how the tests will be executed rather than on the actual information produced by the tests. By this I mean testers often focus on the mere satisfaction of completing all the tests. But is this always a good thing? You can have a 100% pass rate with all green indicators on your dashboard and it is still possible that your tests aren’t strong enough.

    This article will discuss five software testing metrics that might assist QA professionals in evaluating their success.

    Characteristics of a “Good” Testing Metric

    Let’s talk about the features a metric should ideally have.

    Relevant to Business Goals

    Critical KPIs should reflect the primary mission and purpose of a business; for example, monthly revenue growth or the number of new users. Each company chooses its metrics based on what they intend to achieve with their product. While it may seem attractive to succeed in all tests, focusing on the wrong goals can be deceiving. This may impact the app’s work and the entire complex system, such as headless commerce architecture.

    Allows for Growth

    Every metric should allow for improvement. What if you’ve achieved a 100% success rate? The goal may be to keep the metric at this level or to improve it further.

    Encourages Development of a Strategy

    When a metric gives a team a goal, it also motivates them to ask questions to develop a plan. Suppose you need to increase revenue. Consider whether the product requires new features to encourage more purchases. Is it necessary to create a new acquisition channel? Has the competitor launched any new products or features that are attracting new buyers?

    Trackable and Comprehensible

    Good metrics are simple to comprehend and follow. Otherwise, how will the people gathering them make informed decisions? Employees must understand what they can do to improve the outcome.

    Three Tips for Choosing and Measuring Software Testing Metrics

    1. Start by Asking Questions

    Your questions should cover three topics:
    1. What you’re measuring
    2. Strategies and tools to measure it
    3. Reasons to track it

    To avoid analyzing useless metrics, pay attention to the metrics definition process. Sometimes, a small number of backlog bugs means your QA team is doing its job. However, when you break down these bugs into high/medium/low priority issues, you’ll be able to better see the overall program quality and make the needed adjustments.

    2. Don’t Neglect Automation When Calculating QA Metrics

    Automation saves you time on manual data collection and helps ensure your metrics will always be relevant. Let’s assume you use Jira. Set up a Jira Query Language (JQL) request on your Confluence page if you need data on critical bugs every sprint. It will be updated frequently. Or you can employ other tools based on your preferred test management/task tracking system.

    3. Collect Comments and Gradually Improve Metrics

    Once you’ve set up and gathered all the metrics, the feedback and improvement processes start. Pay attention to feedback to improve the efficiency and clarity of your metrics and reports.

    Five Software Testing Metrics to Track

    Now let’s look at some specific examples. Note that different quality aspects matter to varying degrees depending on circumstances.

    1. User Satisfaction

    Here, you’ll want to see the client’s reaction to the product. You use user satisfaction surveys and support tickets that reveal bugs. If you track these quality metrics and work to improve them, the business will grow as you’ll see more satisfied and returning customers. If something’s wrong, you’ll have to do a causal problem analysis and remove the roadblocks.

    2. Process Metrics

    These are internal measurements that have a significant impact on your product quality. For example, you can track lead time and the time it takes between setting the task and code deployment and production.

    One more metric you could use is cycle time. It means time to build a feature after being given the approval to begin working on it. Finally, you can track the time it takes to solve difficulties. This could refer to the speed of resolving tickets or bugs once they’ve been reported.

    As these metrics can be hard to measure, another method to improve process efficiency is to detect where unfinished work starts to pile up in the queue. It can highlight a bottleneck that, if removed, could help your teams become more productive.

    3. Coverage Metrics

    Another indicator of test quality is test coverage. It informs us of the amount of tested code. It’s a method of ensuring that your tests check the code and how much they operate. In this case, it’s better to use a top-down strategy. The first step is analyzing module coverage. Then you consider functionality and, finally, data coverage in each functionality. It means how many different combinations of the potential data inputs you’re covering with tests.

    This group includes such metrics as:
    ● Requirements coverage percentage
    ● Unit test coverage
    ● Manual or exploratory test coverage
    ● Test cases by requirement category
    ● UI test coverage
    ● Integration and API test coverage

    4. Code Quality Metrics

    Evaluating code quality means categorizing the value of code into two categories: Good and bad. There is no single notion of quality because practically every developer defines for themselves what constitutes good code. How can you assess code quality? Tools like SonarQube let you reveal how much technical debt is in a system. You’ll need to classify issues and vulnerabilities, organize them by priority and select what you’re going to focus on.

    5. Bug or Incident Metrics

    Each issue differs in severity, so don’t give all issues equal weight. Some problems are simply suggestions for improvement. Determine which components of quality are more important than others for your company. That said, go beyond just the amount of defects when analyzing the metrics you’ll use.

    What can you extract from incident reports? These results can include:

    ● Total number of bugs
    ● Open defects
    ● Closed defects
    ● The time to close each incident report
    ● Changes since the last release

    Rules for Measuring Software Testing Metrics

    Evaluating metrics in software testing and estimating their success can be frustrating and vague. Here are some tips and suggestions you can use:

    1. Correlate your metrics with project, process and product goals. Keep in mind that a single indicator is not enough for a complete view of your software quality.
    2. Track the progress (or regress) throughout time. Streamline the data collection process through automation, store data in a collaborative resource like a Wiki/Confluence and review outcomes regularly.
    3. Report the statistics to the customer and the team to show your progress. Reports should be easy to understand, so make them helpful and user-friendly.
    4. Check to make sure if the metrics are valid. Keeping track of irrelevant metrics and displaying inaccurate data is out of the question.

    Measurement is an important activity in software testing, such as determining the number of successful tests against how many have failed. All the information you get comes to stakeholders. As a result, they can make informed decisions such as when to release an app.

    How can you monitor your test activities? You need to determine relevant software testing metrics. Choosing the correct testing metrics can be difficult. Frequently, teams opt for metrics that are out of sync with the overall business.

    What can the lack of adequate benchmarks cause? Stakeholders fail to measure progress, identify possibilities for development or control which testing tactics have the most positive impact. All things considered, QA teams need to track individual progress, skill level, and success, as well as code quality, bugs, and coverage.