Tag: test data management

  • Platform Engineering: The 2024 Game-Changer in Tech

    Platform Engineering: The 2024 Game-Changer in Tech

    Platform engineering, a key driver in the ever-evolving technological landscape, is poised for significant momentum in 2024. This article explores the reasons behind its rising popularity, the types of organizations that stand to benefit, potential drawbacks and the crucial role of test data management (TDM) in this context.

    What’s Driving Demand for Platform Engineering?

    Platform engineering is anticipated to gain significant momentum in 2024 as it offers crucial advantages in accelerating business value, reducing cognitive loads and enhancing the efficiency of application development and management processes. According to Gartner, by 2026, about 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery. This trend underscores the increasing adoption and importance of platform engineering in the tech world.

    The growing popularity of platform engineering can be attributed to several factors:

    • Developer productivity: Enhancing developer productivity is a key driver, accounting for approximately 21% of the reasons for its popularity.
    • CI/CD pipeline implementation: About 20% of the popularity is driven by the need for efficient continuous integration and continuous delivery pipelines.
    • Standardization of tools and processes: Another 20% comes from the necessity to standardize tools and processes.
    • Security enhancements: Security improvements contribute 20% to its popularity.
    • Infrastructure-as-code (IaC): Finally, 19% is driven by the adoption of infrastructure-as-code (IaC) methodologies.

    In addition, platform engineering addresses the inefficiencies caused by the decentralization of tools and processes in DevOps, especially as organizations scale. This approach provides a more organized and centralized framework, which is essential in managing the complexities of modern software development environments.

    As highlighted by Gartner, platform engineering’s potential to offer a frictionless self-service experience to customers and business partners is a significant factor in its rising popularity. This adaptability is crucial in an era where technology and market demands are rapidly evolving, requiring businesses to remain agile and competitive.

    These factors collectively make platform engineering a strategic approach for software engineering organizations, particularly looking forward to the year 2024 and beyond.

    platform engineering, TDM

    Key Benefits of Platform Engineering

    While it isn’t a fit for every organization, there are some shared attributes of companies that are most likely to benefit from it.

    If your organization is seeking to:

    • Reduce tool sprawl by standardizing tools and services
    • Improve productivity through automation, leading to faster development cycles
    • Establish governance frameworks for software development
    • Increase scalability through technologies like containerization and orchestration
    • Enhance security by integrating automated security scanning tools into the CI/CD pipeline,

    then platform engineering may be right for you. These benefits are especially relevant for businesses facing complex software development cycles and those in need of robust, scalable, and secure solutions.

    Drawbacks of Platform Engineering

    However, platform engineering is not without its challenges. Increased complexity in infrastructure can be daunting for small-scale teams. High dependency on the platform may lead to difficulties in switching technologies or providers. Additionally, compatibility issues with existing development tools and technologies can slow down processes.

    The Crucial Role of Test Data Management (TDM)

    In a platform engineering environment, test data management (TDM) becomes a pivotal component. TDM’s importance lies in its role in agile development, ensuring test accuracy and reliability, thus enhancing the effectiveness of the testing process. Agile methodologies, which divide projects into smaller sprints, rely heavily on TDM for providing high-quality, compliant test data in a continuous integration and deployment model.

    TDM addresses the challenge of managing data fragmented across various applications, environments and compliance levels. An entity-based TDM approach enables testers to provision test data on demand, streamlining the testing process and reducing the risk of data breaches. Ultimately, TDM practices significantly reduce time, cost, and risk in software delivery, making it a vital component in modern platform engineering strategies.

    As technology continues to evolve rapidly, the role of platform engineering, bolstered by effective TDM, becomes increasingly crucial. Companies that do not adapt to these changes by integrating components like TDM into their platform engineering strategies will risk falling behind in the competitive tech market. Therefore, embracing these innovations is essential for survival and success in today’s fast-paced technological landscape.

  • Database Virtualization – Driving the Next Big Transformation

    Database Virtualization – Driving the Next Big Transformation

    Data is both the most important asset and the biggest challenge for most corporations. It impacts every aspect of the business from financial considerations to AI/ML training. Data is used by development and DevOps teams, engineering teams, quality assurance, business intelligence teams and database administrators. Despite its central role in operations, traditional forms of database delivery remain complex, costly and time-consuming.

    In many cases, enterprise data is growing exponentially, increasing management challenges and driving up the cost of data storage. Duplicating data to each new environment as use cases arise is overwhelming DBA teams and incurring a significant storage footprint. This has resulted in data becoming a significant bottleneck for DevOps teams, highlighting the importance of finding a quick and automated solution for the replication process across non-production environments.

    What’s Changed?

    In the past, development teams would work with the same dataset for upwards of six months. This left DBA teams with plenty of time to meet all database delivery needs. However, as technology became more sophisticated and consumers grew more demanding, the data delivery life cycle was cut down dramatically. Today, with agile development, new features may be added every few days, if not hours. Coupled with QA teams’ requirement for testing data continuously, AI/ML teams requiring millions of data points for accurate training, and data analysts constantly needing fresh data for organizational growth, this means DBA teams are flooded with demands they are incapable of managing.

    What Now?

    Database virtualization is an automated and easy solution to the dataset bottleneck. By simplifying the creation and distribution of database replicas, DevOps teams will be able to create fully functioning virtual environments via a self-service process–allowing DBA teams to focus on more critical duties relating to production databases.

    Speed Up

    The first—and most obvious—advantage of this approach is the increased speed at which data is delivered. To keep DevOps teams productive and avoid the use of old, stale data, new environments need to be produced on demand. By integrating the production of new environments into the CI/CD pipeline, enterprises will be able to automate the process and provide DevOps teams with full autonomy. By cutting out the dependency on the DBA, teams will be able to access the data they need, when they need it.

    Scale

    Agility is fundamental to the success of database management. Each team requires an independent environment, unaffected by other use cases. The creation and supply of virtual databases allow for quick provisioning. Once created, these databases look identical to the original physical database and function completely independently of each other. Any changes made to a vDB remain unique to the environment it’s in.

    Save

    As the need for data grows, so does the cost of storage. Creating a physical copy for each team and use case results in a significant storage footprint. This means that these datasets come with a hefty cost. However, the creation of virtual databases led to a dramatic decrease in storage needs. Where traditionally, physical datasets can weigh upward of several TB, vDBs only weigh a few hundred megabytes. Further, virtualization solutions also compress the weight of physical copies – such as the golden copy – actively decreasing the weight and cost of storage across all fields.

    Secure the Database

    Even after the database delivery problem has been solved, enterprises are faced with another major issue – security. With so many different teams accessing data in virtual and low-level testing environments, the risk of ransomware and other cyberattacks increases dramatically. Generally, the investment in securing non-production environments is significantly weaker than in production.

    A common approach to address this issue is masking sensitive data so it is rendered useless to outside sources. However, traditional masking requires a data expert to manually sift through all existing data and implement data masking algorithms on any sensitive information found. This time-consuming solution creates a new data bottleneck. By automating the process and applying it to the golden copy, corporations can be confident that all vDBs created are completely secure and privacy compliant.

    Looking Ahead

    Database virtualization is the future of database replica management. Virtual databases are delivered in a matter of minutes, significantly accelerating the speed of delivery. These environments are easy to use, independent, and can be maintained via a self-service portal. The ongoing sync between the original database and the vDB ensures continuous access to the latest data without the need for timely or expensive processes.

    Effective database virtualization will allow well-established enterprises to more easily compete against those agile startups that face significantly fewer barriers to entry.

    Image Source: joshua-sortino-LqKhnDzSF-8-unsplash

  • Automation Killed QA – It’s Time to Deal With It

    Automation Killed QA – It’s Time to Deal With It

    Quality assurance (QA) had a good run.

    From the time it was considered an afterthought by organizations and software vendors alike to the era of massive outsourcing contracts, followed by significant vendor investments in related tooling, and, finally, its recognition as a critical success factor among high-performing organizations, quality has evolved to become even more important than functionality to end users.

    Customer experience, today, is defined by speed and quality above all else. Namely, can I access the information and products that I want in the blink of an eye and get expected feedback based on input? As a result, customer experience has also shifted: It’s all about application experience, not the friendliness of a checkout cashier or sales/service rep.

    With this massive shift toward customer experience platforms (think omni-channel) and increasingly lofty expectations, the operative question becomes, How are we enabling velocity in our testing practices to ensure the highest quality while keeping up?

    We’ve tried everything from outsourcing to insourcing, investing in tooling, investing in people and even building testing architecture teams to oversee the automation, quality and consistency of testing results. Roughly seven years ago, my top priority for testing teams was to automate 30 percent of our tests. Today, if you are not 100 percent automated, or close to it, you are severely lagging in output.

    But what’s next? What if I’ve automated all of my tests and my manual testers have been replaced with automation engineers, but I’m still having quality issues and being perceived as a bottleneck?

    The answer is simple. Automate everything.

    Makes sense, right? Isn’t everyone telling you that? But what are we defining as “everything” from a testing perspective? Therein lies the problem; we are thinking about testing as its own factory within the larger software development life cycle.

    While we believe we are changing this perception by going agile and moving most QA functions into scrum teams, the reality is we still look at testing as a standalone function. Centralized or decentralized, this is the case, and we need to think differently.

    Automating for quality begins with defining requirements. How am I ensuring that I’m covering all cases? How do I ensure I’m translating the business requirements properly? These questions, the time it takes to answer them and the risk of human miscalculation all impact quality and velocity.

    We must start our automation for quality at the beginning, during establishment of business requirements.

    Let me introduce you to next-generation QA. Intelligent “continuous testing” platforms are replacing humans for testing, automating tests, creating data and building test cases. These platforms are able to translate model-based business requirements into complete automation—test cases, test data and test script automation.

    Orchestration across your software development life cycle creates your environments, lays down your test data, deploys your software, runs your test scripts and reports results. No more human error, no costly resources and guaranteed test coverage that ensures quality.

    Integrating your existing automation around continuous integration, portfolio management reporting, and execution reporting to this framework now gives you the ability to report and automate your ideas all the way through to outcomes.

    Early adopters are already doing this. QA as a functional organization is gone. If you aren’t already automating to this end, you are severely behind.

    Questions?  Comments?  Perspective?  Have at it in the comments below.

    — Ron DeCanio

  • The ‘Continuous’ Illusion

    The ‘Continuous’ Illusion

    Continuous delivery is an illusion. That doesn’t make it insubstantial—illusions can have a tremendous impact. Like the first motion picture: the locomotive felt so real to first audiences that they fell from their chairs, screaming. But of course, the locomotive was an illusion, merely rushing past on screen.

    A good magician, like a good inventor, will tell you that the secret to a powerful illusion is hard work on top of a good idea. Indeed, good magicians and inspired technologists have a lot in common. Each is always on the hunt for the next big insight, the transformative angle, building on existing industry techniques to create something even greater. But each knows the secret to truly wowing their audience, whether for a one-night-only show, or an ongoing relationship. What really gets the job done is the vast, complicated, hard-won machinery ticking away behind the scenes.

    Today’s No. 1 magic trick for making great applications, a directive now pervasive across every industry, is continuous delivery. Right now, continuous delivery provides that wow. It takes app updates from a customer stumbling block to a seamless benefit. It takes feature delivery from “maybe in a year” to “is tomorrow soon enough?” It allows Dev teams to wave their magic wands and transform the impossible into the effortless.

    And, of course, continuous delivery is an illusion. Remember that movie locomotive, leaping out of the screen? Every instant of its motion was its own little frame of celluloid. And the true magic was the process that bound each and every frame together, delivering them onto the screen with perfect timing.

    Continuous delivery is the very same sort of illusion. The steady stream of new features, new capabilities and bug fixes must be created one by one by a vast army of talented developers—not unlike the thousands of talented stencilers who first brought color to motion pictures. And the true heart of the process is the automated systems that support this army, and which ensure the coordinated delivery of its products to the end user.

    The heart of continuous delivery is the machinery of automated testing and deployment. The approach behind continuous delivery encourages teams to produce software in short cycles, ensuring that the software can be reliably released at any time. For these releases to be reliable, continuous testing is integrated into the software delivery pipeline, for immediate feedback on any bugs an update would generate. Then, when a proposed change has passed the automated tests, it is deployed to production automatically. This software development life cycle (SDLC) allows companies to achieve the business goal of truly responsive development. The team sees an opportunity, confirms the solution and then delivers that solution to customers extremely rapidly.

    Each stage of continuous delivery—develop, test, deploy—has its own technical challenges, but the testing step in particular poses a unique bottleneck.

    In the development stage, developers primarily require code. Code is relatively lightweight, and can be managed through industry-standard tools such as Github. Developers need their laptops, but in general code management poses a limited operations support challenge.

    The deployment stage can be more challenging for ops. The newest version of the code must be deployed to a wide population of final platforms, which may vary in hardware, software, location, permissions and so on. However, the target systems are at least those in ordinary use. The server the new page runs on or the smartphone that installs the application update are pre-existing systems, and they are managed by their users. So Ops teams are not required to support specialized hardware to deploy. Furthermore, in the past few years a number of innovative technologies, such as Ansible and Docker, have emerged to simplify this process further.

    Testing, on the other hand, combines the challenges of both of these stages. Continuous testing requires dedicated resources for developers and QA. But these resources are full-scale application environments, including not just code but data, operating systems and even appropriate hardware. And because best practices encourage developers to write new tests for all new code, the amount of regression testing required for every code change can only grow. That means that testing must grow ever more parallel, or suffer increasing delays—and any delay in testing can undermine overall continuous delivery.

    To preserve the Continuous Illusion, a development team needs on-demand access to scalable testing environments, including their data. Data in particular is often overlooked in test environment creation, but it must be delivered to every test instance. That means test data management (TDM) is an inescapable part of any successful continuous strategy.

    TDM is relatively self-explanatory: it refers to the process of creating, managing and delivering production (or production-like) data to non-production data environments. Every organization does some TDM, though many do not consider it a separate practice. But to achieve the sort of seamless efficiency that can support the Continuous Illusion, teams must adopt a modern TDM practice.

    Legacy TDM relies on multi-stage, manual delivery chains. Developers and testers file tickets, and then they wait. Storage admins, DBAs, backup admins, security personnel and other staff each have to spend a huge portion of their time servicing the ever-growing stream of tickets, handing off environment creation from one function to another. Meanwhile, developers and testers are left in the lurch, and continuous delivery grinds to a halt.

    Once, this process might have been unfortunate but necessary, imposed by technological restrictions. But modern solutions can tackle these challenges and overcome them. Too often, teams with poor TDM have simply neglected to implement the solutions that they need.

    The most effective TDM practices will use a data management solution on par with other continuous delivery pipeline tools. The TDM solution will be able to stand up data environments in minutes and at massively parallel scale. It will rely on production data and automatic security, rather than synthetic data generation or data subsets (both of which requires substantial upfront planning and cannot hit the full suite of edge cases). It will integrate readily with existing continuous delivery workflow tools, allowing data to be automatically provided whenever a test job runs.

    There are some solutions in the market today that meet these criteria. Adopting one can represent your opportunity to tighten test cycles and deliver code faster—regardless of how fast your software timelines are today.

    To deliver the Continuous Illusion, every component of the continuous delivery pipeline must be operating at peak efficiency. A powerful TDM solution is a key requirement for allowing your customers to sit back, relax, and enjoy the magic of your product.

    About the Author / Louis Evans

    Louis Evans HeadshotLouis Evans is a DevOps evangelist with Delphix. He’s excited about the potential for superior TDM to enhance overall software quality. He is a huge Alan Turing fan, and partial to a well-placed semicolon.