devopsy.kinsta.cloud

Tag: application delivery

  • Extending the GitOps Pipeline: DevSecOps and Trusted Application Delivery

    Extending the GitOps Pipeline: DevSecOps and Trusted Application Delivery

    We live in a fast-paced world of rapid changes and uncertainty where every aspect of our daily lives changes often, including the way we work and communicate. Organizations must deliver value to their customers at a much faster pace than ever before to thrive in such an environment. However, the decentralized nature of cloud infrastructure expands the threat landscape and poses several security risks that enterprises should address in light of recent data breaches.

    Organizations must combat security threats and address challenges arising from cloud misconfigurations. Several recent tools, strategies, practices and technologies have emerged that can help you handle such security threats. This article discusses how the fusion of DevSecOps and trusted application delivery can extend the GitOps pipeline and add business value.

    What is GitOps?

    Coined by Weaveworks in 2017, GitOps thrives on a source code management system built on Git and adheres to the belief that Git is the single and definitive source of truth. Since all changes are stored in Git, anyone can see the audit trail if necessary. This enables you to use Git-based version control to manage your application’s code, environment and processes.

    Figure 1: CI/CD with Git-based Version Control

    GitOps leverages Git repositories as the one and only source of truth and embraces DevOps and infrastructure-as-code (IaC) best practices. Using GitOps, your developers can spend more time developing applications than configuring or maintaining Kubernetes clusters.

    GitOps strategies are gaining traction with enterprises for various reasons, including improved productivity, increased deployment frequency and improved security. While it’s true that GitOps continues to be a transformative trend, the increased speed and automation can also lead to misconfigurations that compromise application stability and security.

    Figure 2: CI/CD using GitOps

    Often, these security vulnerabilities delay development as developers spend significant time and effort investigating them. Since this poses a hindrance to progress, the question that arises is how enterprises can maintain the frequency and speed of deployment while remaining secure and reliable. This is where trusted delivery comes in.

    An Extension of DevOps

    DevOps is a software engineering practice and culture that blends development and operations to provide a shared and collaborative approach to developing and maintaining software. This can boost productivity, lower costs and increase customer value through increased collaboration.

    GitOps extends DevOps to bring the deployment workflow closer to developers. GitOps integrates code and configuration management for cloud-native application deployment and administration, while DevOps fosters shared ownership, transparency, and rapid feedback.

    GitOps uses DevOps-proven practices like version control, code review and CI/CD pipelines with any Git-based repository, including GitHub, GitLab or BitBucket. It builds on DevOps and applies DevOps best practices for infrastructure automation.

    What is Policy-as-Code?

    When deploying and managing cloud-native infrastructures, adhering to security best practices and regulatory standards is critical without hindering development. Policy-as-code is an approach to infrastructure security in which rules are codified and enforced, thereby reducing or eliminating human errors. You can use it to write applications using a high-level language to control, manage and automate policies. With policy-as-code in place, developers may create applications to manage security, compliance and other regulations seamlessly.

    Here are the types of policies that you can codify:

    • Security Policies: By adhering to these policies, you can protect your software from data breaches caused by misconfigurations.
    • Resilience Policies: The use of these policies in your Kubernetes clusters will help you create highly available, fault-tolerant systems as well as maintain business continuity.
    • Coding Standards Policies: These policies can enforce coding consistency, i.e., any code that violates these policies will be rejected automatically by the system.

    What is Trusted Application Delivery?

    Trusted delivery entails codifying security policies within your software delivery pipeline for security and compliance and introducing guardrails at every stage. By ensuring the security, integrity and reliability of your applications deployed in production environments, unauthorized access, tampering or malware introduction is minimized. It establishes and maintains trust in application source code, artifacts and deployment pipelines throughout the SDLC process.

    The key objectives of trusted application delivery are:

    • Security: It protects the application from security threats and vulnerabilities
    • Integrity: It verifies the authenticity and integrity of the source code of your application, together with the dependencies, and any artifacts
    • Reliability: It ensures that the applications deployed to the production are stable and are devoid of any security loopholes so that they can perform as desired

    Trusted application delivery helps development teams release applications early and secures them with automated protections or guardrails. It extends the GitOps pipeline by integrating security, governance and verification with policy-as-code. These security measures are implemented with policy-as-code. The policy-as-code approach encompasses the entire SDLC, including the design, development, testing and deployment stages.

    According to your organization’s security and compliance policies, compliance and security rules are codified and integrated into the system. Throughout the life cycle of your application, you can manage its security, compliance and other regulations using policy-as-code. These code-defined policies prohibit the provisioning of non-compliant resources. You should implement trusted application delivery practices to secure your organization’s application delivery process and reduce the likelihood of unauthorized access.

    Here are the key benefits of trusted delivery:

    • Faster and more frequent releases
    • Enhanced security
    • Protect against misconfigurations
    • Avoid compliance violations
    • Improved collaboration

    What is DevSecOps?

    DevSecOps is a software development methodology that blends development (Dev), security (Sec) and operations (Ops) at all phases of the SDLC by incorporating mandatory security checks. An organization of any size can benefit by creating a culture of shared responsibility and collaboration by bridging the gap between development, security and operations teams.

    A DevSecOps pipeline adds practices such as scanning, policy enforcement, static code analysis, threat intelligence and compliance validation to the SDLC process. Contrary to traditional software development processes that treat security as an afterthought leading to security vulnerabilities and breaches, DevSecOps is a paradigm shift that fosters a culture of proactive and continuous security approach to help address security concerns and vulnerabilities.

    DevSecOps and GitOps help organizations adapt quickly to changing emerging trends and requirements. DevSecOps is an offshoot of DevOps that focuses primarily on security throughout the development process. It helps detect and resolve security issues and vulnerabilities easily and quickly while fostering a culture of continuous improvement.

    Here are the benefits of DevSecOps at a glance:

    • At the outset, determine which points in the SDLC process are susceptible to security flaws and vulnerabilities in the SDLC process
    • Streamlined compliance
    • Secure supply chain
    • Reduced risk of the attack surface
    • Complete visibility of potential threats

    Why DevSecOps?

    DevSecOps is a proven way to secure your CI/CD pipelines, deliver secure, trusted, high-quality software and foster an environment where security is the responsibility of everyone in the organization. By shifting security left—i.e., introducing security into the CI/CD pipeline earlier—organizations can be much more productive and the teams can be more cooperative and collaborative.

    Given the threats to the security of the software supply chain, DevOps practices have given way to DevSecOps practices, where safety is paramount and a fundamental and ongoing component of software development. At the outset of the SDLC, you should ensure that software components and dependencies are secure to avoid potential software supply chain hazards.

    Additionally, it would help if you had built-in security gates in each step of the SDLC to ensure consistent, repeatable and automated processes from the software build phase to deployment. Remember, DevSecOps isn’t an option; instead, it is a necessity.

    Trusted Delivery With GitOps

    Automated software delivery pipelines are based on Git as the only source of truth. Policy-as-code is a great way to ensure that misconfigurations and errors are detected, alerted, and deployments halted automatically. Next, we’ll cover how a typical GitOps workflow determines where multiple checkpoints can be implemented for trusted delivery.

    In a typical workflow based on GitOps, a developer commits the source code to a Git repository. The CI tool then builds the container images. These container images are then tested and then uploaded to an image repository. At the end of this process, these container images will be deployed to a Kubernetes cluster. GitOps agents compare the current cluster state with the desired state on a continuous basis.

    Hence, you should implement security guardrails at the following points:

    • Git repository
    • CI stage
    • Configuration repository
    • Kubernetes cluster

    Creating a Trusted Software Supply Chain With DevSecOps

    You can build a trusted software supply chain by incorporating security practices throughout the SDLC to ensure the integrity and security of the software delivered by DevSecOps. Here is a step-by-step guide to building a trusted software supply chain by leveraging DevSecOps principles:

    • Security by Design: You should integrate security right from the outset of the SDLC and identify the key threats to the security of the pipeline.
    • Application Dependency Scanning: When building applications, we often use third-party dependencies to accelerate the development process. You should monitor security vulnerabilities and patches as they become available for these dependencies. You can leverage OWASP Dependency Check, Firewall from Sonatype, etc.
    • Secure Coding Practices: You should adhere to and enforce these practices among your development teams. You can integrate static code analysis tools into your DevSecOps pipeline, conduct regular code reviews and identify and fix security issues.
    • Container Security: You should scan container images regularly for security vulnerabilities, implement strategies to secure your containers and use container registries with access controls.
    • Continuous Compliance: You should ensure the software supply chain adheres to the relevant standards and guidelines for compliance requirements. In this regard, you should conduct audits regularly to check if compliance requirements have been satisfied.
    • Collaboration and Communication: You should be able to foster a culture in your organization that facilitates collaboration and communication across the development, operations and security teams.

    DevOps, DevSecOps and GitOps: The Future

    As organizations strive to optimize the efficiency of their software supply chain, DevOps, DevSecOps and GitOps are approaches that can improve collaboration, efficiency and security, to help software developers and IT operations succeed. These practices would become more critical and widely used in the future. GitOps provides teams with better tools for managing configurations so they can focus on more strategic activities.

    While GitOps is an approach that advocates Git-based version control systems as the single source of truth, DevOps is concerned about a cross-functional team that can work together. DevSecOps goes a step further by blending security into all stages of the SDLC process.

    The future of DevOps, DevSecOps and GitOps will see increased automation, tighter security integration and a sustained emphasis on efficiency and collaboration. Your organization should adopt these approaches to provide reliable software and services to its customers.

    Conclusion

    Trusted application delivery is essential for securing applications, protecting user data, meeting compliance requirements and preserving market credibility and trust. It helps enterprises and end consumers by ensuring that software is distributed securely and reliably. Organizations can ship high-quality applications with guaranteed security and performance by adopting trusted delivery practices.

  • Optimize Performance, Cut Costs With AWS Autoscaling Services

    Optimize Performance, Cut Costs With AWS Autoscaling Services

    A very easy (and free) way to get the get your money’s worth on the AWS Cloud platform is autoscaling. Autoscaling allows for better fault tolerance, better availability and better cost management, quickly scaling up and down to meet traffic demands while keeping your costs within budget by detecting and replacing the components that are not healthy enough to be present in the infrastructure.

    Some of the key benefits of autoscaling are:

    1. Meeting the traffic requirement on-demand and scaling accordingly.
    2. Adjusting scaling group capacity through the scheduled actions on the autoscaling groups.
    3. Reducing resources and costs.
    4. Increasing application availability by deploying across the availability zones.

    AWS has several services that help autoscaling the infrastructure components and reduce the management associated with scaling. They are mediated through the CloudWatch monitoring and observability service. CloudWatch provides up to 1-second visibility of metrics, 15 months of data retention (metrics) and the ability to perform calculations on metrics. This allows digital engineering teams to perform historical analysis for things such as cost optimization, for instance. On top of the specified metrics, teams can create alarms and alarm trigger the autoscaling policy to perform predefined steps, either to scale out or scale in.

    Autoscaling Services on AWS Cloud Platform

    EC2 Instance Auto Scaling

    EC2 instance autoscaling helps us to keep the correct number of EC2 instances available to handle incoming traffic requests for the application. We can create an EC2 autoscaling group, which is a collection of EC2 instances. In that group, we can specify a minimum, making sure that the group never goes below a specified size. We can also specify a maximum number of EC2 instances, which ensures that the group never goes above the specified size. This keeps capacity at a minimum and maximum range and ensures that your autoscaling group has EC2 instances specified in the desired capacity. Autoscaling also allows us to configure scheduled actions that can change the minimum, maximum and desired auto-scaling group capacity at a specified time.

    EC2 instance autoscaling allows for the configuration of scaling policies that will scale up or down according to the policy to increase or decrease EC2 instances in your infrastructure.

    There are two types of scaling: manual, in which we can attach and detach EC2 instances from the autoscaling group, and dynamic scaling, in which we can define how to scale the autoscaling group capacity in response to the incoming request or changing demand in terms of specific resource utilization. This allows us to configure policies that can take care of scale-up and scale-down and acts according to the policy for factors such as the number of requests, CPU and memory utilization.

    Below are the three types of dynamic scaling policies:

    • Target-tracking: This policy will increase or decrease the autoscaling group’s current desired capacity based on the target value for the specific metric. This policy maintains the capacity to match specified target metrics like CPU or memory utilization. Let’s assume that you have set 60% utilization of your autoscaling group—the target-tracking policy will add or remove EC2 instances to meet the specified utilization.
    • Step Scaling: This policy increases or decreases the current capacity of the autoscaling group based on a set of scaling adjustments (EC2 instances) that vary based on the size of the alarm breach. Let’s assume that the autoscaling group has three stages for tracking CPU utilization—the first alarm would be triggered when 40% is reached and would add one EC2 instance, the second alarm would be triggered when 60% is reached and two EC2 instances are added, and the third alarm is triggered when 80% is reached and three EC2 instances would be added.
    • Simple Scaling: This is a simple scaling policy option that increases or decreases the current autoscaling group capacity based on a single scaling adjustment. Here we can add one EC2 instance when specified alarm breaches.

    EC2 autoscaling provides on-demand instance scaling and spot fleet instance autoscaling, through which we can automatically increase or decrease the current capacity of the spot fleet based on the demand. It can launch (scale out) or terminate (scale in), within the specified range.

    ECS Container Service Auto Scaling

    Elastic Container Service (ECS) Auto Scaling works on published container CloudWatch metrics such as CPU and memory usage. It increases or decreases the desired capacity of container tasks in ECS service automatically. CloudWatch metrics can be used to scale out (add more tasks) to handle a high degree of incoming requests and scale in (remove tasks) during low utilization.

    ECS Auto Scaling allows us to configure policies including target tracking, step scaling and scheduled scaling actions.

     RDS Storage Auto Scaling

    Amazon Relational Database Services (RDS) for MariaDB, MySQL, PostgreSQL, SQL Server and Oracle support storage autoscaling, with zero-downtime RDS storage autoscaling automatically to scale the backend storage volume attached to the RDS database in response to growing database size.

    RDS monitors current storage consumption and scales storage capacity up when current consumption reaches near the actual provisioned size, without affecting current database operation and disturbing current database transections.

    Aurora Auto Scaling

    AWS Aurora autoscaling adjusts the number of Aurora replicas dynamically. You can define the scaling policy and Aurora acts accordingly. It scales Aurora replicas to handle a sudden increase in the database connectivity or the workload. As and when database connections or workload decreases, Aurora Auto Scaling removes unwanted Aurora replicas automatically, so customers are not charged for the unwanted replica instances.

    Just as we were able to define scaling policies in other services, so we can define them in Aurora Auto Scaling, and it also allows us to configure the minimum and the maximum number of Aurora replicas that can be managed. Aurora Auto Scaling is available for both of the Aurora engines MySQL and PostgreSQL.

    DynamoDB Auto Scaling

    The most difficult part of the DynamoDB workload is to predict the read and write capacity units. If an application needs high throughput for a specific period, it is not necessary to overprovision capacity units for the entire time. Amazon DynamoDB Auto Scaling dynamically adjusts provisioned throughput capacity on your behalf in response to actual incoming traffic request patterns.

    As and when the workload decreases, application autoscaling decreases the provisioned throughput capacity units, so that customers do not pay for any unnecessary capacity.

    With DynamoDB Auto Scaling, we can create scaling policies on the table or global secondary index. We can specify within the scaling policy whether we want to scale read capacity or write capacity (both), and the minimum and maximum provisioned capacity unit settings for the table or index.

    Prime Your Infrastructure For Autoscaling

    For these AWS autoscaling services to function as they should, organizations need to ensure they have:

    • Specified application user session state and persistence when using EC2 instances.
    • Tested, monitored and tuned their autoscaling strategy to ensure that it functions as expected.
    • Decision-making logic in place that evaluates these metrics against predefined thresholds or schedules and decides whether to scale out or scale in.
    • Service-specific limits in place before configuring autoscaling.
    • While using EC2 autoscaling, teams have specified cooldown time as well as which application to start up, and are ready to serve in a defined time.
  • Survey Surfaces Tension Between Software Speed and Quality

    Survey Surfaces Tension Between Software Speed and Quality

    A survey of 600 software professionals at organizations with more than 1,000 employees published today by OverOps, a provider of software analytics tools, finds the need to ensure quality still trumps the need for speed within most organizations.

    According to the survey results, 70% of respondents say quality is their paramount concern and they would rather delay a product road map than risk a critical error impacting their users. More than half of the survey respondents (53%) said they encounter such critical or customer-impacting issues in production at least one or more times a month. Two out of three survey participants report spending at least a day per week troubleshooting issues in their code, with 30% spending anywhere from two days to a full week.

    Nevertheless, organizations continue to invest DevOps (58%) to accelerate application development. Among those organizations, continuous integration (54%) and continuous delivery (42%) platforms were the top priority.

    Other areas of investment include microservices/containers (45%), static analysis (37%) and dynamic code analysis (27%).

    Nearly half of respondents (45%) said pressure to move fast was one of their top software quality challenges. More than half of respondents (59%) said they release new code/features anywhere from bi-weekly to multiple times a day.

    Despite investments in DevOps, however, a quarter of participants also said that over 40% of critical production issues are first reported by end users or customers rather than internal systems.

    OverOps CTO Tal Weiss said the survey makes it clear there needs to be more focus on software quality. The challenge organizations face is finding a way to achieve that goal while still accelerating the rate at which code is delivered. Too many organizations are measuring the lines of code delivered without taking into account how often they run into issues in production environments because of the quality of the code deployed.

    Of course, whenever a project falls behind one of the first places any organization looks to make up ground is by reducing the amount of time allocated to testing. However, many organizations are also integrating testing within CI/CD platforms to make sure critical testing processes are not skipped in the name of making a deadline.

    It’s not clear whether software being deployed today is any higher or lower in quality than software developed using legacy waterfall approaches. As long as humans write code, there will always be issues. Proponents of DevOps will argue that deploying smaller amounts of code more frequently helps mitigate that issue. If errors are discovered, it’s easier for DevOps teams to not only roll back that smaller update but also more quickly discover the source of any issue. Sometimes that issue may have more to do with the platform the code is being deployed on than the code itself.

    Regardless of the approach to developing software, there is clearly more at stake than ever. As organizations embrace digital business transformation the quality of any software update can have a major impact on the business. The challenge is first eliminating as many of those disruptions as possible and then, secondly, minimizing their potential impact on the business as quickly as possible.

  • Report: Software Delivery Slowed During Pandemic

    Report: Software Delivery Slowed During Pandemic

    A survey of more than 500 IT and development professionals conducted by Atlassian finds two-thirds of respondents have slowed down the frequency of software delivery since the advent of the COVID-19 pandemic.

    Patrick Hill, head of reliability process at Atlassian, said while developers may be creating more code than ever while they work from home, IT operations teams working from home are struggling to keep pace.

    In fact, the survey finds more than half of respondents (51%) reported incident response times have been slower since they began working remotely. At the same time, there’s been a 73% increase in demand for the digital services being provided, the survey finds.

    It’s too early to say to what degree slowing down the application delivery process might be a byproduct of the “new normal.” It’s more likely that IT operations teams need more time to re-engineer processes to return to the software release levels typically achieved prior to the pandemic, said Hill.

    In many cases, IT teams may also need more time to shift toward cloud-based frameworks for managing application release cycles that can be accessed from anywhere. Hill said Atlassian has seen a significant increase in the use of its IT management platforms since March. New signups have increased by approximately 125%, he noted.

    It’s also unclear to what degree an application release backlog may be building inside organizations. While developers may be launching more projects, Hill said many of those projects may be only to address bug fixes. As such, it may not take that long for IT operations teams to recover from the disruption caused by the pandemic.

    Nevertheless, Hill said most organizations are still coming to terms with the human impact of the pandemic. Many organizations, for example, might not decide to bring IT teams back into the office at all. In fact, there may not be any office to return to—many organizations might conclude there is no need, especially if productivity levels have not declined substantially. No doubt many organizations consequently will be closely monitoring application release cycles in the weeks and months ahead to determine to what impact working from home is having on IT productivity.

    Of course, not every member of the IT team is cut out to work from home. While many IT professionals may be introverts by nature, there are also a great many distractions at home that adversely impact productivity. Conversely, some IT professionals might even discover they have begun to work longer hours.

    In the meantime, Hill said IT managers would be well-advised to focus more on outcomes than metrics. The amount of code being released in a given week is not likely to be as important as making sure the right code is being released at the right time. With more demand than ever for application services, the greater the need there is for DevOps teams to focus their efforts on the components of an application that make the most critical difference to the business.

  • Launchable Aims To Improve Delivery Velocity, With Kohsuke Kawaguchi and Harpreet Singh

    Launchable Aims To Improve Delivery Velocity, With Kohsuke Kawaguchi and Harpreet Singh

    A new company, Launchable, aims to improve your delivery velocity by helping you be much smarter about which tests you run and when. By applying machine learning (ML) and better use of the data output by your software development work, the two co-founders think they can make a meaningful impact on development efforts.

    Sure, you say, lots of developers say they can change the world. But in this case, the co-founders have some very impressive résumés to give you confidence they just may do it. The dynamic duo is none other than Harpreet Singh, former GM of Atlassian BitBucket and VP of Product and Design at CloudBees, and the one and only Kohsuke Kawaguchi, founder of Jenkins and CloudBees Chief Scientist, most recently.

    Wait a second, you may be asking, you’re saying KK from Jenkins/CloudBees has started a new company? Yes, that’s what I am saying. In a podcast that will be available very soon, KK and Harpreet talk with us about Launchable’s why—and why now. Stay tuned for that.

    It’s worth noting that KK has been at CloudBees for 10 years and working on Jenkins for 15 years. In the tech business, that is nearly a lifetime. During our podcast, KK said he felt that with Jenkins being passed to the Continuous Delivery Foundation (CDF), coupled with a healthy group of leaders within the Jenkins community, now was a good time to move on to the next adventure.

    Beyond Jenkins, CloudBees has grown into its own next phase, with lots of exciting developments announced and more coming. The scientist in KK has led him to explore solutions to problems he sees in the way so many companies are doing development. His longtime friendship with Harpreet, dating back to their days at Sun, has energized them both to once again work together and tackle the real problems that development teams are facing.

    What will come out of Launchable? I don’t know. But the company has already attracted some blue-chip VC investment, as well as an impressive list of angels including Sacha Labourey, CEO and founder of CloudBees.

    They (like everyone else, it seems) are hiring development engineers and data scientists. So if working with KK is something that appeals to you, head over to the Launchable site and check out the Careers section.

    I am sure we will be hearing more about Launchable in the days, weeks and months ahead. In the meantime, best of luck to Harpreet and KK, and many thanks for a job well done with Jenkins.

    — Alan Shimel

  • Should Your Company Use DBaaS?

    Should Your Company Use DBaaS?

    From SaaS to IaaS, companies are rapidly moving to the cloud to gain huge agility and cost benefits. So, is it time for your company to take advantage of database as a service (DBaaS)? Here’s a high-level discussion to help you along your decision path.

    First, it’s important to distinguish DBaaS from simply running a database on a cloud-based server, such as Amazon AWS or Microsoft Azure. While you can certainly gain some cost and agility benefits from running your database on a virtual machine, you’ll still need to provision and maintain the database, that is, you will need server operations expertise.

    With DBaaS, the cloud provider also provisions and maintains the database, eliminating the need for your organization to maintain server operations expertise in-house. DBaaS manages the entire environment—physical and virtual hardware, operating system, networking, replication configuration, etc.—so you can stay focused on software development. With the click of a button you can set up the database and then connect your application with a simple API call. And you’re ready to go.

    The speed and cost advantages of this approach can be huge, but there are also some limitations, so it’s important to assess whether your company’s resources and your project’s requirements align with the current capabilities of the various DBaaS offerings.

    Reasons to Use DBaaS

    Lack of Expertise: As suggested above, if your technical team is mainly composed of software developers who won’t be able to manage the complexity of provisioning a database, you should consider DBaaS. In addition to handling the management of the database, the DBaaS provider will offer additional services, such as automatic backups of your data. In this worry-free environment, you can focus on optimizing your software instead of constantly worrying if the database is functioning properly.

    Short-Lived Databases: If you need databases to serve as back ends for continuous integration testing, DBaaS will allow you to rapidly provision the databases, populate them with test data and then delete them when they are no longer needed. Having the database provisioned for you makes it far faster and simpler to build the required automation for the testing environment.

    A Microservices Design: DBaaS can be particularly helpful, even in a production environment, if you are using a microservices design composed of a very large number of databases. Even if you have the internal expertise, you may not want to invest the time and effort in deploying all those databases. DBaaS can get you into production significantly faster.

    Reasons Not to Use DBaaS

    While the above benefits are appealing, you likely won’t want to use DBaaS in the following scenarios.

    Database-Centric Applications with Complex Topologies: To ensure ease of deployment, DBaaS providers limit the ability to deploy complex environment topologies. This reduces the flexibility DBaaS customers have. For example, let’s say that for disaster recovery, you have a primary synchronous replication cluster in one region and a secondary synchronous replication cluster in a different region, with an asynchronous relationship between them. This relatively complex topology is outside the scope of most DBaaS offerings.

    IO-Bound Workloads: If your database has IO-bound workloads, you may need very powerful hardware, including high-end CPUs, terabytes of memory and very fast storage. In this case, you may not find a DBaaS provider that offers a configuration that will meet your needs.

    Understand Your Options

    If your database requirements align with the capabilities of DBaaS, you now have the ability to eliminate significant operational complexity and develop, test and deliver your applications faster and at a lower total cost. However, make sure you spend time carefully investigating today’s DBaaS offerings, including Amazon RDS, Google Cloud SQL and Azure SQL Database, which all have different features and focus, including deployment models, performance trade-offs, instance types and more.

    If your needs don’t fit current DBaaS offerings, you’ll need to provision your databases yourself. If you don’t have the expertise in-house and can’t afford new hires, a database consultant may be a cost-effective strategy for getting the support you need.

    — Tyler Duzan

  • How App Stores Are Addressing Fragmentation in the Linux Ecosystem

    How App Stores Are Addressing Fragmentation in the Linux Ecosystem

    According to DistroWatch, 273 Linux distributions are currently active, with another 56 dormant and 521 discontinued. While some of these have shared underpinnings, it still makes for an extremely varied landscape for companies and developers.

    It means developers must create multiple versions of their applications to be able to provide their software to all Linux users or just address a fraction of the market. Also, developers require multiple versions of build tools, which inevitably results in significant resource overhead.

    Desktop application distribution is complex across all operating systems in general; in Linux, this is further compounded by such fragmentation and inter-dependencies both in the packaging and distribution of software.

    For example, Fedora uses the RPM packaging format, while Debian uses the .deb format. Moreover, packages built for one version of a Linux distribution are often incompatible with other versions of the same distribution and need to be built for each version separately.

    Developers need to satisfy all these requirements at the same time to be able to successfully offer their products to their users, which can be difficult with limited resources.

    In a way, the choice of distribution and subsequent promotion of Linux software is a chicken-and-egg problem. Initially, companies and developers must decide what parts of the Linux desktop system they want to target. Then, once they have their products available to end users through one or more of the distribution channels, they still have to invest in separate efforts to promote their applications and capture usage.

    Unfortunately, there is insufficient data to assist in the selection and optimization of either the distribution or the promotion process. Linux software developers generally lack sufficient immediate visibility to the usage and popularity of their software.

    Traditionally, there have been multiple dimensions to how creators distribute their software: official websites, where companies and developers offer software downloads on their own domains; code repositories such as GitHub, GitLab and SourceForge; and application repositories in which Linux-based operating systems typically provide software through self-hosted storage locations.

    To achieve the highest level of penetration, software developers will often distribute their applications using some or all of the above methods. Likewise, most users will utilize multiple methods to obtain software they need. While this gives developers more freedom in how they deliver applications to the end-users, it creates additional fragmentation.

    In recent years, there has been significant effort to address the fragmentation in packaging and simplify the distribution of software through the establishment of software centers, in which some Linux distributions offer store-like destinations with a graphical frontend, software ratings, screenshots, descriptions and other user-focused data that allows better search and discovery.

    Currently, there are three of these in the Linux space—AppImage, Flatpak and snaps. They each approach and handle the various aspects of usability in different ways.

    AppImage and Flatpak technologies are architected to primarily support GUI desktop applications. Snaps are designed to work with servers, cloud infrastructure and IoT devices, in addition to desktop applications.

    Spotify, a snaps publisher, is an example of a company benefiting from this approach. On one hand, it requires the Spotify engineering team to maintain both the snap and the traditional Deb package. On the other, the snap version is significantly easier to release, which has also helped with the simplification of the Deb release, as well.

    The primary reason is the ability to use easy rollbacks, which have already been used. This feature removes uncertainty that a possibly broken version of the Linux desktop client application might be pushed out to the users. Spotify engineers first release the snap version, and after ascertaining that it works and behaves correctly, they build the Debian package, too. Snaps allows the Spotify team to more closely follow the weekly cadence of releases they have for the Windows and Mac versions.

    The emergence of self-contained packaging and distribution mechanisms addresses a major problem in the Linux application ecosystem–the difficulty in establishing a successful business model because of the packaging and distribution challenges. The new formats reduce the fragmentation, as they minimize the number of permutations developers need to support for their applications.

    The shift toward centralized application stores that are not specific to any particular Linux distribution offers higher discoverability and better consistency in the user experience.

    Developers need fewer resources to support multiple target platforms, which allows them to focus their efforts on the core product, with the understanding their software will be available to the wider desktop audience, without having to depend on distribution-specific dependencies.

    Since the aspects of new, refined models of promotion and distribution in Linux are still relatively young, we see improvements but there is still opportunity to develop and adopt better, data-driven practices.

    As this field continues to evolve, the store model will help drive growth and usage of the Linux desktop, offering software developers a refined, more tangible experience than ever before.

    — Martin Wimpress

  • What Quality Metrics Matter Most for DevOps?

    What Quality Metrics Matter Most for DevOps?

    The way we develop and deliver software has changed dramatically in the past five years—but the metrics we use to measure quality remain largely the same. Despite seismic shifts in business expectations, development methodologies, system architectures and team structures, most organizations still rely on quality metrics that were designed for a much different era.

    Every other aspect of application delivery has been scrutinized and optimized as we transform our processes for DevOps. Why not put quality metrics under the microscope as well?

    Are metrics such as number of automated tests, test case coverage and pass/fail rate important in the context of DevOps, where the goal is immediate insight into whether a given release candidate has an acceptable level of risk? What other metrics can help us ensure that the steady stream of updates don’t undermine the very user experience we’re working so hard to enhance?

    To provide the DevOps community an objective perspective on what quality metrics are most critical for DevOps success, Tricentis commissioned Forrester to research the topic. The results are published in a new eBook, “Forrester Research on DevOps Quality Metrics that Matter: 75 Common Metrics—Ranked by Industry Experts.”

    The goal was to analyze how DevOps leaders measured and valued 75 quality metrics (selected by Forrester), then identify which metrics matter most for DevOps success. Here’s a look at the process:

    1. Survey 603 global enterprise leaders responsible for their firms’ DevOps strategies.
    2. From that sample, identify the firms with mature and successful DevOps adoptions (157 met Forrester’s criteria for this distinction).
    3. Learn what quality metrics those experts actually measure and how valuable they rate each metric they regularly measure.
    4. Use those findings to rate and rank each metric’s usage (how often experts use the metric) and value (how highly experts value the metric).
    5. Compare the DevOps experts’ quality metric usage versus that of DevOps laggards. If there was a significant discrepancy, the metric is considered a DevOps differentiator.

    The 75 DevOps quality metrics were divided into four categories:

    • Build
    • Functional validation
    • Integration testing
    • End-to-end regression testing

    For each category of quality metrics, we came up with a heat map showing usage versus value rankings. For example, here is the heat map for the Build category metrics.

    We also plotted the data for each metric into a quadrant with four sections:

    • Value Added: Metrics that are used frequently by DevOps experts and consistently rated as valuable by the organizations that measure them.
    • Hidden Gem: Metrics that are not used frequently by DevOps experts but are consistently rated as valuable by the organizations that measure them.
    • Overrated: Metrics that are used frequently by DevOps experts but not rated as valuable by the organizations that measure them.
    • Distraction: Metrics that are not used frequently by DevOps experts and not rated as valuable by the organizations that measure them.

    For example, here is the quadrant for Build category metrics:

    The eBook provides both heat maps and quadrants for all four categories, a quick look at each of the 75 metrics per-category and overall analyses, as well as a few fun lists.

    Here’s a preview:

    Hidden Gems

    The following metrics are not commonly used (even among DevOps experts), but are ranked as extremely valuable by the select teams who actually measure them:

    1. New defects (IT)
    2. Critical defects (FV)
    3. Automated tests prioritized by risk (Build)
    4. Code coverage (Build)
    5. Test cases executed (Build)
    6. Static analysis results (Build)
    7. Variance from baselines of percent of test cases passed (E2E)
    8. Release readiness (E2E)

    Top DevOps Differentiators

    DevOps experts/leaders measure the following metrics significantly more than DevOps laggards measure them:

    1. Automated tests prioritized by risk (Build)
    2. Percent of automated E2E test cases (E2E)
    3. Risk coverage (IT)
    4. Release readiness (FV, IT, E2E)
    5. Test efficiency (FV and IT)
    6. Requirements covered by tests (Build, FV, IT, E2E)
    7. Test case coverage (Build, E2E)
    8. Static analysis results (Build)
    9. Variance from baseline of percent of test cases passed (E2E)
    10. Test effectiveness (FV, IT, E2E)

    Most Used by DevOps Experts

    The following metrics are the most frequently used (overall) by DevOps experts/leaders:

    1. Test case coverage (E2E)
    2. Pass/fail rate (FV)
    3. API pass/fail rate (IT)
    4. Number of tests executed (E2E)
    5. API bug density (IT)
    6. Requirements covered by tests (FV)
    7. Requirements covered by tests (E2E)
    8. Blocked test cases (FV)
    9. Percent of automated E2E test cases (E2E)
    10. Successful code builds (build)

    Most Valued by DevOps Experts

    The following metrics are the most highly valued (overall) by DevOps experts/leaders:

    1. Requirements covered by API tests (IT)
    2. Percent of automated E2E tests (E2E)
    3. Requirements covered by tests (E2E)
    4. Requirements covered by tests (FV)
    5. Count of critical functional defects (FV)
    6. Total number of defects discovered in test (E2E)
    7. Number of test cases executed (E2E)
    8. Pass fail rate (FV)
    9. New API defects found (IT)
    10. Automated tests prioritized by risk (build)

    — Cynthia Dunlop

  • Panaya Offers Best-In-Class Integrations to Better Support Modern Software Development and Delivery

    Support for over 150 leading industry tools and services adds essential visibility and reporting capabilities to its Enterprise Agile Delivery Platform

    Hackensack, NJ – October 16, 2018 – Panaya, the leader in SaaS-based testing and continuous delivery, today announced the integration of over 150 leading application development and delivery tools and services into Panaya Release Dynamix (RDx), its Enterprise Agile Delivery (EAD) platform. Users can now take advantage of the tools they already employ every day to increase visibility, collaboration and communication among all stakeholders – the business, development, operations and test teams. With these new RDx integrations, organizations can now deliver application changes from ideation to realization in one unified platform.

    Digital transformation requires enterprises to adopt a continuous delivery model where release cadences are measured in days, not quarters, and quality is guaranteed. To get there, organizations need to apply agile methodologies, but are often limited by existing tools and technologies that create siloed work environments. These best-in-class integrations now offered by Panaya include many of the leading applications for software delivery, such as Jira, ServiceNow, Tricentis Tosca, CA Rally, Bugzilla, Salesforce and more, allowing Panaya’s RDx and Panaya’s test acceleration platform, Panaya Test Dynamix, to fully support continuous integration and continuous delivery.

    The new RDx integrations offer end-to-end visibility and connect the fragmented delivery tool chain to better address the risks associated with business-critical application delivery. From initial business change requests to testing and production, these RDx integrations ensure application development and delivery, project management and business teams can continue to leverage the tools they choose with greater visibility into where items are on the delivery pipeline, while delivering on time and without sacrificing quality. Additionally, open channels and better alignment with business objectives and requirements allows application development and delivery teams to gain a better understanding of the value of each delivery.

    “The pace of delivery in today’s development ecosystems is daunting, and delivering quality releases is hampered by a truly fragmented toolchain ecosystem. There is a plethora of solutions and tools in use today, and rather than force users into yet another solution and cause even more multiplicity, we opened the door to allow customers to use what they already have, seamlessly with Panaya Release Dynamix,” said Jake Klein, CEO of Panaya. “This is what Panaya’s Enterprise Agile Delivery is all about, ensuring all stakeholders involved in the business process have the tools they need in a single, holistic platform that proves the business value faster by managing changing priorities, all while juggling shorter release cycles to meet the continuously evolving needs of the business.”

    These new integrations also cover the gaps left from one tool to another, such as development teams needing to manually provide dev execution and backlog data since there is no visibility between the disparate tools. With extended visibility, IT teams and business managers can make more informed decisions and achieve greater business agility through collaboration.

    Panaya RDx provides a holistic and integrated environment that enables collaboration with all stakeholders involved in the business process, and the visualization, management and risk assessment of application delivery and value streams, while monitoring investment buckets to ensure strategic alignment. By providing real-time insight into risk and quality, corrective actions can be automatically generated, allowing for safe allocation relief and the continual flow of value. Panaya RDx also offers complete visibility of the entire delivery pipeline, so users can save time without having to sacrifice quality.

    Since 2008, over 2,000 companies in 62 countries, including a third of the Fortune 500, have used Panaya to delivery quick quality change to enterprise applications. Customers are from a variety of sectors including automotive, pharmaceutical, retail, manufacturing and more.

    For more information on available integration within the Panaya Enterprise Agile Delivery platform, visit www.panaya.com/agile-delivery/integrations.

    About Panaya

    Panaya, an Infosys company, enables organizations to accelerate application change and continuously deliver innovation with its Enterprise Agile Delivery Platform. Panaya provides cloud-based application delivery, and testing solutions that ensure collaboration between Business and IT. Enabling enterprise agility with faster release velocity and uncompromising quality, Panaya delivers an optimized user experience with end-to-end visibility of the application lifecycle. Since 2008, 2,000 companies in 62 countries, including a third of the Fortune 500, have been using Panaya to deliver quick quality change to enterprise applications.