devopsy.kinsta.cloud

Tag: Platform

  • Harness Launches Open Source Gitness Platform

    Harness Launches Open Source Gitness Platform

    At its unscripted conference today, Harness unveiled a streamlined open source git platform, dubbed Gitness, that is significantly lighter weight than the platforms DevOps teams traditionally rely on to build increasingly complex applications.

    At the same time, the company is adding four additional modules to its continuous integration/continuous delivery (CI/CD) platform to improve developer productivity and make it simple to build and deploy secure applications.

    Finally, Harness is launching an Engineering Excellence Collective, a consortium of 300 senior engineering leaders. The collective is developing a maturity model based on 11 pillars for achieving software engineering excellence; a FinOps Excellence community initiative was also announced to advance best practices for controlling cloud computing costs.

    Harness CEO Jyoti Bansal said the need for a modern open source Git platform—as an alternative to legacy platforms developed a decade ago—has never been more apparent. Gitness provides all the collaborations, performance, analytics and security capabilities DevOps teams require in a streamlined platform that reduces overall bloat by seamlessly integrating, for example, code hosting and automated pipelines, he added.

    Other core capabilities include automated status checks and mandatory reviews, branch protection rules, user access management tools and a semantic search engine that has been infused with generative artificial intelligence (AI) capabilities that invoke multiple large language models (LLMs).

    Collectively, the approach reduces the amount of time spent when attempting to integrate and manage disparate tools on legacy platforms that inevitably lead to the creation of additional bottlenecks, said Bansal. Rather than bolting on additional tools, the time has come to simplify software engineering by migrating to a platform specifically designed to address modern software engineering requirements, he added.

    Designed to be installed using Docker contains in a matter of minutes, DevOps teams can also take advantage of tools to automatically migrate their existing repositories and pipelines from platforms such as GitHub and GitLab.

    Gitness is also at the core of one of the four additional modules that Harness is adding to its portfolio. The Harness Repository is a premium tool, available in beta, that provides governance and compliance-as-code capabilities embedded within the repository.

    The three other modules being added are a Harness Internal Developer Portal based on open source Backstage software, Harness Infrastructure as Code Management that makes it simpler to implement GitOps workflows at scale and Harness Software Supply Chain Assurance to provide visibility into open source software components and manage the creation of software bills of materials (SBOMs).

    It’s not clear whether DevOps teams are ready to rip and replace existing platforms, but the pressure to improve developer productivity has never been higher. Organizations increasingly realize that developers are spending the bulk of their time managing development environments tied to legacy platforms that create bottlenecks and are becoming more costly to manage and sustain.

    Harness, in effect, is now calling for the establishment of an alternative approach based on open source software that promises to streamline software engineering workflows. As applications incorporate microservices, security controls and AI models, they are only going to become more challenging to build and deploy at scale.

  • Does Platform Engineering Make DevOps & DevSecOps Irrelevant?

    Does Platform Engineering Make DevOps & DevSecOps Irrelevant?

    For those of us old enough to remember, the DevOps movement came onto the scene somewhere around 2007/2008. Its proponents railed against the traditional software model at the time, which called for the developers who wrote the code to be organizationally and functionally separate from those who deployed and supported the code. The reasoning behind the movement is that these siloed teams, concerned only with their own objectives, resulted in botched releases, significant delays, poor communication and, ultimately, unhappy customers. It took a few years to gain traction, but when Gartner got on board with the concept in 2011, adoption soared, and Agile development practices like automated build and test and continuous integration and delivery became the new norm.

    Security and Compliance Join the Mix

    Agile, DevOps and its promise of continuous integration and continuous delivery … well, delivered. Development and operations teams were finally on the same page, each able to see a current phase’s end goal, providing the flexibility to make changes and improvements along the way, speeding the delivery of quality software. Unfortunately, in these early years of DevOps success, security and compliance generally remained siloed. That silo resulted in security being an afterthought—stuck near the end of the application development life cycle. Consequently, security took the blame for release-delaying bottlenecks.

    The year 2014 was notable for an exponential increase in security breaches compared to the year before. According to an article in Security Week, 2014 marked the year that, for the first time, one billion records were compromised in more than 1,500 notable data breaches, an increase of 80% from 2013. Home Depot, JP Morgan Chase and eBay were among the many exposed to attackers. Given these and other high-profile breaches, it was time to re-evaluate development processes and give security and compliance a seat at the table.

    With research by Microsoft and others showing that 80% of security breaches were related to configuration errors, the concept of DevSecOps, putting security front and center in the Agile development process, ensures that assets are configured correctly in the first place, providing continuous compliance by running constant scans to identify configuration drift.

    This approach can be extended beyond the data center to any cloud to any edge, where even applications can be managed and checked against compliance and security standards. You can even extend a single DevSecOps compliance framework to cloud native assets including Kubernetes and public cloud services. 

    Today, it is safe to say that the term “DevOps” is likely losing its relevance, but “DevSecOps” is alive and well, as long as the organization embraces the cultural, people and process changes necessary for success. Tools and technology are essential to DevSecOps, as is adopting a culture that security is everyone’s responsibility. That culture requires instigating a security-first mindset among teams as well as implementing essential automated security testing tools.

    What About Platform Engineering?

    Platform engineering has recently captured interest and is now generating considerable buzz due to its focus on building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management. The platform is supported by layered services or tools, created and maintained by a dedicated product team, designed to support the needs of software developers by essentially stitching together components to create a frictionless developer experience.

    As Gartner says, “Platform engineering is an emerging technology approach that can accelerate the delivery of applications and the pace at which they produce business value.” In fact, Gartner expects “[t]hat by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery. Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.”

    In that context, platform engineering certainly builds upon the Agile concepts of DevOps and DevSecOps. Looking deeper at DevOps/DevSecOps and platform engineering shows that they both share many characteristics, while they can also be combined in a way that provides greater benefits to organizations that think about them in tandem. It is easy to see the integral link between platform engineering and DevSecOps and the broader infrastructure management landscape. For example,

    • Developer Experience and Productivity – DevSecOps extends experience and productivity support beyond the developer to IT Ops, security and compliance.
    • Automation – Automating infrastructure configuration as well as compliance tasks using a policy-as-code approach is the lynchpin of DevSecOps. Platform engineering provides the opportunity to extend automation to the other parts of the development lifecycle.
    • Self-service – This is another common concept where platform engineering can build off of the automation and services-oriented approach that DevSecOps uses to not only enable developer self-service for code/test/deploy, but also to enable developers to be more proactive and effective in the security/compliance realm.
    • Accelerate Value – Accelerating value is the focus of any tech enabler, from platforms to tools and processes.

    From an Agile development approach supported by DevOps/DevSecOps and extending now to platform engineering, the end game is all about speeding delivery of high-impact applications with continuous updates that are highly resilient, reliable and secure. Given the synergies and the pressure on organizations to rapidly deliver applications while combatting cyberthreats, any platform engineering effort should ensure that DevOps/DevSecOps plays a central role.

    While the term DevOps and, to some extent, DevSecOps, sound a bit dated and irrelevant and could maybe use a new moniker, the evolving role they are certain to play as platform engineering gains a foothold are not to be underestimated. 

  • Google Announces Availability of iPaaS Service

    Google Announces Availability of iPaaS Service

    Google today made available an integration platform-as-a-service (iPaaS) capable of invoking a range of methods to integrate applications.

    Initially developed for the Apigee application programming interface (API) management platform Google acquired in 2016, the Application Integration service can now, for example, also consume a publish and subscribe event or an event driven through a Salesforce platform.

    Amit Zavery, vice president and general manager for Google Platform, said the Application Integration service provides IT organizations with all the benefits of an iPaaS without requiring them to stand up and manage an integration platform themselves.

    The Google Application Integration service also provides access to a Visual Integration Designer tool that can be used to build workflows using a low-code tool. In total, there are now more than 75 connectors that can be used to integrate multiple Google Cloud services and third-party platforms that can run in either a cloud or on-premises IT environment, said Zavery.

    In general, visual tools are transforming how integrations are created and expanded within organizations, noted Zavery. Rather than using lower-level procedural code, a visual tool enables developers to employ low-code to create integrations. That makes it simpler to collaborate with business users that can now more easily participate in developing workflows.

    In fact, in some cases, business users, otherwise known as citizen developers, have enough technical acumen to create their own workflows using low-code tools.

    There are, naturally, going to be plenty of complex integration challenges that will require procedural code, but the bulk of the integrations required today are not especially complex.

    Regardless of who creates the integration, the number of them being employed across an enterprise organization continues to increase as more digital business transformation initiatives are launched. Developers are not going to be able to keep pace with the demand for those integrations if they rely solely on procedural code. The only way to effectively reduce the backlog for integrations is to rely more on visual tools to construct them. In most cases, the integration being created is relatively trivial. The only reason it wasn’t created sooner is there are not enough developers available to complete that task using procedural code.

    There are, of course, no shortage of iPaaS options available. As more workloads are deployed in the cloud, Google is betting the center of gravity for integration will shift toward the places where modern microservices-based workloads are deployed to reduce overall latency.

    It’s not clear whether organizations still view integration as an afterthought versus employing an integration platform around which all applications revolve. That latter approach tends to reduce the total cost of integration when compared to using multiple point products that are not managed via single framework, noted Zavery.

    Ultimately, IT teams that adopt an iPaaS are able to focus more on higher-value IT tasks. The issue is determining which integration projects really require professional developers with lots of integration expertise and which, via a low-code tool, can be handled by almost any developer.

  • Defining ‘Best’

    Defining ‘Best’

    (Note: For the last few years, I’ve been sparse with naming vendors in blogs. This one will have more than usual as examples.)

    We all have a ton of tools at our disposal. From installed tools to products to open source, we can solve any given problem in fifteen different ways. Several years ago, I wrote a blog about using what you have to get the most out of your purchases. There are several “platforms” that solve a lot more problems than just what you are currently using them for. At the time, my shining example was F5’s BIG-IP. That thing can do everything: Networking in your data center and probably cooking your breakfast, too. At the time, most people used the box to handle load balancing but then were concerned about the cost. Duh? I mean, you have a tool that can solve a fistful of problems … and you’re using it for load balancing. I mean, it’s very good at load balancing, don’t get me wrong. But I feel like quoting Marvin from The Hitchhiker’s Guide to the Galaxy. “Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don’t.” (Interestingly, at the rate that generative AI is advancing, it is only a question of time before a machine throws that quote out there.)

    The thing is, investors and the hype machine told all of your vendors three things. First, that they needed a recurring revenue stream. Second, that you wanted everything as-a-service and third, that they needed to be a platform. That means that those fifteen SaaS products you’re on the hook for now want to solve all of your problems because “they’re a platform.” Some of them do a kick-arse job of it and you might very well have a SaaS license that covers whatever you need to do today.

    This is screamingly obvious for some vendors. If you’re an Akamai customer, for example, the breadth of things you can do through them is stunning. Most customers do not seem to take advantage of that to the extent they should. This is no different than that BIG-IP in your DC; it’s just as-a-service. You’re already paying for both. You should make the most of them.

    Other vendors might surprise you but  they have done the same through M&A or expanding their “platform” from marketware to reality. I have hinted at this in the not-too-distant past but will say it point-blank here. Know what your products are capable of. Tomorrow you might need some of that functionality, and knowing if it’s already in the organization (but not being used) is a big deal. Also, if the “platform” already fits into your organization, then choosing a ‘best’ solution leans toward that product line already–less integration is the best integration.

    And keep those lights on. You may have more tools than you need, but you’re managing them and keeping the organization online. You should be getting kudos for that, so I’ll offer them. Thank you. I replaced my phone this weekend and had to reconnect everything and to all of those orgs I had to log back into, reinstall or reconfigure, let me say: I am grateful for each IT person there. Even my bank, who honestly pisses me off—I’m still grateful for their IT.

     

  • Chronosphere Adds Professional Services to Jumpstart Observability

    Chronosphere Adds Professional Services to Jumpstart Observability

    Chronosphere has added a professional services capability through which it will provide the resources and expertise needed to deploy and manage its observability platform.

    Ian Smith, field CTO for Chronosphere, said the Chronosphere Quick Start program will make it easier for organizations to transition away from legacy monitoring tools that only track a set of pre-defined metrics and embrace an observability platform that enables DevOps teams to surface issues before an IT environment is disrupted.

    The scope of the services provided spans everything from data ingestion to providing training so that management of the Chronosphere observability platform can eventually be handed over to an internal DevOps team.

    The professional services team will also guide DevOps teams through setting up data control mechanisms and retention polices in addition to crafting dashboards to monitor specific processes.

    Finally, there’s also a self-paced online learning platform, dubbed Chronosphere University, that provides a comprehensive curriculum to help DevOps teams navigate fundamentals, advanced features and best practices.

    It’s still early days as far as the adoption of observability platforms is concerned. But it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary, but the biggest technical obstacles are deploying and configuring the platform, loading data and managing the cost of storing all the data that is collected.

    In addition, DevOps teams also need to understand what queries to launch to investigate specific issues. Many DevOps teams lack the expertise required to frame those queries today, but it’s expected that machine learning algorithms and other forms of artificial intelligence (AI) will automatically identify issues that might lead to disruption.

    In the meantime, DevOps teams should be evaluating where it makes sense to continue to rely on monitoring tools. In many instances, an observability platform might obviate the need for that tool, but there may also be plenty of instances where a simple monitoring tool is sufficient for the task at hand.

    One way or another, however, more advanced observability capabilities will be needed as application environments continue to become more complex in the cloud-native era. Application environments now consist of a mix of monolithic and microservices-based applications that gain more dependencies with each passing day. An application may not be as prone to crash as it once was, but determining the root cause of a performance issue can still take weeks given all the dependencies that exist between various services.

    Regardless of approach, observability has always been a core tenet of DevOps. As organizations’ DevOps maturity increases, the greater the appreciation for it becomes. The challenge has been that observability is one of many DevOps things that are easier said than done.

  • 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.

  • Platform Engineering: Creating a Paved Path to Reduce Developer Toil

    Platform Engineering: Creating a Paved Path to Reduce Developer Toil

    This article is part one of a series of three on the boom in platform engineering and its role in reducing cognitive load and creating a better developer experience.

    Developer toil and cognitive load in the cloud-native space is real. The complexity posed by microservices, Kubernetes, and “software-defined everything” almost necessitated that ops needed to solve many of these issues to support cloud-native development.

    Developers taking on full dev life cycle ownership and the requirement to shift left have resulted in cross-functional and operational concerns that have added even more complexity to already challenging workloads and unclear workflows.

    To fuel productivity and consistency and enable developers to build and ship apps faster and more securely, one must understand what a ‘paved path’ might look like and where responsibility for different aspects of the development life cycle resides.

    Supporting the Majority of Developers Without Alienating the Rest

    Most developers want and need paved paths, particularly as paradigms shift; the adoption of cloud-native development being one such shift. These paths must help them reach the “safety” and productivity on which they are measured in their daily output and provide focus for completing their tasks. Freedom to make choices about processes and tools is not a priority because it ends up being noise that adds to the cognitive load and, in most cases, does not serve the company’s software shipping goals. This majority needs tighter guardrails and guidelines to do their work and get their code into the world without having to figure out too many operational parameters for themselves.

    The cloud-native tooling landscape is vast, duplicative and overwhelming. Just trying to select and test tools could be a developer’s full-time job. Likewise, many organizations and developers have reported frustration—they are wasting a lot of time on repetitive work and routine tasks that deliver no business value, such as setting up environments and troubleshooting CI pipelines along with slow feedback loops in the development process.

    As organizations increase pressure to deliver more with less and do so more frequently, these responsibilities make for a poor and unproductive developer experience and a far-from-ideal use of organizational resources. Stack Overflow’s 2022 Developer Survey reported that 62% of respondents spend more than 30 minutes a day fixing problems and looking for answers, leading to somewhere between 333-651 hours of lost time per week across a team of 50 developers. This reinforces a need for upfront investment in the paved-path developer platform, which eliminates much of this frustration.

    It’s worth noting there is also a so-called 1% developer–one who wants to experiment and discover new tools on their own. Defining the developer experience within narrow guardrails ends up stifling this minority, which not only hampers their productivity but could stand in the way of innovation for organizations as a whole.

    Building quality software requires accommodating both kinds of developers. For most development teams, the goal is to give them a clear route to building apps faster and shipping safely by prescriptively paving the path. The path also must provide enough freedom for adventure, allowing developers to stray from the path (within reason and where it makes sense).

    Internal Developer Platforms: Paving Just Enough Path With Platform Engineering

    Platform engineering and internal developer platforms (IDPs) are much-touted approaches to taming the toil. It is a part of the solution, and as it gains traction, it is becoming more mature. That is, instead of developers and development teams taking on full responsibility for every phase of the software life cycle and potentially cobbling together something resembling a developer platform, the industry trend is moving toward more comprehensive, commercial out-of-the-box platforms. Whether or not this addresses the actual needs of the development organization, this shift works because developer experience is now a business-critical requirement, and a centralized developer platform facilitates that experience (with flexibility enough to house all types of developer experience and developers working across industries).

    The developer platform concept, supported by architecture, DevOps and SRE teams, contains the ingredients of transformation both for business and for developer experience. As the concept reaches critical mass and the “productifying” of developer platforms matures, one thing seems likely: By shifting to a platform model, development organizations are moving from ops-first to developer-first Kubernetes. The developer experience becomes defined by its optimized tools and workflows (and enables wider adoption of cloud-native development across larger organizations and broader industries).

    Refocusing Developer Efforts: Abstractions, not Distractions

    Cognitive toil will exist for developers regardless of the tools they’re offered. Technologies grow more complex and change frequently, and there are performance metrics that must be met. Taking the focus away from developers’ primary concerns—coding and shipping software and features—contributes to this toil without generating much return. As much as developers should be able to gain enough understanding of the way their code behaves and the consequences it can have downstream when shipping and running it, they should not need to become DevOps experts as a part of their work. This is why DevOps, despite predictions to the contrary, isn’t dead.

    The paved-path developer platform gives developers exactly that: The ability to shift left without drifting right. The platform provides much-needed abstractions and tools that enable developers to refocus on priority work without distracting or overwhelming them with too many choices.

    Becoming dev-first doesn’t kill off ops, either. Dev-first Kubernetes and a centralized developer platform elevate the importance of the developer experience while continuing to highlight the importance of DevOps in supporting and optimizing the developer experience. This is an entire topic in and of itself, which will be explored in part two of this article series.

  • Datadog Adds Support for Microsoft Azure DevOps

    Datadog Adds Support for Microsoft Azure DevOps

    Datadog has added support for Microsoft Azure DevOps to its namesake monitoring and analytics platform.

    Ilan Rabinovitch, vice president of product and community for Datadog, said Microsoft Azure DevOps, formally known as Visual Studio Team Services, is gaining traction as a continuous integration/continuous delivery (CI/CD) platform that can be deployed on-premises or in the cloud.

    Via this integration DevOps teams that have adopted Microsoft Azure DevOps can now pull in events to create metrics from their continuous integration pipelines, and then correlate that information in real-time against Datadog is pulling from their entire stack in Datadog. DevOps teams can also configure to monitor gates in their Azure DevOps deployment pipelines, enabling them to detect and abandon bad releases automatically, said Rabinovitch.

    Finally, DevOps teams can also employ Datadog to measure the efficiency of their processes by tracking, for example, how often builds are completing or failing or the frequency of code commits, added Rabinovitch.

    Datadog Microsoft

    Microsoft has been pouring significant resources into building out Microsoft Azure DevOps over the course of the last year. At the recent Microsoft Ignite 2019 conference, the company released Azure DevOps Server update 1.1 release candidate to address some bug issues before organizations deployed the platform in production environments. Microsoft also has added previews of auditing tools, extended reporting capabilities, enhanced the user interface for the repositories page to be more mobile device friendly and added more billing options.

    Microsoft Azure DevOps in time will play a much larger role in the company’s bifurcated approach to hybrid cloud computing. On the one hand, the company is driving an increasingly larger portfolio of Azure public cloud services. In on-premises IT environments there is a massive base of Windows servers coupled with a nascent Azure Stack platform that provides organizations with the option to deploy the same IT environment Microsoft employs on its public cloud. The long-term goal is to make it easier for organizations to build and deploy applications across hybrid cloud computing environments using the same DevOps pipeline.

    Of course, Microsoft Azure DevOps is not the only CI/CD platform that might be employed to achieve that goal. As rival CI/CD platforms continue to extend their reach into Azure and Windows environments, Microsoft will find itself competing with a small army of rival DevOps platforms that span not only Azure, Windows and Linux platforms but also rival cloud platforms such as Amazon Web Services (AWS) and Google Cloud Platform (GCP).

    In the meantime, IT organizations should expect to see a host of third-party tools becoming available for Microsoft Azure DevOps as the CI/CD platform gains traction. In some cases, organizations will standardize on Microsoft Azure DevOps. In other cases, Microsoft Azure DevOps will become one of several CI/CD platforms that different teams within an organization are employing. Regardless of the CI/CD platform adopted, however, organizations that do wind up employing multiple CI/CD platforms are likely to want to consolidate as many as the monitoring tools they rely on as possible.

    — Mike Vizard