devopsy.kinsta.cloud

Author: Mike Vizard

  • The Graph Donates $48M to Advance GraphQL Platforms

    The Graph Donates $48M to Advance GraphQL Platforms

    The Graph, a provider of indexing and query tools based on the GraphQL language designed for blockchain platforms, today announced it has given $48 million to The Guild, a group of developers advancing an open source application programming interface (API) platform to further development of GraphQL-based technologies.

    Administered via The Graph Foundation, a nonprofit consortium that oversees the development of an open source graph database dubbed ONgDB, the agreement also calls for members of The Guild to contribute to the development of indexing and query tools being advanced by The Graph over the next four years.

    Eva Beylin, director of The Graph Foundation, said the goal is to fund the development of projects that leverage GraphQL, an open source data query and manipulation language for application programming interfaces (APIs) originally developed by Facebook, to create subgraphs used on blockchain platforms like Ethereum to index data in a way that is more accessible to developers.

    The open source community that is starting to evolve around blockchain platforms, also known as Web3, is now a major contributor to a range of GraphQL projects, noted Beylin. Those blockchain platforms are now being used to drive decentralized finance (DeFi) applications that do not rely on any single platform to process transactions. Those platforms are being employed by both startup and incumbent providers for financial services around the globe.

    It remains to be seen, however, how the GraphQL community will address security concerns. GraphQL APIs can easily suffer from broken object-level authentication issues just like any other API. The issue is a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could become a major vulnerability.

    Cybercriminals also tend to launch brute-force attacks against APIs. With REST APIs, that malicious behavior is easier to catch with standard web application firewalls (WAFs) because it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a brute-force attack is harder to detect. It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks one at a time.

    It’s not likely GraphQL APIs will replace REST APIs overnight. However, as the backend platforms for managing GraphQL APIs become more robust, the number of these APIs being used in a production environment by DevOps teams will dramatically increase—assuming there are no objections from cybersecurity teams.

    In the meantime, the open source community is clearly starting to rally around GraphQL, which should result in innovations applicable across a wide range of use cases. The challenge now is not only determining which type of API to employ and when, but also deciding whether any existing legacy APIs need to be replaced. One way or the other, however, the managing and securing of APIs—like it or not—is only going to become that much more challenging in 2022.

  • NetApp Survey Shows Hybrid Cloud is Maturing

    NetApp Survey Shows Hybrid Cloud is Maturing

    A small survey of 79 midsized to large enterprises conducted by NetApp suggests enterprise IT organizations might finally be embracing hybrid cloud computing beyond use cases involving backup and recovery.

    The survey finds 20% of respondents are currently employing both on-premises and cloud resources to support the same workload in a production environment, with another 17% planning to do so within 24 months.

    Darnell Fatigati, senior product marketing manager for hybrid cloud at NetApp, noted that a hybrid approach to cloud computing will dominate with more than three-quarters of respondents reporting their organization plans to operate a hybrid cloud environment for the foreseeable future. Only 17% expect their organization to eventually migrate all their IT environments to the cloud.

    A major factor in the decision to not migrate all workloads to the cloud is the amount of data gravity that legacy applications running in on-premises IT environments exert, noted Fatigati. The amount of effort required to successfully migrate terabytes and even petabytes of data into the cloud is simply too great, he added.

    The primary benefits of hybrid cloud computing cited by survey respondents are faster innovation (26%), increased responsiveness (25%) and increased collaboration (22%). Survey respondents also noted they are looking to improve infrastructure flexibility and scale (27%), optimize costs (21%) and improve data accessibility (13%). Data protection involving disaster recovery, backup and archiving remains the most widely employed use case for hybrid cloud, with 29% either employing it today or planning to do so in the next 24 months.

    Most hybrid cloud computing environments today consist of multiple clouds and on-premises IT environments that are managed in isolation from one another. The fact that more organizations are now starting to deploy the same workload across both a cloud service and an on-premises IT environment has significant implications for DevOps teams that will be required to manage those workloads. Most DevOps workflows today do not span multiple platforms. However, as more organizations become impacted by the occasional cloud outage, the level of resiliency enabled by hybrid cloud computing is becoming a higher priority.

    In many cases, the shift to hybrid cloud computing was accelerated by the COVID-19 pandemic that drove many organizations to increase the number of workloads deployed in the cloud. Now, heading into 2022, those same organizations are looking to reduce IT costs by centralizing IT management as much as possible, noted Fatigati. Each time an IT organization adds a new platform, the tooling and personnel required to manage that platform increase the total cost of IT for any organization. Much of the shift to hybrid cloud is being driven by C-level executives looking to reduce those costs.

    It may be a while before most enterprise IT organizations are able to deploy workloads across multiple platforms. However, as both cloud and on-premises IT environments continue to evolve and as more platforms deployed in local data centers are increasingly managed using a cloud operating model, the way those platforms are accessed on demand will continue to converge. In fact, there may come a day when the term cloud computing itself disappears from the IT lexicon as every IT platform, by default, leverages one type of cloud or another.

  • Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat this week announced that a private preview of the Red Hat Ansible Automation Platform is now available on the Microsoft Azure Cloud.

    Tom Anderson, vice president of Red Hat Ansible automation, said making the Red Hat instance of the open source automation framework available on Azure is the first step toward making it possible for IT teams to use the IT automation framework across multiple clouds.

    The goal is to make it simpler for IT teams to bridge multiple IT environments using a common framework to automatically configure everything from operating systems to security platforms across a hybrid cloud computing environment.

    Ansible is emerging as a de facto standard for automating IT environments largely because it provides an IT team with a declarative approach to automating IT processes. An IT team can write a playbook that describes their desired state for a platform without having to know anything about its current state.

    Interest in IT automation has soared as the number of workloads being deployed in the cloud and on-premises IT environments have steadily increased. The simple truth is that many organizations can’t keep pace with the rate at which applications are built and deployed because they are unable to hire and retain enough IT staff. The challenge is that writing a playbook to automate any IT process requires a fair amount of expertise that many organizations lack. There are, however, now large numbers of existing templates that organizations can reuse.

    Anderson also noted that security concerns will also force the IT automation issue. Many of the application workloads running in cloud computing environments are misconfigured because they were provisioned by developers that have little to no security expertise. A playbook greatly reduces the chances an application workload will be misconfigured in the cloud without having to turn every developer into a security expert, Anderson explained.

    Ultimately, IT automation frameworks reduce the level of friction that often exists between developers and the rest of the IT operations team in a way that actually serves to increase developer productivity, added Anderson.

    Regardless of how IT organizations automate IT processes, it’s now a question of the rate at which that goal will be achieved rather than if. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex, IT organizations are embracing automation more aggressively. Most of those initial efforts are focused on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

    In fact, many organizations may soon discover it’s difficult to retain IT professionals without investing in automation. After all, the most talented IT professionals will not want to work for an organization that requires them to always manually configure IT resources. Many IT teams might also discover that automation frameworks like Ansible are the gateway to embracing additional DevOps best practices. The challenge, of course, is finding the time to get started automating processes when there are so many immediate issues that IT teams can’t ignore.

  • Stacklet Embeds Collaboration in Compliance-as-Code Platform

    Stacklet Embeds Collaboration in Compliance-as-Code Platform

    Stacklet has added collaboration capabilities to its security and compliance platform that automatically groups related notifications, routes them to the right stakeholders and integrates with existing workflows and collaboration tools.

    The Stacklet platform is based on Cloud Custodian, an open source project that provides access to a domain-specific language that enables an IT team to employ YAML files to manage compliance-as-code.

    Stacklet CEO Travis Stanfield said that approach makes it simpler for organizations that have embraced DevSecOps best practices to comply with a wide range of mandates by shifting responsibility for achieving compliance further left toward DevOps teams.

    The latest version of the Stacklet Platform adds communications capabilities that leverage cloud resource configuration and policy metadata to automatically route notifications and escalations. Customizable notification templates add context for teams to collaborate either via email or integrations with Slack, Microsoft Teams and Symphony instant messaging. The Stacklet Platform can also trigger external workflows in tools such as Jira and ServiceNow to track issue resolution and generate reports.

    Ultimately, the goal is to make it simpler for IT teams to prioritize their compliance remediation efforts by keeping everyone involved continuously updated, said Stanfield.

    The number of compliance and security issues that organizations are experiencing in cloud computing environments is especially problematic. Developers often employ infrastructure-as-code (IaC) tools to provision cloud infrastructure. Unfortunately, they typically lack security and compliance expertise, which then results in large numbers of misconfigurations.

    The Stacklet platform is designed to give DevOps teams a way to prevent compliance and security issues using a compliance-as-code framework that spans multiple cloud platforms rather than requiring DevOps teams to employ a different set of compliance tools for each cloud platform on which applications are deployed.

    It’s not clear yet how far left responsibility for compliance will shift. In theory, organizations could avoid penalties if compliance issues are addressed before an application is deployed in a production environment. However, the teams that manage compliance in larger enterprises today are even further removed from DevOps teams than their cybersecurity counterparts. It may be several years before the cultural divide between these teams is bridged. In the meantime, many DevOps teams are taking it upon themselves to manage compliance as code to prevent unexpected issues from arising at the last minute before deployment.

    Overall, the goal is to enable DevOps teams to enforce compliance policies without slowing down the rate at which applications are built and deployed. The hope is that the adoption of compliance-as-code and DevSecOps best practices will address that issue. In fact, as the pace at which applications are deployed continues to accelerate to support digital business transformation initiatives, the number of potential compliance issues steadily increases. More troubling still, the greater the number of compliance issues there are, the more likely it becomes that cybercriminals will find a vulnerability to exploit.

  • Sentry Acquires Specto to Add Analytics Tool for Observability

    Sentry Acquires Specto to Add Analytics Tool for Observability

    Sentry this week announced it has acquired Specto, a provider of a set of tools for analyzing the performance of mobile applications.

    As the number of mobile applications being deployed continues to expand, developers are being asked to manage them as part of a general shift left that requires them to take on more accountability for how well their applications run in a production environment.

    Sentry CEO Milin Desai said today the Specto tools are focused on making it easier for developers to determine how mobile applications are running, but that the plan is to expand that analytics capability to a wider range of applications.

    As the responsibility for applications continues to shift left toward developers, the need for observability and monitoring tools that developers can easily use is becoming more acute. Sentry already provides a JavaScript software development kit that enables developers to insert a small amount of code in their application to track, for example, how many times an application failed. The Specto tools will take those observability capabilities to a deeper level by enabling developers to analyze a wider range of metrics collected, said Desai.

    Of course, DevOps teams are already collecting metrics, as well. Sentry has worked with partners such as GitLab and GitHub to provide a plug-in that makes it possible for DevOps teams to see the same metrics that developers are now using to manage applications. The goal is to make it easier for developers and IT operations teams to collaborate around a common set of metrics, said Desai.

    The rate at which responsibility for the management of applications is being shifted left, of course, varies widely. Some organizations continue to prefer to have developers mainly focus on writing code. However, Desai said Sentry is encountering more instances where site reliability engineers (SREs) are providing Sentry tools to developers as part of an effort to provide them with more insight into how their applications are running in a production environment.

    Historically, IT operations teams have relied on application performance management (APM) platforms to manage IT operations. Those platforms are now evolving into observability platforms that promise to provide more context by correlating events as they occur across both applications and IT infrastructure platforms. That approach, however, typically requires developers to insert agent software into their applications. Once inserted, that agent software needs to be maintained and updated within the context of a larger DevOps workflow.

    The Sentry approach provides developers with a tool for collecting data from an application that, after being embedded in the application, consumes just tens of kilobytes of memory. That approach eliminates the need to rely on much larger agent software to achieve observability.

    Regardless of how developers go about instrumenting their applications, the overall state of observability clearly needs to improve as application environments become more complex. The issue now is determining how best to achieve that goal in a way that benefits both developers and DevOps teams alike.

  • Vercel Acquires Turborepo to Gain Build System

    Vercel Acquires Turborepo to Gain Build System

    Vercel today announced it has acquired Turborepo, a provider of a build system for JavaScript and TypeScript applications that provides developers with access to an easy-to-use monorepository for their code.

    In the wake of that acquisition, the command line interface (CLI) for accessing Turborepo will now be available under an open source license.

    Jared Palmer, creator of Turborepo and other popular open source projects including Formik and TSDX, will continue working on accelerating Turborepo’s capabilities as the new leader of a build performance team at Vercel.

    The goal is to move existing users of the Turborepo cloud service to a Vercel platform for building applications using the Next.js framework, which makes it possible to build web applications based on the React library for creating user interfaces that enable both static site generation (SSG) and server-side rendering (SSR).

    Palmer said monrepositories such as Turborepo not only make it easier for developers to manage builds but also reduce the amount of time required to process those builds using a continuous integration/continuous delivery (CI/CD) platform.

    Rival build systems are also much more complex to configure and manage, which Palmer said is a primary reason many developers have not yet set up their own mononrepositories.

    As the number of applications that organizations want to build and deploy in the digital business transformation era increases, the focus on developer productivity is intensifying. Rather than having to maintain a complex build system, Turborepo is designed to be simple to configure. As a result, more developers can reduce build times by as much as 50%, noted Palmer.

    In effect, front-end developers are able to more easily become full-stack developers by combining that build system with the Next.js framework, he added.

    DevOps teams will need to adjust to applications capable of providing richer application experiences without relying as much on backend infrastructure. That shift has implications for everything from the amount of network bandwidth consumed to the performance of web applications. The Vercel platform employs caching, routing and a React framework to optimize application performance in a way that reduces the dependency on backend infrastructure to optimize application performance.

    As web application development continues to evolve, the overall rate at which they web apps are built should increase significantly. Naturally, DevOps teams will need to consider the implications of having more applications move through DevOps pipelines and the need to continuously update those after they are deployed.

    It’s not clear whether or how much DevOps teams will nudge developers toward frameworks such as Next.js to develop web applications that might not tax backend infrastructure as much as previous generations of applications. In effect, developers can take advantage of frameworks that enable them to treat the underlying IT infrastructure as if it were serverless whenever possible with tools that have a familiar JavaScript construct. Vercel claimed there are already more than 30,000 sites running Next.js in production at organizations like Airbnb, Hulu, Nike, Ticketmaster and Uber.

    One way or another, it’s clear that the way web applications are being built is fundamentally changing. The only issue now is determining to what degree the rest of the IT organization is prepared to absorb that level of change.

  • Digital Business Transformation Driving More API Adoption

    Digital Business Transformation Driving More API Adoption

    A global annual survey of 2,200 developers published today by RapidAPI, a provider of an application programming interface (API) hub, finds digital business transformation initiatives have led to an increase in reliance on external-facing APIs.

    According to the survey results, nearly three-quarters of developers (74%) are using APIs for internal applications. However, nearly half (49%) said they are working on third-party APIs, with 44% working on partner-facing APIs. That’s up from 35% a year ago.

    RapidAPI CEO Iddo Gino said it’s clear APIs are a key enabling technology for driving digital business transformation initiatives.

    More than three-quarters of developers (75%) indicated that participating in the API economy is a top priority for their organization now or in the near future, according to the survey results. Companies are realizing the opportunity for new revenue streams, with growth in API monetization strategies increasing to 41% from 35% in 2020.

    In addition, more than two-thirds of developers (68%) said they expect to increase API use in 2022, with 61% relying on APIs more in 2021 than in 2020.

    However, well over half (56%) noted that a shortage of developer talent is a top concern, followed by lack of internal prioritization around digital transformation efforts (34%), lack of API development resources and tools (32%) and lack of alignment with other departments (29%). A full 90% also noted that security and data privacy is a key issue to consider when employing APIs.

    The results also show the use of REST and SOAP APIs in production environments fell 3.7% and 1.4%, respectively, in 2021. That drop reflects the rise of alternative API technologies such as GraphQL and Async APIs, said Gino, However, he noted it’s unlikely any new class of APIs is likely to supplant legacy APIs anytime soon; instead, most organizations will be employing a wide range of APIs for many years to come.

    The survey results reveal that JavaScript is the most used (71.6%) and preferred (51.9%) programming language for building APIs. TypeScript is also gaining traction in terms of usage (20%) and being preferred (12%).

    The most troubling aspect of the survey, however, may be the fact that well over half of respondents (56%) said they are open to switching jobs. The top five reasons developers said they might switch jobs are higher compensation or improved benefits (60%), interest in a specific product or technology at a different company (54%), desire for a more flexible working environment (38%), interest in a specific company or market (25%) and an opportunity to work with former teammates or friends (17%).

    It’s not clear to what degree the so-called Great Resignation phenomenon might be impacting DevOps teams in general. However, it’s apparent no class of jobs is immune from a general sense of restlessness that pervades the market as the global economy continues to recover from the COVID-19 pandemic. The challenge and the opportunity for DevOps leaders is to encourage the best talent available to join and then remain with their organization versus pursuing a job somewhere else that, at least from afar, appears to have greener pastures.

  • Iterative Adds Experiment Versioning to MLOps Platform

    Iterative Adds Experiment Versioning to MLOps Platform

    Iterative today added an experiment versioning capability to an open source platform for managing machine learning operations (MLOps) using GitOps workflows.

    Dmitry Petrov, Iterative CEO, said the latest version of the Data Versioning Control (DVC) platform makes it simpler to save, compare and reproduce machine learning (ML) experiments at scale without requiring organizations to set up an additional repository to track them. Instead, organizations can store those experiments alongside other software artifacts in a Git repository, he said.

    As a result, IT teams will no longer need to try to keep track of experiments using spreadsheets or notebook tools such as Jupyter, he noted. Organizations that are building AI models for applications constructed using DevOps workflows will also find it easier to comply with a wide range of existing and forthcoming compliance mandates, added Petrov.

    The DVC platform makes use of a Git-like interface to enable organizations to track multiple versions of data sets, models and pipelines across an MLOps workflow. That capability is being extended to make it easier to manage the experiments data science teams create during the construction of an AI model.

    Iterative is at the forefront of an emerging debate over how best to infuse AI models into applications. Providers of platforms used by data science teams are making a case for separate repositories for tracking the artifacts used to construct an AI model. Iterative, on the other hand, is arguing for the use of an AI model build framework that uses the same Git repositories where any other type of software artifact is stored and shared. Iterative’s argument is that, in effect, AI models are just another type of software artifact, noted Petrov.

    In addition to reducing the total cost of building AI models by reducing the number of platforms required, a Git-based approach also makes it simpler for DevOps and data science teams to collaborate because the DevOps team will have more visibility into what AI models will eventually need to be incorporated into an application.

    It may be a while before the development of AI models and applications fully converges. Data science teams today typically have defined their own workflow processes using a wide range of graphical tools. However, as it becomes obvious that almost every application is going to be infused with machine learning and deep learning algorithms to some degree, the need to bridge the current divide between DevOps and data science teams will become more acute.

    In the meantime, DevOps teams should assume that many more AI models are not only on the way but that those models will need to be continuously updated. Each AI model is constructed based on a set of assumptions; however, as more data becomes available, AI models are subject to drift that results in less accuracy over time. Organizations may even determine that an entire AI model needs to be replaced because the business conditions on which assumptions were made are no longer valid. One way or another, the updating and tuning of AI models is likely to soon become just another continuous process being managed via a DevOps workflow.

  • Sumo Logic Extends Observability Reach to AWS Lambda

    Sumo Logic Extends Observability Reach to AWS Lambda

    At the AWS re:Invent conference this week, Sumo Logic announced that in addition to collecting log data, metrics and traces, it now can collect telemetry data from the Lambda serverless computing service provided by Amazon Web Services (AWS).

    In addition to collecting telemetry data, Sumo Logic also revealed that the Sumo Logic Continuous Intelligence Platform hosted on the AWS cloud can now analyze how functions used on the AWS Lambda service perform during transactions.

    That data can then also be correlated against the performance of other AWS services that Sumo Logic tracks via integrations with the AWS CloudWatch and AWS CloudTrail monitoring services.

    George Gerchow, chief security officer for Sumo Logic, said the company is making extensive use of the OpenTelemetry agent software created under the auspices of the Cloud Native Computing Foundation (CNCF) to make it simpler to instrument IT environments. That data is not only being used to improve application performance but also to surface anomalies indicative of a security breach, he added.

    As part of this ongoing security effort, Sumo Logic this week also added Sumo Logic AWS Quick Start integrations for rapid access to security and compliance insights along with support for Amazon Inspector, a vulnerability management service provided by AWS.

    AWS this week named Sumo Logic as its independent software vendor (ISV) partner of the year. The two companies have a longstanding relationship that began with Sumo Logic’s decision more than 10 years ago to build a monitoring platform hosted on the AWS cloud.

    As IT monitoring tools continue to evolve into observability platforms, Gerchow said it’s becoming much easier to leverage machine learning algorithms and open source agent software to identify the root cause of an issue before it results in a major disruption.

    Most IT teams today are still relying on legacy monitoring tools that only tack a set of predefined metrics to identify when a specific platform or application is performing within expectations. The metrics tracked generally focus on, for example, resource utilization. In contrast, observability combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshoot issues.

    Observability, of course, in one form or another, has always been a core tenet of DevOps best practices. Initially, DevOps teams focused on continuous monitoring as the most effective way to proactively manage application environments. However, it can still take days (and sometimes weeks) to discover the root cause of an issue. Observability platforms promise to make it easier to manage IT environments even as the overall complexity of those environments continues to increase.

    It’s not clear at what rate IT organizations will be transitioning to observability platforms. However, it generally takes only one major outage before IT organizations start looking for better tools to manage their IT environment. As those IT environments become more complex, the probability that there will be a significant disruption is now higher than it’s ever been. The challenge and the opportunity is to find a way to instrument applications more widely; the expectation being that an observability platform will be able to analyze telemetry data to reduce the number of issues that lead to service disruptions.

  • AWS Unfurls Bevy of Automation Tools to Streamline DevOps

    AWS Unfurls Bevy of Automation Tools to Streamline DevOps

    At the AWS re:Invent conference, Amazon Web Services (AWS) added a bevy of tools to its portfolio intended to accelerate the pace of application development while simultaneously simplifying DevOps processes.

    AWS development tools unveiled this week include AWS Amplify Studio, a visual development environment that allows developers to create web application user interfaces (UIs) with minimal coding.

    Ken Exner, head of product for developer tools at AWS, said as an extension of an existing AWS Amplify Studio tool, this latest addition allows developers to customize application UIs at a higher level of abstraction using a library of components while enabling them to drop down to a lower level of coding to customize their application further whenever required. After the UI is designed, AWS Amplify Studio automatically generates the associated JavaScript or TypeScript code for the developer.

    In general, AWS is committed to improving developer productivity by providing, for example, automated reasoning tools that automate processes without locking devs into a layer of abstraction that, ultimately, may create a wall that blocks them from meeting customization requirements, he said.

    Other developer tools launched by AWS this week include updates to Amazon CodeGuru Reviewer that adds a secrets detector that uses machine learning algorithms to identify hardcoded secrets that can be secured using AWS Secrets Manager; a revamped Amazon Inspector vulnerability management tool that provides automated assessment scans, automated resource discovery, support for container-based workloads, improved risk scoring, integration with Amazon EventBridge and AWS Security Hub and the removal of the stand-alone Amazon Inspector scanning agent.

    AWS also revealed it has eliminated the need to manually pull images from the Amazon Elastic Container Registry (ECR) repositories by adding automated synchronization capabilities that keep private and public registries consistent with each other.

    In terms of IT operations tools, AWS added a managed database service to its Amazon Relational Database Service portfolio that allows IT teams to customize the underlying database and operating system using an RDS Custom option, a new table class for Amazon DynamoDB designed to reduce storage costs for infrequently accessed data and a service for RDS, dubbed Amazon DevOps Guru, that extends existing machine learning capabilities to automatically detect and diagnose performance bottlenecks and operational database issues.

    Jeff Carter, vice president for relational databases at AWS, said that as databases are increasingly managed by DevOps teams rather than traditional database administrators (DBAs), the cloud service provider is moving to reduce friction by automating as many manual tasks as possible. That’s critical at a time when IT teams are deploying a much wider range of purpose-built databases that are optimized for different classes of applications, he added. The overall goal is to rely more on automation to reduce friction across the IT environment, said Carter.

    Overall, there are two classes of AWS customers: The first are development teams that are increasingly relying on managed services provided by AWS to automate a wide range of DevOps processes. The second tend to be enterprise IT organizations that prefer to manage cloud services themselves.

    Mitch Ashley, a principal for Techstrong Research, an arm of the parent company of DevOps.com, noted that, in many cases, enterprise IT teams are managing DevOps workflows that span multiple clouds. As such, they tend to prefer tools and platforms that can be applied to both multiple clouds and on-premises IT environments. The more those organizations rely on managed services provided by a cloud service provider the more difficult it becomes to consistently manage DevOps workflows across multiple IT environments.

    It’s too early to say just how much IT organizations will rely on managed services going forward. However, at a time when more organizations are using more IT platforms than ever, it’s clear the DevOps management challenge increases with each new platform introduced into the IT environment.