devopsy.kinsta.cloud

Tag: DevOps platform

  • Platform Reality Has a Surprising Amount of Detail

    Platform Reality Has a Surprising Amount of Detail

    Developer platforms and the platform teams that create them have been the center of attention for quite some time now. There have been many (wildly different) opinions about the subject, ranging from how bad the notion of a platform team is to how essential platforms are to make an organization’s DevOps journey to cloud native successful.

    Since early this year, the CNCF TAG App Delivery team has been working on a whitepaper about platforms. It explains what platforms are, why they are needed and how platform teams might work to create them. Furthermore, there’s an abundance of end-user talks at conferences that show how platform teams and their platforms were essential in enabling developers at scale. Even on the KubeCon + CloudNativeCon keynote stage, we’ve seen success stories of platform teams like the one at Mercedes Benz.

    Developer Platforms Should Enable Developers

    There is no silver bullet to successful platform teams and platforms. However, it is important to understand that the main goal of a developer platform is to enable developers. It is essential for platform teams to focus on delivering that value, which is why we are seeing a trend to introduce actual product ownership and product management roles to platform teams.

    The CNCF whitepaper stated that the three core jobs of a platform team as follows:

    1. Research platform user requirements and plan a feature roadmap.
    2. Market, evangelize and advocate for the platform’s proposed values.
    3. Manage and develop interfaces for using and observing capabilities and services including portals, APIs, documentation and templates and CLI tools.

    I couldn’t agree more. But the reality of day-to-day business for many platform teams means they rarely get to focus on those three jobs.

    Reality Has Detail

    The situation reminded me of a blog post I read a few years ago, titled “Reality has a surprising amount of detail.” The author explained how it is easy for people to get stuck even when faced with a task that might look simple from the outside. They explain how a task as simple as building wooden stairs can, in its many subtasks, become quite complex. Furthermore, when faced with reality, even the tasks that seemed plannable get more complex and need real-life adjustments.

    Most engineers have had analog experiences in their day-to-day work. We can translate this notion into platform engineering quite well. Building a developer platform sounds straightforward at the onset. However, once we get into it, it becomes a rabbit hole of figuring out the CNCF landscape, adding company-specific glue, compliance, security, fixing bugs, getting deep into the open source projects and sometimes, faced with the reality of open source, even becoming contributors and maintainers of such projects.

    Now, I’m not saying that it’s all bad. All these things can be great and rewarding in their own way. Especially with a community like the CNCF, participating and contributing to open source can be a very rewarding experience. You’ll make lots of friends, learn DevOps and development skills and might even further your career significantly.

    While it’s a lot of work, there is a risk that every platform team basically reinvents the wheel. This is because an organization’s requirements seem too large to rely on a single product (or even a suite of products). We end up with bespoke platforms that need a lot of attention. These platforms also have platform teams that don’t have enough time to focus on the higher-level jobs that they were tasked with.

    Platform Evolution

    Over the years talking to and working with platform teams we have built a model of prototypical platform evolution and its risks at each stage.

    Usually, a platform team starts with the task of building a developer platform to enable the product teams to build great software and deliver value to the end users.

    As they build the platform from the first Kubernetes clusters to observability tooling to security, the backlog for features constantly grows. Even with a growing platform team and sub-teams for certain technology areas, there’s a risk that some of these backlog items never get attention. Especially, delayable, non-critical, daunting tasks (like upgrading to the next Kubernetes release) often fall victim to this problem.

    Next, when it comes to operations, the platform team needs to limit the possibilities and breadth of what they offer. Operations responsibility for functionality that is outside of those limits, (for example, a specialized data store) goes back to the product teams themselves, which results in developer distraction.

    Even with a wide coverage of the platform, Day 2 and operations, the next big task for the platform team is advocating for adoption. This is not just marketing for their platform, but also means the platform team has to build user-friendly interfaces and documentation. The risks and alternatives we often see here are that product teams build their own mini-platforms and systems that result in shadow IT. Another common risk is ending up with several competing platforms within big enterprises that are hard to integrate and centralize, which in turn leads to inefficiencies.

    Once we get over the adoption hurdles, it is the platform team’s job to deliver value and high-level capabilities to the product teams’ developers. However, at this stage, often the platform teams have grown and might encompass several sub-teams for technology areas. Additionally, some areas like security might already be under central IT control. The risk we see here is that the capabilities offered are reduced to technology silos. They might cover all areas like observability, connectivity, security and release engineering, but to achieve real maturity, a platform team needs to offer capabilities that span several of those areas.

    Many of the advanced capabilities that we see with more mature end users cover several or all technology areas. Think about a simple high-level capability, like progressive rollouts. It starts with release engineering capabilities to build and deploy the software. From there, we need connectivity capabilities to dynamically route traffic to the new service. Then we need observability capabilities to observe our new version and from there have automated feedback loops to roll back or go forward with the rollout to production. And if that wasn’t enough, as we’re a security-aware organization, we want the whole software supply chain that facilitates this to be secure and trusted.

    Question for the curious cloud native enthusiasts: How many tools do you need to integrate to achieve the above “simple” high-level capability in an automated way? And this is only one of many capabilities.

    PaaS-Like Platforms Without the Downsides

    So, while platforms and platform teams are definitely the way to go, we need to be aware of the amount of work and effort required.

    We need to be aware of the risks and strive towards building highly integrated platforms that deliver high-level capabilities to the product teams.

    However, cloud-native developer platforms, while having similar goals to the PaaS systems of the past, should not follow the same approach of full abstraction. If we just abstract away into bespoke systems that hide everything from the user, we go back to the world of PaaS where at some point the end-user developers hit limits and build workarounds around the platforms.

    Additionally, if we build these bespoke internal platforms, we’ll be stuck with them and need to maintain and evolve everything by ourselves.

    Or, to go back to the blog post I referenced earlier, “At every step and every level there’s an abundance of detail with material consequences.” And we have to remember what we care about. The way to avoid both of these downsides is to bet on open source and stand on the shoulder of giants.

    By building our platforms on open source and using as many of the established or soon-to–be-established standards of our community we can avoid our platforms becoming bespoke. Recent developments like Cluster API, Gateway API and sigstore are some good examples.

    Furthermore, we need to make our abstractions poke-able. While our platforms should come out of the box with user-friendly interfaces and sensible production defaults that enable new product teams to onboard quickly and get their jobs done without having to bother with deep understandings of the underlying technology, we need to keep them open to mature users that know their way around and want to tweak it to their needs. We achieve this by giving mature users the option to access said open standards and APIs safely.

    This is the strength that we gain from a community like the CNCF, so we should use it to build great platform products that stay true to the core of open source and strive to make our product teams as happy and successful as possible. And remember to be happy with ourselves as successful and appreciated platform teams.

  • Salesforce Launches Low-Code DevOps Platform

    Salesforce Launches Low-Code DevOps Platform

    Salesforce made generally available today a low-code DevOps Center service on its infrastructure through which developers are provided an opinionated platform for building custom applications. The Salesforce DevOps Center service is based on the same object model Salesforce uses to construct its own applications.

    Karen Fidelak, senior director of product management at Salesforce, said after nearly two years of development effort, this platform will make it simpler for both professional and citizen developers to build applications consistently using a common Source Control repository. That’s especially critical for professional developers that may need to access source code previously created by a citizen developer, Fidelak noted.

    In 2023, Salesforce will embed more robust continuous integration/continuous delivery (CI/CD) capabilities within the platform to make it simpler to deploy custom applications on the Salesforce platform, Fidelak added.

    In general, the number of developers willing to embrace DevOps best practices to build Salesforce applications has been surprising, since the platform was initially launched in 2020, noted Fidelak. She noted that both citizen and professional developers are looking to adopt best practices that provide a set of guardrails that ensure high-quality applications are secure. Salesforce anticipated a much higher level of DevOps resistance, added Fidelak.

    The DevOps Center platform enables development teams to track and deploy changes to custom objects on the Salesforce platform as Work Items that can be integrated with other Salesforce Flows, a set of process management tools the company provides. As development teams make changes in their sandboxes, DevOps Center automatically tracks them. Developers can then point and click to promote their desired metadata components via custom pipelines they define.

    In addition, Salesforce also provides optional integrations with version control systems such as GitHub to centralize the management and governance of artifacts.

    Finally, Salesforce is committing to tightening integration between DevOps Center and multiple software-as-as-service applications such as Tableau and middleware platforms such as Mulesoft, said Fidelak.

    It’s not clear how much low-code is moving through DevOps pipelines these days, but the volume is increasing as more developers rely on these tools to accelerate application development. The issue that creates is citizen developers typically don’t have the expertise required to build and deploy secure applications at scale—at least not applications that anybody other than themselves really wants to use. Ideally, citizen developers should be supported by application development platforms and DevOps teams that ensure security guardrails are in place for building applications at scale. DevOps teams should also reduce the friction that a citizen developer will most certainly encounter when building any application.

    The fact is, in the absence of that support, most citizen developers—who typically have other tasks that require their attention—will simply abandon an application development project should projects become overly complicated. None of this means organizations shouldn’t be working toward building their own army of citizen developers. The increased reliance on citizen developers is part of an inexorable wave of the democratization of IT. The challenge is making sure those applications are of the highest quality possible regardless of who actually developed them.

  • Building a Platform for DevOps Evolution, Part Two

    Building a Platform for DevOps Evolution, Part Two

    In the introduction to this series, we discussed the concept of change and how it applies to DevOps environments and release managers. 

    In a world of constant changes in our surroundings and user demands, DevOps has to maintain hundreds of moving pieces across large organizations of people who, by nature, are adverse to change. This requires release managers to delegate power, transition from a centralized commander to an enabler, understand different value streams and constantly experiment. 

    In this section, we’ll cover some of the ways and types of experiments DevOps organizations can conduct to improve their release management procedures and meet their objectives using DevOps principles.

    Value Stream Mapping

    Value stream mapping is a series of steps used by organizations to provide products or services their customers want or need. In the traditional sense, the release and deployment process can seem tedious, especially if teams must communicate with a release management team to schedule release slots on a calendar.

    Despite its advantages, value stream mapping has a few drawbacks. It requires a lot of people and it can be difficult to coordinate and sparsely repeated.  

    Value stream management platforms can extract the four key DevOps metrics for teams to inspect and adjust in real-time. However, there are some shortcomings with using the four metrics:

    • Lead time is characterized as time from code commit to live; however, in value stream management, we also consider the time it takes for an idea or customer request to reach value realization.
    • Deployment frequency becomes interesting when teams deploy sporadically but are still improving, but when teams attain the ability to release on demand, other metrics become more helpful.

    As a result, teams must alter metrics over time to match team ability. This is why it’s critical to empower value stream teams to discover and measure their own metrics. Another factor is that people are more likely to change when doing it for themselves rather than having it done to them.

    Lessen Batch Size

    Reduced batch size lowers risk and reduces the time an activity waits in a queue. When changes are minimal, they may be implemented quickly and with less danger of causing disruption, thereby making the distinction between the phases less significant.

    While some key metrics may be accessed through specific tools such as backlog or release automation, without a value stream management platform, it’s more difficult to gain insights into overall queueing time.

    The value stream map is automated when all aspects of the DevOps toolchain are combined, resulting in a unified system from idea through the realization that allows teams to understand their cycle time and value flow efficiency and observe how changes improve work.

    Evolving Architecture From Monolith to Microservices

    Most organizations have monolithic, tightly coupled applications because that was the best software design approach available in the past. However, as the industry evolves, release managers become increasingly conscious of the limitations of this architectural approach:

    • Large batches of work are required to build, test and deploy.
    • Dependencies must be managed, including people and systems.
    • Dependencies cause fragility.
    • Fragility causes bureaucracy (e.g., CABs).
    • Bureaucracy and handoffs hinder flow.

    Rearchitecting applications to microservices, like changing human behaviors in a system, does not happen overnight, and there are frequent bottlenecks along the way. This is often a “change or die” conversation. If the application does not become more capable of change, market disruptors will provide new experiences to consumers, and customers will jump ship for these competitors.

    A value stream management platform can reveal where restrictions, delays, and dependencies occur and how they might be reduced. As a tenet of DevOps says, “Don’t manage dependencies; break them.”

    For many companies, however, the road to systemic autonomy, or loosely coupled systems, is lengthy with many incremental steps of improvement. This method is recommended by the strangler pattern: chipping away at the monolith one bit of functionality at a time.

    During the application architecture change, we need to support value stream teams, so they don’t waste time on unexpected work caused by unknown dependencies. We also need them to see and appreciate the improvements they’ve made with the support of a value stream management platform.

    Part of the release manager’s job is to identify value stream success stories and share them with the other value streams so that local improvements can become global ones.

    Transfer the Release Management Role to the Value Stream Team

    When teams work independently on small changes, they can release them as soon as they are ready. However, moving from one state to another takes time to transition to that stage of the journey.

    In a traditional method of working, the release process is likely to be coordinated by a release manager or a team of release managers. The release manager role can be transferred to the value stream team, with the team providing access to systems that provide visibility into current releases to the release manager.

    Transparency into operations across value streams provides traditional release managers with great comfort during this transition, relieving them of the administrative strain. It allows individuals to learn new skills and refine the meaning and purpose they derive from their work.

    By taking an end-to-end and cross-value stream approach to change and improvement and ensuring blame becomes accountability, release managers can be key to the success of these improvements. Platforms for value stream management give the data needed to support the conversations that will lead to this cultural and behavioral shift.

    In this series’s third and final part, we will cover more types of experiments and DevOps best practices for achieving change and driving results. 

  • GitLab Research Shows Security Concerns in DevOps Teams

    GitLab Research Shows Security Concerns in DevOps Teams

    The threat of breaches is top-of-mind for many DevOps teams, and while security continues to shift left it appears to be a driving force for many decision-makers when it comes to choosing a DevOps platform or other technologies.

    These were among the results of a GitLabs survey that also found getting security right is the number one challenge for DevOps teams. 

    Getting it Right

    Among the top reasons respondents said they chose DevOps were better code quality, developer productivity and operational efficiency—cited by 37% of survey takers, followed very closely by better security/more secure applications.

    The survey also revealed that 53% of developers said they are fully responsible for security in their organizations, a 14% jump from 2021. 

    Michelle McLean, vice president at Salt Security, said it is risky for organizations to depend on development teams alone for security.

    “Security and developer teams need to collaborate and work together–at every point in the application life cycle–not just development,” she explained.

    For example, security teams must bring runtime insights back to development so they can be applied for education and training.

    “It’s fundamentally important to choose a DevOps platform that either has security capabilities built-in or that can easily integrate with security platforms to facilitate collaboration by security and DevOps teams,” she said. “Otherwise, organizations run the risk of pushing out unsecured software or introducing other risks into the software supply chain.”

    Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, added that an obsolete mantra in the cloud-native community held that security wasn’t a high priority as proper DevOps workflows meant that incremental changes were small and easily deployed.

    He said the Log4j and Log4Shell experiences called that philosophy into question with a recognition that security issues can, and do, occur out-of-band from a release or feature and that continuous monitoring for external threats is part of a properly functioning security process.

    “By implementing monitoring for new threats, regardless of source or nature, the ability for cloud-native development to quickly issue tested patches becomes itself a security feature,” he explained. 

    Understanding the Pipeline

    McLean pointed out that while there is a growing understanding of security in the pipeline with DevSecOps, it’s not enough.

    “This is particularly true, for example, in the case of APIs. Because APIs aren’t just straight code, you must see them being exercised to spot logic flaws,” she said. “You need the ability to monitor them in runtime in order to spot anomalies and find areas where APIs might be exposing critical data. Although developers write APIs, their testing often falls short for security.”

    To accurately see what’s going on with APIs, developers need to exercise the API–even in pre-production.

    McLean said this is an area where security and development collaboration and integration is essential–APIs underpin a significant portion of the modern economy and the disconnect between security and development teams can have a direct economic impact.

    John Bambenek, principal threat hunter at Netenrich, a security and operations analytics SaaS company, added there has always been a delay between the release of new platforms and the awareness that security capabilities for those platforms need to be implemented.

    “With cloud-native and serverless technologies, that delay is as short as I remember in my career,” he said. “I greatly prefer the world where everyone at least understands the need for security instead of having to spend time getting buy-in that it matters in the first place.”

    He said if you can manage and implement security in a seamless and efficient way early in the development process, it is far easier and cheaper to address issues than addressing them after code has already shipped—and that’s without adding in breach or liability costs.

    “You can either fix it in dev or in prod, but you’re going to have to fix it sooner or later,” he said. 

    McLean noted many organizations are still maturing in their DevOps practices, not to mention their DevSecOps initiatives.

    From her perspective, educating developers as to what is expected of them from a security perspective before a line of code is written is key.

    “To help increase compliance, we’ve begun to see organizations taking steps to introduce security tooling into their pipeline process and add testing into the build process,” she said.

    Then they’ll add a step that triggers an alert for non-compliant builds but won’t prevent the build. Then they’ll add a step that mandates sign-off by the developer that they’ve seen the security alert for a non-compliant build but still won’t interrupt the build.

    “In rare organizations with highly mature DevSecOps processes, they’ll fail the build for non-compliance,” she added.

    McLean said organizations need to understand what’s realistic given their maturity and risk tolerance and implement controls that match.

    They also need to reevaluate those controls to look for opportunities to increase adherence to security policies and other compliance regulations.

    Overall, continuing to educate through compliance automation in the software development life cycle (in development, testing and deployment phases) further helps reinforce best practices while ensuring issues are uncovered before they become a risk or technical debt.

    Mackey said because DevOps platforms touch the software powering your business, when choosing any DevOps platform, the security of the platform itself and the competencies it enables should always be must-haves.

    “In effect, any decision about new software should be based on how it improves the current security capabilities of the business,” he said. 

  • CircleCI Integrates CI/CD Platform With GitLab

    CircleCI Integrates CI/CD Platform With GitLab

    CircleCI today announced it has integrated its continuous integration/continuous delivery (CI/CD) platform with a rival software-as-a-service (SaaS) offering from GitLab.

    DevOps teams can now, for example, trigger pipelines in CircleCI from GitLab forked merge requests in addition to merging requests and making commits for specific branches. Other capabilities include the ability to access testing capabilities on the CircleCI platform and integrate permissions to ensure security.

    CircleCI CEO Jim Rose said the company routinely integrates its CI/CD platform with other offerings because organizations typically have multiple teams using different version control platforms at different times. The goal is to give those teams access to capabilities and best practices regardless of which specific platform they are using.

    In general, Rose said organizations are trying to strike a balance between the standardization of DevOps platforms and the need to enable development teams to innovate by adding new tools. Standardization tends to create more opportunities to automate more tasks in ways that reduce costs. However, developers will eventually rebel against any effort to limit the choice of tools they use to improve productivity, noted Rose. Too many senior IT leaders are quick to assume that a plethora of tools is an indication of a problem rather than the result of ongoing experimentation, he added.

    In the wake of the global economic downturn, many organizations are also revisiting their existing DevOps workflows to try to increase overall efficiency by automating more tasks. Those organizations realize they can’t afford to continue throwing labor at manual DevOps tasks, Rose added.

    The challenge, of course, is that building and deploying modern software is becoming more complex. Organizations are embracing microservices to make applications more resilient as they realize how dependent they are on software. The issue is that as the number of microservices continues to expand, it becomes apparent that legacy manual processes will not scale, said Rose. As a result, the impetus to automate DevOps processes becomes that much greater, he added. Less clear is to what degree organizations that have already embraced DevOps platforms might be willing to swap out their current CI/CD platform to achieve that goal.

    In the meantime, more organizations are embracing DevOps to manage software development projects that drive a wide range of digital business transformation initiatives. The applications driving those processes typically need to be continuously updated as business requirements change. That becomes much easier to achieve when using processes optimized around continuous development and deployment.

    Regardless of which underlying CI/CD platform organizations choose, they should assume that, eventually, some level of integration between those platforms will be necessary. After all, in the event of an acquisition, for example, it’s not likely both companies will have standardized on the same DevOps platform. Given the amount of time required to migrate from one DevOps platform to another the amount of time required for interoperability is inevitably going to be measured in months if not years.

  • Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

    Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

    Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.

    Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.

    Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.

    Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.

    Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.

    Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.

    Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.

    Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.

    It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.

    At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.

  • Clinical Trials: Programming for Scale, Speed and Success

    Clinical Trials: Programming for Scale, Speed and Success

    According to the Journal of the American Medical Association (JAMA), the median cost of bringing a new drug to market is $985 million and the average cost is $1.3 billion. However, those in health care hoping to harness promising new treatments, and patients facing steep prescription costs, see this as progress. After all, previous studies estimated the average price for developing a drug to be as high as $2.8 billion, a cost usually recouped at the expense of consumers. While savings are being realized, trials still come with quite a price tag—but the reasons why are understandable. First, clinical trials are complex and, simply put, time is money. The final stage alone, the Phase 3 clinical trial, can involve tens of thousands of participants, each with hundreds or thousands of data points that need to be tracked over a number of years. This can produce hundreds of millions of data points that must be protected, secured and blinded, and all of which must be analyzed by numerous applications.

    Many cite the fast development of a COVID-19 vaccine as proof that the process can be expedited. While the vetting of these vaccines was thorough, the processes benefited from unprecedented resources, industry and government cooperation and global pressure to quickly find a way to slow a highly infectious disease. Even so, one can’t help but wonder why clinical trials typically take six to seven years? Haven’t we learned how to speed up trials without jeopardizing health or draining budgets?

    The short answer is yes—there is a way to reduce the time and resources needed for clinical trials. Pharmaceutical companies use dozens of software platforms from an array of vendors in their trials. As a result, crucial data gets trapped in unconnected silos, adding complexity and stalling progress. However, by unifying apps and data stores in one integrated system, trial efficiency can be raised and time-to-completion reduced by over 20%.

    Raising a Platform

    Deloitte noted that COVID-19 revealed health care’s need for structural and technology transformation, adding that its future will be “enabled by radically interoperable data, artificial intelligence (AI) and open, secure platforms.” The same holds true for clinical trial data software platforms; however, creating a unified system is an enormous undertaking for software developers and software engineers. Most importantly, any unified system must be able to provide the following four capabilities.

    ● Security: Data in platforms must not only be protected from external threats such as hackers and ransomware but it must also be blinded. The ideal is a double-blind clinical trial in which neither participants nor their physicians know who received the actual drug and who received the placebo.
    ● Modeling: A platform must be capable of extending a data model for each clinical trial to prevent the need to rebuild every time. The models, and the platform overall, must be flexible but still capable of managing hundreds of millions of records across multiple trials.
    ● Extensibility: Over the course of years, data collected—even in a single trial—may change. The ability to extend a scheme on the fly to fit evolving needs can save an enormous amount of time versus building a platform and transferring data. This is especially true when you have millions upon millions of data points.
    ● Ease: A platform must be easy to modify by non-programmers. If a trial designer can implement rules without having to bring in a programmer, the trial will move ahead much more quickly.

    Key to being able to raise an effective clinical trial platform are software engineers and developers. According to the Bureau of Labor Statistics, software developer jobs alone will grow more than 22% by 2029—faster than all other occupations combined. While this is good news for software pros, demand will create a shortage exceeding 1.2 million by 2026, which isn’t so great for the pharmaceutical companies that need talent.

    Then again, there are purpose-built platforms available that provide data, software, services and an ecosystem of partners to support functions from research and development through commercial availability. They’re designed to bring such products to market faster and more efficiently while maintaining complete compliance. The platforms can not only be comprehensive, but they can also mitigate reliance on developers and engineers, with regular provider updates future-proofing operations and decreasing investments.

    Programming for Success

    First and foremost, pharmaceutical companies are achieving faster trial goals by leveraging the cloud and DevOps. In doing so, all data can reside in a central repository that’s accessible from anywhere. There’s no hardware requiring time-consuming manual configuration. What’s more, modern cloud infrastructures are resilient, secure and robust. And all of this is largely being made possible by software-as-a-service (SaaS) platforms.

    Despite this progress, the need to technologically bolster trials continues. AI is now being applied to auto-classify documentation. Naturally, these types of developments require the implementation of programmability and extensibility at scale. The best minds in software engineering have made considerable gains. It’s now up to pharma to ensure their trials and operations continue to be programmed for success.

  • GitLab Gets an Overhaul

    GitLab Gets an Overhaul

    GitLab launched its next major iteration, GitLab 15, starting with its first release version, 15.0, which the company said pulls together new DevOps and data science capabilities into the platform. With GitLab 15, GitLab says it provides (or soon will provide) continuous security and compliance, enterprise Agile planning, visibility and observability, workflow automation and increased support for data science workloads.

    In an interview with devopsy.kinsta.cloud, Hillary Benson, director of product management, detailed how GitLab 15 provides several security benefits, including the ability to automatically create an exportable software bill of materials (SBOM) and signed attestation for build artifacts, centralized security policy management including a two-step exception approval process, as well as providing compliance managers the ability to see project history changes and better enforce policy. “Supply chain security, especially, has become a major area of focus for us, both because it’s become a high priority in the industry and because GitLab is uniquely positioned to support customers well in this area,” Benson said.

    GitLab 15 also provides improved static application security testing (SAST) with stronger and more flexible rules and finding management, Benson said. Finally, users can pool together GitLab project data to create custom automations.

    According to Benson, GitLab 15 will also introduce more capabilities that interlink data across every stage of the DevOps life cycle from initial planning, implementation, deployment and monitoring. “Some of the things that will happen in this area are additional options for the types of work items that can be managed,” said Benson. That includes supporting a more diverse range of workflows and frameworks—including enterprise Agile frameworks. The platform will continue to support issues, epics and requirements and soon enable tasks, features and objectives.

    GitLab 15 provides new capabilities the company hopes will increase visibility and enable an end-to-end view of value delivery and application health, the company said. The unified collaborative context will help remove DevOps silos within organizations and decrease incident rates as well as provide comprehensive insights into issues that hinder performance in addition to real-time triaging of incidents. These new capabilities can help shorten lead times from code to production, reduce error frequency and severity, help development teams deploy more frequently and reduce mean-time-to-recover (MTTR) after an incident.

    Upcoming features include improved product analytics and experimentation, such as increasing the practicality of surfaced data by enabling testing and validating new ideas and measuring the adoption of DevOps best practices across teams and projects, Benson said. Expanded support for all DevOps research and assessment (DORA) metrics including improvements to value stream analytics for projects and groups is also addressed. “This is about making it easier to understand what value your product is bringing,” said Benson. “We’re introducing product analytics and experimentation to increase the practicality of the data that you’re using and the data you’re collecting to actually move your product forward,” says Benson.

    Finally, GitLab 15 will increase support for data science teams and their workloads. “This is about streamlining the development and deployment of machine learning models to train and test those and then get them into production. We’ll also be working on providing monitoring for those workloads so that it can be understood if those models are being used, how they’re being used and where there may be performance issues,” said Benson.

  • Digital.ai Extends Scope and Reach of DevOps Platform

    Digital.ai Extends Scope and Reach of DevOps Platform

    Digital.ai today unveiled the Ascension release of its namesake DevOps platform that adds pre-built metrics and best practices dashboards using a Test Lens capability to more easily employ analytics to identify software delivery bottlenecks.

    In addition, the company has added autonomous testing tools that automatically generate performance and security tests for mobile applications. These tools can be run by DevOps teams, developers or business users. An enhanced Change Risk Prediction capability enables machine learning algorithms to make more extensive use of historical data.

    Finally, Digital.ai has also added integrations with the open source Argo continuous integration/continuous delivery (CI/CD) platform and made available an Agility Sync tool for building custom integration with legacy application environments and opened an online marketplace for integrations.

    Jeff Moloughney, chief marketing officer for Digital.ai, said the goal is to extend the reach of the company’s DevOps platform. At its core, the platform has a value stream management (VSM) and version control software originally developed by XebiaLabs and CollabNet VersionOne before the two companies merged to create Digital.ai. The combined company subsequently acquired Numerify, a provider of analytics tools infused with artificial intelligence (AI), Experitest, a set of testing tools, and Arxan, a provider of an application security platform. The company claims that its platforms are used by more than 1,500 organizations.

    In general, DevOps is entering a new era as organizations realize how dependent they are on software to drive business processes, noted Moloughney. Historically, the adoption of DevOps practices has been driven from the bottom up within most organizations. Now, business and IT leaders are also looking to drive the adoption of a consistent set of DevOps best practices to gain more visibility into software delivery, he added.

    That does not mean, however, that organizations can dictate what tools individual developers can use, so the DevOps platform employed has to be extensible in terms of the available integrations, said Moloughney.

    At the same time, Molougney added that more DevOps processes will be automated using machine learning algorithms. Digital.ai is embedding these algorithms within its core platform to both uncover software delivery bottlenecks and automate routine tasks such as testing.

    It’s not clear to what degree organizations that have already embraced DevOps might be considering replacing their existing platforms but, regardless of size, most of them are encountering issues. On the plus side, the number of organizations that are adopting DevOps practices more broadly is increasing as more digital business transformation initiatives are launched. As those practices evolve, the expectation is many of those organizations will embrace analytics in the form of VSM to better optimize their efforts.

    In the meantime, the rate of DevOps adoption across enterprises will continue to vary widely. Each development team within an organization tends to define a set of DevOps practices based on their own requirements. The challenge, given all the dependencies that exist between those projects, is determining the actual rate of progress the organization is making as each of those isolated initiatives progresses.

  • Riverbed Unveils Unified Observability Platform

    Riverbed Unveils Unified Observability Platform

    Riverbed today launched a beta of a unified observability platform it will make available under the Alluvio by Riverbed brand name.

    Jim Hansen, senior vice president for product management at Riverbed, said the Alluvio by Riverbed observability platform combines several existing network and application performance management platforms into a single offering that is now infused with machine learning algorithms to provide deeper insights into IT environments.

    The goal is to provide an open observability platform that can not only aggregate data collected from both Riverbed and third-party offerings but also identify the best ways to resolve an IT issue, added Hansen.

    Scheduled to be generally available later this year, the Alluvio by Riverbed observability platform will differ from existing observability platforms in that it will enable IT teams to not just identify the root cause of an IT issue, but also note which processes should be employed to resolve it, he said.

    With this launch, Riverbed is attempting to reposition itself. Previously, the company offered network and application performance management platforms alongside a wide range of network software and hardware. Each of those offerings is now a source of data that can be fed into the Alluvio by Riverbed observability platform, noted Hansen.

    Observability, of course, has always been a core tenet of any DevOps best practice. Achieving that goal, however, has proven to be elusive. Most of the IT monitoring tools used today are designed to track a set of pre-defined metrics. Whenever there is an issue, IT teams typically convene in a war room where they try to uncover the root cause of, for example, a performance issue by comparing reports and the various dashboards generated by monitoring tools. It can take weeks to discover an issue that often only takes a few minutes to fix once the source of the problem is identified.

    In contrast, observability platforms promise to reduce the time required to discover IT issues by aggregating all the data generated by the IT environment within a single platform that correlates events and makes it easier to identify anomalous behavior. Armed with those insights, it becomes a lot simpler for IT teams to launch queries that enable them to resolve issues faster.

    Those insights are also increasingly being used to drive business decisions as organizations become more dependent on software to drive digital business transformation initiatives. However, a recent survey conducted by Riverbed finds three-quarters of business decision-makers (75%) said their organizations struggle to glean actionable insights from data generated by their technology infrastructure.

    The challenge IT teams inevitably encounter is they don’t always know the right questions to ask, which is an issue that can be addressed by machine learning algorithms capable of identifying anomalies indicative of an IT issue that needs to be resolved.

    There already is no shortage of observability platforms. The issue now is determining which observability platform to employ across a distributed IT environment that is becoming more instrumented with each passing day.