Category: Features

  • LeanIX Extends Application Management Reach

    LeanIX Extends Application Management Reach

    LeanIX today unveiled a catalog that enables DevOps teams to more easily track the relationships between microservices as they are built and deployed.

    At the same time, the company also revealed it has acquired Cleanshelf, a provider of a platform for managing software-as-a-service (SaaS) applications.

    LeanIX CEO André Christ said the Microservice Intelligence catalog will make it simpler for IT organizations to keep track of their ongoing software development efforts, while Cleanshelf provides the mechanism for centralizing management of SaaS applications that are now widely employed across the enterprise.

    The Microservice Intelligence catalog is the latest addition to the LeanIX Continuous Transformation Platform used to manage enterprise applications. It automatically captures and correlates metadata being generated across disconnected toolchains, pipelines and Kubernetes clusters to create a 360-degree view of microservices and their dependencies, said Christ.

    In addition to being integrated with the LeanIX Enterprise Application Suite, Microservice Intelligence comes with out-of-the-box connectors for Kubernetes, Jenkins, GitHub Actions and Red Hat OpenShift platforms.

    By monitoring deployment frequencies, mean-time-to-recovery (MTTR) and failure rates, Christ noted it will become easier to make software engineering decisions based on data and insights surfaced via the Microservice Intelligence catalog. DevOps teams can also annotate the microservices recorded by the catalog to provide additional information, Christ added.

    The Microservice Intelligence catalog provides the added benefit of making it easier to onboard new developers, said Christ. Each new member of a development team can, on their own, explore the overall application environment without requiring an IT team to dedicate someone to describe it each time a new member of a DevOps team is hired, Christ noted.

    At the same time, other stakeholders, such as cybersecurity teams, can explore the application environment to better understand dependencies as well as the potential impact of a newly discovered vulnerability, Christ added.

    In general, Christ said, as application life cycle management across the extended enterprise becomes more complex it’s clear new platforms will be required to manage legacy monolithic applications, emerging microservices-based applications and SaaS applications that, in the wake of the COVID-19 pandemic, are being used to enable employees to work from home. The Cleanshelf platform, in particular, will be rebranded as LeanIX SaaS Intelligence to address that latter issue. A SaaS discovery and cataloging capability will also be made available as a free component of the LeanIX Application Portfolio Management module in the second quarter.

    IT environments have never been more distributed, and it’s clear most organizations are under pressure to reduce the total cost of IT by centralizing management functions. It’s too costly to dedicate a management platform for each type of application deployed across an extended enterprise. LeanIX is making a case for a platform that enables IT organizations to finally centralize the management of application environments.

    It’s unclear at what rate that centralization may occur, given the level of inertia that exists within most IT organizations today. However, as application lifecycle management continues to evolve, the centralization of the management of application portfolios that continue to grow is all but inevitable.

  • Progress Unveils First Update to Chef Automation Portfolio

    Progress Unveils First Update to Chef Automation Portfolio

    Progress today announced it has enhanced its Chef Enterprise Automation Stack (EAS) and released a new version of Chef Infra Client that promises to make the programming language on which EAS relies more accessible.

    Sudhir Reddy, vice president of engineering for Progress, said the latest versions of both offerings are the first updates to the Chef portfolio since Progress acquired the company last fall.

    Chef EAS combines elements of the Chef portfolio in a way that makes it easier to develop and integrate DevOps workflows that span everything from provisioning infrastructure to deploying applications. The latest update to EAS adds the ability to automatically execute compliance audits as part of any Chef Infra Client run using Chef InSpec tools. At the same time, the latest update also simplifies the implementation of the patch management processes.

    DevOps teams can also view and manage Chef Infra Server details via the Chef Automate framework. Those views, when combined with Chef Infra Client Run Reports, provide insights into the various policies and Chef objects in use on a system.


    Finally, the Chef Workstation module includes the Chef Habitat command line interface (CLI) to further simplify workflows.

    Ultimately, Progress is moving toward creating a common user experience across all elements of the Chef EAS suite of tools, Reddy said. In effect, EAS is emerging as the control plane through which the entire Chef portfolio will be managed, Reddy added.

    Meanwhile, Infra Client 17 promises to make the Chef Language underpinning that suite more accessible. It provides a streamlined developer experience as well as pre-built integrations with various cloud services. In addition, Progress is adding support for various ARM processors used in cloud services, macOS Big Sur, the Apple M1 architecture, Windows 8 and PowerShell Core.

    Progress also enhanced its ability to securely capture metadata from the Amazon Web Services (AWS) public cloud as well as capturing data from Microsoft Azure clouds.

    An early pioneer of a framework for automating IT infrastructure-as-code management, Chef is still widely employed. However, rival open source frameworks have since emerged, which Chef eventually responded to by making its core platform also available as open source software as it changed its business model. Progress today also announced it will recognize external contributors to the platform with recognition awards. Progress reports that, in 2020, there were more than 6,000 contributions from over 350 contributors in the Chef community in support of Chef Infra, Chef InSpec and Chef Habitat.

    It’s still unclear how the battle for infrastructure-as-code framework management supremacy will ultimately play out. While many developers have clearly shown a preference for rival open source tools, Progress is positioning the Chef portfolio as a framework for IT organizations that need to automate processes at scale, including how application are deployed on infrastructure that is provisioned as code.

    Of course, many rival framework providers have similar ambitions. The challenge, of course, will eventually be convincing organizations that tend to employ a wide range of tools across different departments to finally standardize on one framework versus another.

  • Eclipse Foundation Creates Adoptium Working Group for OpenJDK Binaries

    Eclipse Foundation Creates Adoptium Working Group for OpenJDK Binaries

    The Eclipse Foundation announced today a working group that will establish a governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based on OpenJDK source code.

    Members of the Adoptium working group include Alibaba Cloud, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic and Red Hat.

    OpenJDK is a free and open-source implementation of the Java Platform, Standard Edition that is provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source, high-quality Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times.

    The Eclipse Foundation is now continuing that effort under an Eclipse Adoptium project that aims to become the primary source for OpenJDK-based binaries. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that will enable it to run compatibility tests to ensure conformance to the Java specification.

    Mike Milinkovich, executive director of the Eclipse Foundation, said the Adoptium WG will provide the infrastructure, marketing, community building and developer education required to ensure timely releases and adoption of Eclipse Adoptium runtimes.

    OpenJDK is a reference implementation used by multiple vendors to create their own binaries, which are only guaranteed to be compatible with the standard until the next update arrives; updates are released approximately every six months. The Eclipse Adoptium project will make it simpler for developer teams to identify which binaries are compatible with specific implementations of OpenJDK. Ultimately, the goal is to encourage developers to build applications using frameworks that make use of new OpenJDK features as they are added to the platform versus continuing to rely on older binaries.

    At the same time, however, the Eclipse Foundation is also looking at making it simpler for enterprise IT teams to rely on long term support (LTS) licensing agreements that would be based on Eclipse Adoptium runtimes, Milinkovich noted.

    Despite the plethora of programming languages developers use and even after 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Over the last few years, OpenJDK has gained traction as organizations adopted an open source implementation of the specification that enabled providers of frameworks for building applications to reduce licensing costs.

    It’s not clear at what rate enterprise IT organizations are replacing proprietary editions of Java with OpenJDK. However, in the wake of the economic downturn brought on by the COVID-19 pandemic, reliance on open source software has increased to reduce costs. At the same time, many organizations are looking to build microservices-based applications using Java frameworks that are based on OpenJDK runtimes.

    Regardless of the underlying platform employed, as developers are asked to build and deploy applications faster, most of them will rely on the programming language they already know rather than take the time to master another.

  • Cooperative Gaming: Software Teams’ Secret to Success?

    Cooperative Gaming: Software Teams’ Secret to Success?

    Trust falls and team backpacking trips are out — cooperative gaming is in. Don’t think embarking on group Minecraft missions could help deliver great software products? Think again. A 2019 BYU study found a 20% increase in office productivity after just 45 minutes of gaming.

    Software engineering is a mentally taxing endeavor, and many developers are under mounting pressure to deliver. To destress, many software teams use gaming to unwind during work hours. Gaming, it turns out, has added benefits of improved morale, increased productivity and lowered ego around unofficial hierarchies within the office. Setting aside time to recharge with collaborative gaming could increase a workplace’s health and help software teams work together to deliver products more efficiently.

    I recently spoke with Max de Lavenne, founder and CEO of Buildable, ally to the workplace gamer, to see why he embraces gaming as a regular part of his software developer team’s weekly regimen. Buildable adopted gaming and saw a notable impact; de Lavenne shared how other teams could similarly introduce gaming to improve performance.

    Gaming in the Workplace

    Traditional business environments don’t typically embrace fun activities on the clock — there is a clear separation between work and life. But at Buildable, gaming is integrated into the weekly routine. The Buildable engineers set aside about 45 minutes mid-week for collaborative gaming, typically on Wednesday or Thursday. The Buildable team, made up of about 20 software engineers, favors Rocket League and a modded version of Minecraft.

    According to de Lavenne, gaming is a great way to foster collaboration and intuitive group thinking. “Getting recharged is really important,” he said. He encourages the team to adopt cooperative multiplayer games; no solo play. He also discourages violent and aggressive RPGs, like first-person shooters.

    Workplace gaming isn’t unique, in and of itself — many teams at other companies will often play Haxball during coffee breaks or get into a Call of Duty: Warzone match from time to time. Yet, few leaders have the stomach to sanction gaming as integral to the developer’s workflow and overall team dynamic.

    “Engineers collaborate best when they respect each other and have confidence in each other’s skillsets,” said de Lavenne. “They are individuals, but there’s a lot of groupthink in teams.”

    Benefits of Gaming

    Gaming has proven benefits. In fact, researchers at Kansas State University found that employees who spent one or two minutes during breaks in their day playing games such as Candy Crush on their phones reported being happier than their peers. Similarly, de Lavenne noticed improved mood and other positive outcomes from collaborative gaming at Buildable, including:

    • Better team morale: Having scheduled gaming breaks to look forward to each week keeps attitudes positive. Software engineering can cause fatigue, which managers need to monitor carefully. “People get tired, and there’s only so much the brain can do,” de Lavenne said .
    • More fluid communication: Collaborative gaming focuses a team’s effort on a collective activity free from monetary incentives, bonuses or other hidden agendas. Afterward, de Lavenne said he’s noticed more fluid communication emerge among the team.
    • Increased collaboration: There’s satisfaction in doing something together, and de Lavenne reports that gaming has redefined collaboration for his team in unique ways. Employees take the cooperative, creative attitude fostered from gaming experiences and apply it to more structured, scrum-type environments.
    • Increased productivity: Dedicating one hour for gaming per week equates to about a 2% loss of labor time. However, de Lavenne reported that the productivity gains afterward surpass that lost time and more.
    • Reduction of ego: In work environments, unspoken hierarchies inevitably exist. Interestingly, collaborative gaming can completely reverse those social dynamics. Seeing senior engineers at the bottom of a gaming leaderboard can be humorous and boost confidence for younger engineers.
    • Combating isolation: Throughout the pandemic, remote work has left many of us feeling lonely. For young engineers without families, a big chunk of social interaction may occur in the workplace. Games can help maintain good spirits by bringing teams together virtually.

    Tips for Encouraging a Healthy Gaming Culture

    The overall goal is to promote enjoyable, freeform shared experiences. To enable this, de Lavenne shared a few tips on integrating games into developer team workflows.

    First off, gaming should not be mandatory, as making it a required activity would somewhat defeat the purpose. Instead, gaming should be fun and completely voluntary. If people would rather get in some physical exercise or check Instagram, they should feel just as free to do so.

    Also, as much fun as gaming with the team could be, it’s helpful having the CEO removed from this activity, de Lavenne advised. This is important so that players don’t feel they’re constantly monitored. Yet, leaders may want to have a say in the type of game, as well as when it’s played.

    Furthermore, the game doesn’t need to be an immersive RPG — it could be as simple and accessible as Jackbox. Cooperative board games like Dungeons & Dragons or Gloomhaven could have just the same effect as digital games.

    Outside of encouraging collaborative gaming, leaders can take other actions to boost morale and productivity. One such action is leaving chat channels unmonitored, so that team members can engage with each other on whatever subject they want without oversight. Another way to affect morale is location, noted de Lavenne. As I’ve written previously, hiring interest is expanding outside of traditional tech hubs. Buildable, for instance, chose to headquarter in suburban McMinnville, Oregon, for its walkability, greenery and better work-life balance than in larger cities.

    Gaming Is Where It All Began

    Multiplayer video games, LARPing, and AR/VR environments not only offer an escapist retreat — they represent nostalgia. For many programmers, video games were a doorway to the computer science field in general.

    “I’ve rarely met a software engineer that never gamed,” de Lavenne added. Gamers often seek out the highest-performing machines. And chances are, those kids with limited resources built their rigs from scratch. “This inspires you to learn about hardware, and you start to care about speed, compile and software activities,” said de Lavenne.

    From Atari to Minecraft, gaming has been a shared passion among generations of programmers. Recognizing this affinity can unite a team. Because at the end of the day, “building good software is all about people,” said de Lavenne.

    Of course, software development takes extreme diligence, planning, and structure to deliver bug-free, user-centric products. But under intense pressure to perform and meet new digital innovation demands, software developers could get burned out without a bit of distraction. With gaming, “the team really comes alive,” de Lavenne said.

    So, when things get slow, check out what’s hot on Steam. You may, ironically, just find your next productivity breakthrough.

  • Grafana Labs Aligns with Elastic on Observability

    Grafana Labs Aligns with Elastic on Observability

    Elastic and Grafana Labs have allied to create a plugin through which DevOps teams that are employing Elasticsearch within a DevOps workflow will be able to invoke a monitoring platform, based on Prometheus, that is managed by Grafana Labs.

    Raj Dutt, Grafana Labs CEO, said both companies are dedicating engineering resources to building and maintaining a plug-in for a service, based on open source Prometheus software, that is rapidly becoming a de facto standard for observability in DevOps environments. One of the primary reasons for that expanded usage is that Grafana Labs doesn’t require DevOps teams to move data into a central repository to analyze it, Dutt said.

    The overall goal is to eliminate the “tunnel vision” that results when relying on tools that only visualizes a narrow set of metrics, Dutt added.

    The cloud platform provided by Grafana Labs is based on open source Grafana visualization tools. The primary tool for visualizing Elasticsearch data is based on open source Kibana tools. Grafana, however, is based on a fork of Kibana, so the plug-in represents an effort to bring those two open source communities closer together. The two companies plan to collaborate on including more aggregations, broader query language support and support for space-saving constructs like rollups as the partnership evolves.

    Grafana Labs provides a cloud service that aggregates data, pulled from multiple instances of Prometheus, deployed on clusters and servers. Prometheus, especially, gained a lot of traction as organizations began to deploy Kubernetes clusters that are also based on open source software. Both Kubernetes and Prometheus are being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    Once DevOps team initially employ Prometheus to monitor Kubernetes, they frequently expand deployments to monitor additional platforms. That shift has resulted in many providers of proprietary monitoring tools to extend the data they consume to include the metrics captured locally by Prometheus. Grafana Labs claims it has more 1,000 customers, including Bloomberg, JP Morgan Chase, eBay, PayPal and Sony, for a total of more 650,000 active installations of Grafana around the globe. Existing customers of Elastic that are paying for Elasticsearch support include Cisco, eBay, Goldman Sachs, Microsoft, The Mayo Clinic, NASA, The New York Times, Wikipedia and Verizon.

    It’s not clear to what degree Grafana and Kibana might ultimately re-converge one day, but it’s clear there will be a fair amount of ongoing cross-pollination across the two projects. In the meantime, DevOps teams should be able to opt for whichever open source visualization framework they prefer alongside Elasticsearch.

    In the longer term, it’s clear greater appreciation for observability platforms that provide more context will drive a wave of consolidation among all the monitoring tools that enterprise IT teams rely on today. As part of the transition, enterprise IT teams might even standardize on a set of visualization tools that would eliminate the need to master different user interfaces. After all, the only way to actually achieve observability is through a set of tools that makes surfacing the context required easier to consume.

  • Harness Revamps User Interface for CI Platform

    Harness Revamps User Interface for CI Platform

    Harness today announced it has updated the community edition of its continuous integration (CI) platform with, among other updates, a revamped user interface.

    Formerly known as Drone.io, the latest release also adds pipeline execution visualizations, governance and security controls and live CI pipeline debugging capabilities. Harness last year acquired Drone.io, an open source CI project, to extend its existing continuous delivery (CD) platform into the realm of CI. Harness claims there are now more than 50,000 active monthly users of the community edition of Harness CI.

    Brad Rydzewski, co-founder of Drone.io, said the user interface for Harness CI will soon be applied across the entire portfolio.

    The update to the community edition of Harness CI comes at a time when the debate over how tightly integrated CI and CD platforms need to be is heating up. Harness launched a namesake CD platform before it acquired Drone.io to add a CI capability. While most DevOps teams are proficient with CI, the CD side of the DevOps equation has proven more elusive. There are now GitOps advocates that contend the rise of Kubernetes makes it more advantageous to enable a separate CD platform to pull updates from a Git repository, rather than having them pushed out by a CI/CD platform. The challenge with CD has always been that each platform on which code is deployed is unique. Kubernetes, however, now provides a de facto standard layer of abstraction that runs atop multiple platforms.

    Rydzewski said the integrated CI/CD approach will ultimately prevail, because it enables DevOps teams to more easily integrate a range of processes, including testing, that are required to consistently build and deploy applications at scale. Harness is, essentially, making a case for solving the CD challenge using a platform that encourages – but doesn’t require – a DevOps team to replace their existing CI platform.

    Regardless of how DevOps evolves, the CD issue needs to be addressed. As the enterprise becomes more extended with the rise of both cloud and edge computing, the number of platforms a DevOps team needs to support continuously expands.

    Despite the fact that DevOps teams employ CI/CD platforms, it is clear most of those organizations are not overly committed to the way they currently manage CD. It may be years before most organizations finally implement a consistent set of processes for automating application deployment.

    In the meantime, the number of organizations just starting out on their DevOps journey continues to increase. There are still plenty of instances where organizations have yet to deploy any type of CI/CD platform. It’s also worth noting that, in many cases, different DevOps teams within the same enterprise have decided to deploy different CI/CD platforms.

    Regardless of how DevOps evolves the pressure to automate is rising. The challenge many DevOps teams face today is the current platform they are relying on to automate the building and deployment of applications requires a small army of specialists relying on all too often manual processes to maintain.

  • Copado Acquires New Context to Drive DevSecOps Adoption

    Copado Acquires New Context to Drive DevSecOps Adoption

    Copado, a provider of a DevOps platform for building applications deployed on the Salesforce cloud platform, announced today it has acquired New Context as part of an effort to expand the scope of its portfolio into the realm of DevSecOps best practices.

    Andrew Leigh, chief marketing officer for Copado, said the acquisition brings Copado tools and professional services expertise that will be applied to help organizations build and deploy secure, custom applications on top of the same cloud platform they already use to access a range of software-as-a-service (SaaS) applications.

    The New Context Lean Security Intelligence Platform enables developers to achieve that goal by analyzing code and then surfacing recommendations for when developers should apply specific security controls, Leigh explained. Existing New Context customers include Blue Shield of California, GE, Kaiser Permanente and Royal Dutch Shell.

    Like most organizations that have embraced DevOps best practices, it’s still early days as far as adoption of DevSecOps are concerned. However, it’s already apparent that Copado is well-positioned to advance adoption of a complementary Lean Security Intelligence Platform, said Leigh. Copado, which claims to have more than 1,000 customers, recently raised an additional $96 million in funding to help fuel those efforts. The company also claims it recorded 120% growth in annual recurring revenue (ARR).

    In the wake of the COVID-19 pandemic, more organizations are employing SaaS applications to drive digital business transformation initiatives. Rather than building every application from the ground up, it is often simpler to extend, for example, a Salesforce customer relationship management (CRM) application.

    Once organizations reach a certain level of scale, they then start to apply DevOps best practices to those builds. These efforts, however, are often uneven. A recent survey, conducted on behalf of Copado, found that while 82% have increased or maintained the size of their Salesforce development teams, the change fail rate jumped from 23% last year to 33% in 2020 when compared to a similar survey conducted a year ago. The survey also notes time to recover increased from 110 hours in 2019 to nearly 196 hours in 2020.

    The next major challenge facing organizations that have embraced DevOps is, of course, DevSecOps. The challenge is that, since Salesforce environments are unique, applications are constructed using a set of objects and tables that are specific to that platform. As such, Salesforce environments generally require a DevOps platform designed from the ground up to work with objects and tables.

    Salesforce, in its most recent fourth quarter, reported revenue of $5.82 billion, up 20% year-over-year despite the lingering economic impact of the COVID-19 pandemic. As such, the number of custom applications being developed on top of Salesforce should steadily increase, especially as low-code tools become more widely adopted. It’s now only a matter of time before more organizations reach application development initiative critical mass that warrants investing in a DevOps platform to manage them.

  • Teleport Adds Database Support to Security Gateway

    Teleport Adds Database Support to Security Gateway

    Teleport announced today it has added support for databases to a security gateway, delivered as a cloud service, that is currently used to secure Linux servers and Kubernetes clusters.

    Ev Kontsevoy, CEO, said Teleport intends to extend the reach of the security gateway up the entire stack of IT infrastructure that developers routinely use to remotely access databases. Initially, Teleport 6.0 adds support for open source PostgreSQL and MySQL databases.

    Teleport has gained traction as an access management tool because it provides a single binary that can be easily deployed by developers to encrypt IT platforms and enforce session controls. It automatically discovers all the resources in an IT environment, along with the protocols needed to access them. Teleport also provides a unified audit log, in a JSON format, that enables IT teams to track what resources are being accessed, when and by whom.

    Other features include the ability to authenticate identities via built-in single sign-on (SSO) and multi-factor capabilities, discover and see all database instances, integrate with command line interfaces (CLIs) and a set of workflows for managing privilege escalation.

    Access control is becoming a bigger issue due to a number of factors. The overall IT environment is becoming more complex as the infrastructure stack required to run applications continues to grow; most IT teams continue to work from home to help combat the COVID-19 pandemic. Teleport provides a fine-grained approach to streamlining access management across servers, clusters and databases in a way that eliminates the need to rely on virtual private networks (VPNs). In effect, Teleport enables IT teams to move toward a more identity-centric approach to unifying the management of access, Kontsevoy said.

    That’s critical at a time when the rise of DevSecOps is pushing responsibility for security further left toward developers, Kontsevoy added. While the rate at which that transition occurs will vary widely, Kontsevoy said it’s clear developers are taking more control over access control as part of a broader effort to roll out secure applications, faster.

    It may be a while before DevOps teams are able to aggregate all the access control protocols they currently employ under a single proxy. However, Kontsevoy said, the massive amount of time and effort spent managing access control today will drive DevOps teams to look for ways to automate what is currently a very manual process.

    Less clear is what role cybersecurity teams might play in supervising access management. The days when a separate overlay was needed to manage access may be coming to a close.

    In the meantime, it’s clear VPNs were not designed to address access management, in an era where the bulk of IT teams – and the employees they support – are working from home. More employees may be soon be heading back to the office more frequently, but it’s likely that remote work will remain prevalent. That means legacy approaches to managing remote access that were never designed to scale will becoming increasingly obsolete.

  • Logz.io Adds Prometheus Service to Observability Portfolio

    Logz.io Adds Prometheus Service to Observability Portfolio

    Logz.io announced today the general availability of a cloud service, based on Prometheus, that can collect and analyze metrics alongside its existing log management service.

    Jonah Kowall, CTO, Logz.io, said the goal for Prometheus-as-a-Service is to provide IT teams with a centralized approach to analyzing data collected from instances of Prometheus running on local servers and clusters. While Prometheus is relatively easy to deploy, it’s not designed to scale horizontally, which means IT teams have to deploy multiple instances of Prometheus on a fleet of clusters and servers. The Logz.io service makes it easier to aggregate and analyze all the data those instances of Prometheus collected, said Kowall. That approach not only offloads the storage of those metrics, Kowall said, it presents an opportunity to correlate that data against logs and traces that Logz.io already collects.

    Logz.io, as part of that effort, is also making it possible to upload a Grafana dashboard, typically employed to visualize Prometheus data as a JSON file, to Logz.io, which will then convert the Grafana dashboards to dashboards based on the Logz.io user interface.

    While Prometheus is closely identified with Kubernetes, IT teams are starting to deploy the open source monitoring tool more widely to collect metrics. A recent Gartner report predicts that, by 2025, half of new cloud-native application monitoring deployments will rely on some form of open-source software to instrument applications. As part of that transition, Prometheus has already emerged as a de facto standard, Kowall noted.

    The primary focus, at least initially, is still on monitoring IT platforms, but as IT teams start to correlate metrics, logs and traces, they begin to benefit from additional context, otherwise known as observability, Kowall said.

    Observability, of course, has always been a core DevOps principle. However, as more applications become instrumented using open source tools and agent software, it’s becoming less costly to achieve. DevOps teams will still need to instrument each application, but the costs associated with collecting metrics and other data continues to decline. Most providers of monitoring tools and observability platforms are moving toward adding support for open source tools and agents to collect data alongside the proprietary tools and agent software they already make available. It will be up to each DevOps teams to decide whether to rely on open source tools or continue to rely on proprietary software that may be able to surface deeper insights or is simply easier to deploy.

    Regardless of the path chosen, the rise of microservices-based applications with numerous dependencies is forcing the observability issue. Microservices-based applications may not crash as frequently as a monolithic application because they are, ideally, designed to degrade gracefully in the absence of a single point of failure. The challenge is that, once they do degrade, it’s difficult to pinpoint the source of the issue; this may result in applications running sub-optimally for an extend period of time.

    The good news is that DevOps teams should now have the tools required to diagnose and resolve those issues long before any end user notices.

  • Assessment of DevOps Capabilities: 5 Dimensions Explained

    Assessment of DevOps Capabilities: 5 Dimensions Explained

    In order for organizations and teams to move toward DevOps maturity, they need to understand their DevOps capabilities. An Assessment of DevOps Capabilities determines a baseline DevOps state, measures and accelerates continuous improvement.

    When we designed our Assessment of DevOps Capabilities (ADOC), the ambassador cohort brought a ton of ideas to the table around the high-level topics based on their experience performing this work for years. We talked about how important it was to cover the three aspects we have classically referred to in our industry; people over process over tools and many referred to the CALMS (culture, automation, lean, measurement and sharing) model widely known in the DevOps world and originally coined by Willis, Edwards and Humble.

    Our chief of research, Eveline Oehrlich, who led the 40-strong ambassador cohort who crowdsourced the model along with myself, had been conducting research for our Upskilling Report for several years. We looked at the models she’d been using there to drive comprehensive coverage of the different dimensions of DevOps. They aligned with the other models we were considering, resonated with the team and we all agreed that they gave us the best chance of ensuring the organizations that would use the assessment considered all the elements of these complex and sophisticated ways of working we call DevOps.

    The 5 Dimensions of the Assessment of DevOps Capabilities (ADOC)

    1. Human aspects
    2. Process and frameworks
    3. Functional composition
    4. Intelligent automation
    5. Technology ecosystem

    Our next job was to define the topics in each dimension and then to define Likert statements for each of the topics. These statements allow for data to be collected that provides teams with insights into where their capabilities are strong and should be shared, and where we recommend they experiment with improvements. Let’s look at each dimension in more detail:

    1. Human Aspects Dimension

    At DevOps Institute, we’re all about the human aspects. We know that culture is the biggest challenge for most organizations on a DevOps journey. Helping individuals and teams to understand and change behavior is a core purpose of ours.

    In this dimension, we address psychological safety and a culture of trust. We explore how leadership behaves, using transformational leadership as a model. We ask questions that explore how the team feels the organization is performing in terms of alignment, accountability, autonomy, empowerment and if and how they feel supported. We look at dynamic learning and constructive collaboration.

    Some topics focus on The Three Ways; we consider flow through the lens of customer focus and value stream thinking. We ask about how feedback is generated, received and reviewed in retrospectives. We explore how innovation and experimentation happens. There are some statements that help the teams learn about organizational design and team topologies. And we also include happiness and joy at work, and diversity and inclusion topics.

    2. Process and Frameworks Dimension

    Many years ago, I borrowed our esteemed leader Jayne’s phrase, “DevOps is the happy, polygamous marriage of ITSM, lean and agile.” Naturally, these frameworks are in this dimension – specifically, how they connect with DevOps activities.

    We also look at how the teams are experiencing scaling their activities and whether it’s working for them. We want teams to understand how to achieve high performance in continuous compliance, so we help them explore how they incorporate governance, risk and compliance (GRC) in all that they do.

    We take another look at value stream ways of working from a process perspective, and how well teams are transitioning from project to product. We look at a couple of frameworks very closely related to DevOps; site reliability engineering (SRE) and DevSecOps.

    We explore how the teams are leveraging systems and design thinking. We gather data on which elements of immersive learning, Holacracy and Humanocracy are helping them achieve their DevOps goals.

    3. Functional Composition Dimension

    In this dimension, we are looking at all the steps from ideation to value realization.

    We start with looking at how the teams collaborate and then where and how ideas are conceived, nurtured and refined through portfolio, backlog and product management and ownership.

    We look at change, whether the teams are using lower-level change advisory/approval board (CAB) patterns, and how far they have progressed towards peer-review. We explore with them how loosely coupled their architecture has transitioned, and how they build, develop and integrate. We ask them to rate their capabilities around test and validation, and deploy and release.

    Other capabilities we explore include operations and support, security, infosec and cybersecurity – helping them understand the patterns that create the safest environments to reduce business risk. We look at data lakes and how they manage data generally; its statefulness has always caused problems with DevOps at speed; for remediation and test data in particular. And we help them understand how to build in reliability and recovery patterns to counteract the risks associated with high-velocity working.

    4. Intelligent Automation Dimension

    This dimension is all about the DevOps toolchain; from artifact management and source control through CI/CD and into live.

    We also look at how tools are used to create a unified backlog, and how service and support happens post-release. We explore environment management and how well the teams are achieving continuous compliance and what this means for customer delight.

    We consider some of the key tool categories that help obtain feedback for improving customer experience; observability and monitoring and tie it all together by exploring how the team is using value stream management to gain visibility, traceability and insights into the end-to-end flow through the DevOps toolchain.

    5. Technology Ecosystem

    Our final dimension is designed to help teams understand how the infrastructure that surrounds their product, service or value stream influences their ability to work better, faster, safer and happier. This means understanding their capabilities for cloud, elasticity, serverless, containers, microservices and APIs.

    They rate their attitude toward open source, and how inner source does or doesn’t help them work better. It requires investigation into how they construct their route-to-live and how they architect the toolchain within these contexts.

    We look at security elements, such as secrets management, and some of the technology concepts that are currently emerging and that promise to drive us further forward; robotic process automation (RPA), blockchain and virtual and augmented reality.

    What to Expect From the Assessment of DevOps Capabilities

    This five-dimensional model allows teams and organizations to assess their current state on their DevOps journey. The data collected allows teams to self-discover improvements and accelerate progress, with the guidance of a qualified ADOC consulting partner. Organizations can compare team capabilities across their enterprise, pinpoint high levels of capability and turn local discoveries into global improvements. ADOC is a tool to measure and accelerate a DevOps journey.

    ADOC is now available as an exclusive benefit to Premium and Enterprise Members. Learn more about the assessments at: https://devopsinstitute.com/devops-assessment/