staging-devopsy.kinsta.cloud

Category: Application Performance Management/Monitoring

  • Microservices Explained: Not Your Father’s SOA

    Microservices Explained: Not Your Father’s SOA

    Microservices are frequently referred to as a variant or derivative of service-oriented architecture (SOA), if not essentially the same thing. While there are similarities and both are designed around the concept of services, that’s where the similarities end. Each was created around a different set of principles and intended to address different problems.

    Microservices architecture is built around key concepts that, when applied, not only differentiate it from other architectures but deliver advantages that accelerate software delivery and help to scale large, complex applications. To deliver on the promise of cloud-native, microservices must be loosely coupled so that, ultimately, they are independently deployable. Any microservice can be updated and deployed—just that containerized microservice—without requiring changes to other microservice(s). Loosely coupled microservices mean they are not sharing databases or maintaining state, for example.

    How big should a microservice be? Or, in other words, how much should it do? The answers range from ‘a single thing’ to ‘a small set of related code with high cohesion’. Another factor is that getting too granular can overrun a microservices-based application with large numbers of microservices, increasing complexity and making triage through observability and tracing very challenging.

    Scaling microservices-based apps is another important factor. Autonomous microservices can be replicated and scaled for performance and workload using container orchestration tools such as Kubernetes.

    Microservice communications are achieved through well-thought-out APIs created around the business or operational capabilities the microservice provides to anyone or anything engaging through the API. The API, and data provided through the API, are often referred to as ‘technology-independent.’ It’s probably better stated that microservice APIs are built using approaches like RESTful and GraphQL over networks that are not tied to any one specific operating environment, technology or programming language. JSON, YAML and XML similarly represent data that is transferable across technologies.

    The following diagram of a media application demonstrates the principles of microservices architecture. Microservices for scheduling media, digital rights management, tracking impressions and adding new ad insertions are loosely coupled, autonomous and have well-defined API interfaces. Each microservice can be changed, enhanced and deployed rapidly and independently of other microservices.
    Microservices SOA

    Service-oriented Architecture, or SOA, emerged to solve a very different problem; the overwhelming size and complexity of monolithic applications. Monolithic applications have very large codebases that often don’t do a good job of compartmentalizing functional or business logic. This makes changes to the codebase challenging even to developers who know much of the codebase well.

    Services in SOA were often used to gather a collection of similar business logic together and then share them as a service with other parts of the application, as needed. Technologies like message buses are used to make requests of a service and operate as traffic managers for requests across multiple services and other parts of the application. While reusability was a critical design consideration, SOA services were still quite large, and deploying services at high velocity was not an important design consideration. SOA services often take considerable time to code and test the service including interdependencies across other parts of the application before deploying as part of a larger software release.

    One important note: There are benefits and drawbacks to microservices and SOA architectures; neither is ‘better’ than the other. Which architecture to use when mainly depends on the purpose of the application you are building. For larger, more complex enterprise application environments that require integration with many other applications, you might choose SOA. That’s a better fit than for smaller applications that don’t require middleware elements for managing the requests within the app or between other applications. Microservices, on the other hand, are better-suited for smaller and well-partitioned web-based systems. They are becoming the standard for today’s cloud-native applications, and also are a great fit for developing a mobile or web application because they give developers more control.

  • Allstacks Adds Alert Capability to VSM Platform

    Allstacks Adds Alert Capability to VSM Platform

    Allstacks has added an alert capability to its software-as-a-service (SaaS) value stream management platform that automatically notifies DevOps teams when software project goals and deadlines are likely to be missed.

    The core Allstacks platform employs machine learning algorithms and artificial intelligence (AI) models to keep track of pull requests, commits and card changes via a set of dashboards that are designed to be accessible to anyone in an organization.

    The Allstacks Alerts capability makes it possible to notify those stakeholders via email or Slack any time a specific indicator, such as a pull request, has been open for four days, which would suggest risks of delays have increased. Support for Microsoft Teams will be added early next year.

    Adam Dahlgren, senior vice president of product for Allstacks, said the goal is to leverage the advanced analytics built into the platform to surface thoughtful observability insights versus simply firing off a series of generic alerts that lack any context.

    Value stream management (VSM) platforms such as Allstacks automatically take technical metrics collected via DevOps tools and correlate them to key performance indicators (KPIs) defined by business leaders. The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a highly-automated process using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business has grown as organizations realize how dependent they are on software.

    In fact, many organizations are discovering there is a clear disconnect between their business goals and software development processes. Business leaders are especially anxious to understand how a software development project delay might impact future revenue projections at a time when economic conditions are the most uncertain they’ve been in recent memory.

    VSM platforms also make it possible to track KPIs spanning multiple software development projects; the hope is that doing so will make it easier to see where resources should be reassigned as various bottlenecks are encountered. In the long term, Allstacks is also working toward adding scenario planning tools to make it easier for IT and business leaders to model “what-if” scenarios, added Dahlgren.

    It’s not clear how much organizations are willing to invest in VSM platforms, but the need for them is becoming more acute. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics. A SaaS-based platform should make it simpler to achieve that goal and to apply algorithms to what can quickly become a large corpus of data.

    Of course, it’s still early days as far as the adoption of VSM platforms are concerned. But there’s no doubt the divide between application development teams and the rest of the business is continuing to narrow. Less clear is to what degree that increased visibility will lead to a higher degree of empathy between dev teams and the business.

  • Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs exited stealth mode today to launch a platform that applies graph analysis to identify the depth of dependencies that exist within an application.

    Fresh from raising $25 million in funding, Endor Labs CEO Varun Badhwar said the Dependency Lifecycle Management Platform makes it simpler for organizations to manage dependencies within applications that can involve tens of thousands of components.

    Existing software composition analysis (SCA) tools are not able to as accurately identify the dependencies between software components because they generate too many false positives, he added.

    To address that problem, the Dependency Lifecycle Management Platform provides the equivalent of a credit risk score for each component employed with an application environment, said Badhwar.

    Designed to run out-of-band within a continuous integration process, the Dependency Lifecycle Management Platform is currently being made available via a private beta program.

    On average, bout 80% of an application is made up of open source components that developers downloaded from a repository. The challenge is that many of those components have known vulnerabilities. The Dependency Lifecycle Management Platform makes it simpler to both identify those vulnerabilities during the build process and find components that might be impacted by a newly discovered zero-day vulnerability, said Badhwar.

    Overall, the Dependency Lifecycle Management Platform improves the productivity of both application development and cybersecurity teams by streamlining vulnerability management, he added.

    Having a full understanding of their dependency graph also lets customers generate and analyze accurate software bills of materials (SBOMs) as applications are dynamically updated, noted Badhwar.

    In the wake of a series of high-profile breaches, there has been increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise and, even when provided with tools to identify vulnerabilities, there are simply too many alerts generated. In the absence of any context, most of those alerts simply wind up being ignored. In the meantime, the rate at which new applications are being deployed and updated isn’t slowing down, especially as more organizations embrace cloud-native applications that make it easier to rip and replace software components.

    It’s going to take years for organizations to implement DevSecOps best practices to teach developers how to build more secure applications, but that journey needs to begin with tools that make it simpler for developers to address issues before applications are deployed. The best way to combat application vulnerabilities is to make sure they don’t manifest themselves in code in the first place. Based on the number of vulnerabilities that continue to find their way into application environments, it’s apparent that the current processes being used to build applications are fundamentally broken.

    At this juncture, it will take years to fix the application development and deployment process, but as more secure applications eventually replace millions of insecure applications the overall security posture of organizations will steadily improve. The issue now is finding ways to achieve that goal before another known vulnerability leads to another major security crisis.

  • Forget Automation: Why IT Should Take UX Cues From Fine Dining

    Forget Automation: Why IT Should Take UX Cues From Fine Dining

    As a college student, I worked at a five-star Italian restaurant where I learned the discipline and practice of customer service. The general manager knew exactly which corner to stand in to get a view of every single table during service. They would gauge diners’ experience according to how they were interacting, their microsignals, how much food was left on their plate and the way they glanced around the restaurant. What does this intense attention to detail and individual customer experience have to do with running a service-oriented technology business? Everything.

    The tech industry is notorious for automating processes at the expense of personalization, and that aversion can extend to building the relationships necessary to produce a successful end product. Understandably, some companies and their developers prefer to keep relationships with their clients strictly functional because these connections are messy, people are unpredictable and nothing ever goes completely according to plan. It’s a dance we have to do over and again with every new client and project. 

    For those of us who wish to function as service-oriented tech companies, keeping on top of client and customer experiences requires us to stay attentive and listen with active care. Just like the veteran restaurant manager, we have to constantly scan our environment for cues of satisfaction and dissatisfaction.

    Service is More Than an End Product

    Before opening every night, the general manager would make staff hold long pieces of string to measure the angles and distance between tables to ensure they were straight and the edges perfectly aligned. Then, after telling staff the evening specials, he would randomly quiz them about the menu. What color is a fava bean? 

    Seeing the value of such old-school standards left a deep impression and helped me embed attention to detail as a foundational practice across the board, from designing good UX to cultivating relationships. Creating a desirable environment is about successfully orchestrating a million tiny details and always looking for tweaks to make the customer experience better. 

    That seemingly omniscient Italian from my earliest experience in the restaurant industry also taught me that being empathic goes hand-in-hand with the hard-nosed realities of running a service-oriented business. They showed me how to take care of people, how to make them feel good and how to read body language. 

    It might be easy to stereotype tech companies as impersonal dispensers of products (and their developers as cogs in the machinery), but we don’t want to just take orders. Our job is to become strategic partners from the ground up for long-term success, and that requires constant care and continual adaptation. 

    Mapping the Client Experience

    We must be willing to redesign how we work with customers and end users over and over again—it’s always changing because expectations are always changing, and market norms are always changing. The moment that we stop trying to get better through small incremental improvements is the moment we stop being service-oriented.

    In the same way that a restaurant has a sequence of service that maps a diner’s journey from the moment they enter the door, we can architect a customer experience from every touchpoint. 

    In the sales process, it’s valuable to layer in different people to create more relationship touchpoints throughout an organization, so, in our case, a new client meets a member of our operations team and then somebody from our engineering team in order to ensure that they feel fully supported. Then, we set expectations in terms of communication as part of a scripted onboarding experience. In our review meetings, we seek feedback to determine whether we have under-delivered and course correct if necessary. 

    The other thing I learned from that Italian restaurant is that no mistake is irredeemable. It doesn’t really matter if you get it right or wrong the first time, it is how you respond when the unexpected happens that matters. Turning a situation around after making a horrible mistake—even sending out a cold steak—can breed even more loyal customers because it demonstrates that you really care.

    The Creative Heart of Service

    Despite the image of tech as cold and distant, it’s important to recognize that coding and development itself is creative and we should seek to nurture a healthy environment so that people can perform at their best. To that end, it makes sense to think of your responsibility as running the entire length of the chain, from employees to clients and, finally, to end users. Finding humanity in the work along each link is key to building successful partnerships. 

    In the context of building products, we must be creative to design seamless, curated experiences for end users. There are plenty of apps that sit on someone’s phone unused before ultimately being deleted. The only way to grab the attention of people that share the same interests and problems is by understanding their needs. 

    To that end, we must always be asking our clients: What is the easiest point of entry for the user? Creating a low barrier is a quick win that in and of itself is an onboarding experience and an opportunity to build trust. 

    Equally, what may make one customer happy may not actually have any resonance in the wider market. If customers were only hiring us to write code, we would only be interested in meeting their expectations. The goal is not just to build products, but successful products that establish or reinforce a client’s reputable presence in the marketplace. 

    Adding Value Through Relationships

    When we stand in our metaphorical corner of the room to observe the customer experience, we are consolidating data from products that have millions of users and harvesting insight. We are not interested in quick fixes. Customer service and a focus on the end-user experience means being oriented to what the market wants, not designing in a vacuum. We can then continue to build value over time.

    In the restaurant business, the little surprise at the end of dinner adds value because it is unexpected. A complimentary after-dinner liqueur with a pithy origin story is a point of detail at its finest. Creating a richer, fuller customer experience can set a tech business apart in an exploding marketplace. For my old mentors, paying attention to every nuance from the beginning to the end is what defines five-star service.

  • Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Linux 6.0 promoted to Stable, Debian 12 will include closed-source binaries, and Google Cloud opens its first Africa region. (more…)

  • ServiceNow Acquires Era Software to Unify Observability

    ServiceNow Acquires Era Software to Unify Observability

    ServiceNow today announced it has agreed to acquire Era Software as part of an effort to add support for log data to the Lightstep observability platform the company acquired last year.

    Ben Sigelman, general manager for the Lightstep business unit at ServiceNow, said rather than reinventing the same log management capability that Era Software already has, it makes more sense to integrate that capability with the Lightstep platform that collects metrics and traces.

    The integration of those two platforms will then make it possible to unify observability rather than requiring DevOps teams to navigate two separate silos, he added.

    As observability continues to evolve and mature, the most immediate goal is to make it simpler to navigate the alert storm that inevitably ensues any time there is a disruption, said Sigelman. The alert storms generally occur after there has been a change made, but unraveling how exactly that change impacted an IT environment is challenging, he noted.

    An observability platform reduces the time and effort necessary to achieve that goal by surfacing a set of statistics that guide DevOps teams through that process, added Sigelman. The challenge, of course, has always been finding an efficient means of storing all the telemetry data that’s generated. In fact, as organizations start to deploy microservices-based cloud-native applications, many of them are starting to see the amount of telemetry data increase exponentially.

    Era Software uses an object storage system to index and analyze log data collected from cloud applications, Kubernetes and IT infrastructure platforms. The company has also made available in beta an Era Streams tool that reduces the volume of observability data collected without sacrificing fidelity by dynamically reconfiguring data pipelines in real-time.

    Once the acquisition is completed, log data analytics will then be shared with the IT service management (ITSM) tools that ServiceNow provides alongside the Lightstep observability platform. The goal is to make it easier to correlate those IT events with their potential impact on the business, said Sigelman.

    Era Software CEO Todd Persen said the long-term 10-year goal is to get to the point where issues are both automatically detected and remediated. In the meantime, the amount of context switching that IT teams encounter can be sharply reduced via a unified observability platform.

    There is, of course, no shortage of unified observability platforms these days. DevOps teams have also been relying on legacy monitoring tools that track specific metrics for years. The issue is that those legacy monitoring tools only track a narrow range of pre-determined metrics. As IT environments become more complex, the need to launch more open-ended queries to determine the root cause of IT disruption has become more pronounced.

    It may be some time before observability platforms are widely adopted, but the need for them is generally apparent to anyone managing a modern IT environment. Less clear is the degree to which observability platforms will remove the need for legacy monitoring tools; however, right now the focus should be on gaining as much visibility and transparency as possible into what are still opaque IT environments.

  • The Whats and Hows of APIs: A New Developer’s Guide 

    The Whats and Hows of APIs: A New Developer’s Guide 

    For those who are new developers, you may not know a lot about application programming interfaces (APIs). However, it is likely that you’ve used them before as a consumer or an end user, whether purchasing online, using business communication software to reach colleagues or sharing images from a monogram logo maker on social media platforms, for example. It makes knowing about them helpful, regardless of if you plan to make and use one yourself or want to understand how the tools you use work. 

    Although coding and developer tools can be daunting for the outside world, we’ll put APIs into a language that new developers (and even non-developers) can understand. In this guide, we’ll cover what APIs are and the different types that exist. You’ll also learn how they work and how you can use them. By the end, hopefully, you’ll be more comfortable with APIs and know how they impact you and your business.

    What Is an API?

    An application programming interface is a piece of coding used by developers to communicate between different devices, systems, or applications. It allows information to be passed on—allowing procedures to be followed across multiple platforms. Depending on the API, this could be transferring data, images, videos, text, files and other content, or allowing developers to connect through the use of backend-as-a-service (BaaS) to link their apps to the cloud. APIs are often used in a business context and for personal projects or other purposes. 

    Generally, APIs are concerned with the raw information and passing this on to another program rather than the appearance or visual side of these applications. Another set of coding is used instead to build the aesthetic and usability of the interface, while the API tends to be less visible to users. Nonetheless, they form an essential part of our technology stack today, allowing systems to integrate and become more agile, making applications easier for users to navigate.

    Image sourced from developers.facebook.com

    For example, when you refresh your omnichannel communications application, a request is sent to the API to check other linked programs for new messages on your social platforms or calls to your 800 numbers for business. These programs inform the API of new communications and send the appropriate data across. The API returns this data to the application you are using, enabling you to read the messages from here or notify you of no new calls.

    Types of API

    1. Private

    A private API is used internally within a team, created by developers who work for the company or organization. It can help make highly personalized APIs for the needs of your business and adapt the API as and when needed. Private APIs can’t be used or worked on by external developers, as it is purely for your in-house team. These APIs tend to focus on aiding your company’s productivity and project management across multiple applications.

    2. Partner

    Alternatively, partner APIs are used externally with companies that your business collaborates with. Often, this transfers information between businesses, such as within an affiliate scheme or for external postage of online orders. However, APIs can also share and update files such as your release of liability contract or emergency procedure templates. Developers from both companies can improve the API system to effectively share data between partners. 

    3. Open/Public

    Because they are not restricted to usage by specific businesses, open APIs (also known as public APIs) can be used by anyone. You may need a subscription to give you access to the API depending on how frequently you use it, although there are other APIs that are completely free to use. Once you’ve sorted out your access, any software developer can use the API to make changes and transfer information more easily between various software for several purposes. 

    Image sourced from mailchimp.com

    4. Composite

    By taking the responses of multiple programs and streamlining these onto one platform, composite APIs are essential for business and personal use. Or, vice versa, a composite API allows you to make requests of multiple platforms simultaneously. It is helpful for omnichannel management, tracking customer interactions, online faxing and purchases across various platforms. These tend to require little input from developers and are set up for anyone to use.  

    How to Use an API

    • Choose Your API

    As you may have gathered, APIs can be used for several purposes. When choosing your API, look for something relevant to the business that helps you complete the tasks you already do. The software and tools you use may have recommended APIs to try, or there may be APIs that similar businesses use. Do your research to ensure your API performs the right functions and works with your rephrasing tool, calendar software or other add-ons you use. 

    If you’re getting used to APIs, you may want to start with a free option. It means that if it doesn’t work as you hoped, you’ve not lost anything by trying. Many APIs have a free trial period or a free subscription tier with the basic functions, so you can get a feel for the API and decide if it works for your business. When you’re confident in your choice, you can invest in the other subscription tiers that tend to allow for additional users and added functionality.

    • Find Your API Key

    An API key identifies you as the user, authenticating your actions using the API and tracking your usage. It is crucial to have, particularly with subscription-based APIs, as without it you may not be able to perform certain actions, or your users of the API may be limited. Even if your API of choice is free to use and publicly accessible, there still may be an API key to keep your information and preferences stored and linked between your platforms. 

    Image sourced from developers.google.com

    Your API key may be issued as you sign up for the service, so remember this and ensure those in your business who need it can access it. Otherwise, you may need to request or pay for an API key, although this should be clear when you sign up for your chosen API. To increase your API security and avoid your preferences being altered, keep your API key private and limit who has access to it. If your account is hacked, you may need to request a new API key. 

    • Read the Instructions

    It can be easy to overlook the documentation and instructions an API comes with, assuming you’ll get the gist through practicing and by actually using it. Although this may be true to an extent, you could be missing out on useful functions or not using the API as effectively as possible. Likewise, you could get yourself into a mess, not properly setting resource requests and limits, leading to more issues for your business when using the API in the future.

    Set aside time to read the instructions and documents for your API or divide the workload between your management team. You may discover it comes with setup instructions or useful tutorials you can use with the rest of your teams. As you introduce more people to the API, the instructions ensure everyone uses it in the same way. It prevents confusion for your teams and enables them to build their confidence with the API more quickly. 

    • Set Up Your Requests

    Depending on the API, there may be suggested requests for you to set up or you may have to create and code your own. Following the instructions from your API can help with this, allowing your in-house developers to reach their full potential within the API and informing you of the coding structure to use. Nonetheless, there are plenty of tutorials online covering how to set up your API requests without relying on coding expertise.   

    Image sourced from developer.paypal.com

    Just because a request is possible doesn’t mean it’s always relevant to your business. Consider why you’re using an API and what you want it to do once you’ve set up your requests. If you’re new to using APIs, start with a few basic requests and build on these as you gain confidence and experience, using CI/CD best practices to ensure it runs well. It allows you to become familiar with using each request and ensure it works in the way that you intended it.

    Are You Ready to Use APIs?

    As technology progresses and software is developed, having APIs in place is becoming more helpful. Being able to communicate between applications can streamline your virtual receptionist service, incoming video calls and outgoing messages, for example, as well as accelerate cloud-native application development. Having one place to make your requests and display information from multiple platforms gives you more control in managing your tasks.

    If you’re still new to APIs, you don’t have to start using them for everything immediately. Take your time learning to use them for specific functions, getting familiar with them, and enabling your teams to adjust to using them. From this foundation, add new APIs or requests as they’re needed, personalizing them to your business and the tasks you complete. Over time, you’ll gain confidence in using APIs and build a strong network of requests to run your business effectively.

     

  • EvolveWare Further Automates App Modernization Tasks

    EvolveWare Further Automates App Modernization Tasks

    EvolveWare today announced it has added an Agile Business Rules Extraction capability to its Intellisys application modernization platform.

    EvolveWare CEO Miten Marfatia said the Agile Business Rules Extraction capability eliminates the need to freeze code development while applications are either being shifted to the cloud or refactored. Instead, the Intellisys platform will now keep track of updates to code and apply them once the application has been modernized, he said.

    Code updates can now be transferred automatically into the extracted business rules repository without affecting the rules that are not impacted by the updates. For rules impacted by the updates, a report is generated that highlights the changes. IT teams can now also update business policies and modernize applications concurrently via the repository that also keeps track of documentation such as diagrams, logic, database details and critical dependencies, said Marfatia.

    In addition to presenting logic in multiple formats, including pseudo-code, flowcharts, decision tables and business analyst language, it enables consolidation and optimization actions to be reverted to their original state if required.

    In general, IT teams have been struggling with application modernization efforts that require them to either lift and shift a monolithic application running in an on-premises IT environment into the cloud or refactor it into a set of microservices that run natively in the cloud. Eventually, most organizations will refactor monolithic applications, so the debate becomes to what degree to undertake those efforts before lifting and shifting an application into the cloud. Most monolithic applications were not designed to run in the cloud, so when the app is shifted it’s not uncommon for any number of performance issues to be encountered.

    EvolveWare claims that its Intellisys platform reduces the cost of application modernization by as much as 60% by eliminating much of the manual effort that would otherwise be required. Modernization efforts, in general, are hindered by manual processes that should be automated, said Marfatia.

    The issue that most DevOps teams encounter when modernizing an application is that it is not a task they regularly perform. As such, many of the processes required have not been automated with the same level of zeal they’ve applied to more routine manual tasks. The Intellisys platform is designed to enable IT teams to automate the most common tasks associated with migrating an application to another platform.

    The biggest driver of those migrations these days has been digital business transformation efforts that have accelerated since the start of the COVID-19 pandemic. Organizations of all sizes are moving applications to the cloud to ensure greater availability and resiliency to limit the amount of disruption that might be encountered should the pandemic worsen, or in case some other unexpected event makes accessing IT services difficult.

    The challenge, of course, is moving applications—and the database they depend on—from one platform to another is not easy. It can take some organizations months, sometimes even years, to make the transition. Given the backlog of applications that many organizations are looking to migrate to another platform, it’s clear there is a need for much higher levels of automation to accelerate a transition that, on its present trajectory, might take years to complete.

  • Latest DORA Report From Google Surfaces Raft of DevOps Challenges

    Latest DORA Report From Google Surfaces Raft of DevOps Challenges

    The annual Accelerate State of DevOps 2022 report published today by the DevOps Research and Assessment (DORA) team at Google found the percentage of high performers is at a four-year low, with the percentage of low performers rising dramatically from 7% in 2021 to 19% in 2022.

    Based on a survey of 1,350 DevOps professionals, the report evaluated organizations based on the five DORA metrics: Deployment frequency, lead time for changes, time to restore service, change failure rate and operational performance. The DORA team also identified clusters of DevOps teams ranging from “starters” to “flowing” based on their overall maturity. Only 17% of respondents achieved a ‘flow’ state defined by high reliability, high stability and high throughput characteristics.

    The DORA survey sample shifted this year to include more respondents that are earlier in their careers than in previous reports. However, Claire Peters, DORA research lead at Google, said that while there are a lot of factors that impact those metrics, the current hypothesis is that the COVID-19 pandemic has taken a toll on DevOps productivity as more DevOps professionals continue to work remotely.

    The report noted a marked shift in deployment targets requiring new skills, with 54% of respondents now working with container artifacts.

    Overall, the report finds software delivery performance is beneficial to organizational performance when operational performance is also high. The challenge is the number of organizations that have achieved high operational performance is relatively small. In fact, the report also noted that site reliability engineering (SRE) practices had a negative impact on software delivery performance until an organization achieved a high level of SRE maturity.

    The report also concluded that organizations that built software on and for the cloud tended to have 1.4 times higher organizational performance than those that didn’t. The percentage of respondents using public clouds is 76%, up from 56% in 2021, while the number of respondents not using a cloud stands at 10.5%. Usage of multiple public clouds is at 26%, while 35% reported using a private cloud.

    Less clear is the impact on DevOps teams of shifting application security left. The report suggested the biggest challenge organizations face when it comes to achieving application security have more to do with cultural issues than any technical shortcomings. The report notes that organizations that focus on accelerating software delivery without implementing meaningful DevSecOps best practices find themselves in a vicious counterproductive cycle that results in applications being successfully deployed in production environments less often.

    Peters noted that there is greater developer fatigue because organizations attempt to address security issues either just before an application is deployed or they remediate applications after they are deployed. Organizations that have low levels of security practices are 1.4 times more likely to experience developer burnout.

    The DORA team used both the supply-chain levels for secure artifacts (SLSA) framework defined by Google and the Secure Software Development Framework (SSDF) defined by the National Institute of Standards (NIST) to evaluate organizations. The most widely-adopted practice is application security scanning within a continuous integration/continuous delivery (CI/CD) system, with 63% of respondents reporting these tools are “very” or “completely” established. Preserving code history and using build scripts are also highly established, the report finds.

    In general, Peters said the report suggested the biggest predictor of application security success was whether an organization had a high-trust, low-blame culture focused on performance. Organizations that have these cultures tend to have higher organizational performance. Similarly, organizations with teams that felt supported through funding and leadership sponsorships tended to have higher organizational performance, the report noted. In addition, team stability and positive perceptions about one’s team also tended to lead to higher levels of organizational performance. Lastly, companies that offer flexible work arrangements tended to see higher levels of organizational performance.

    Each organization, as always, will implement DevOps best practices in ways that best fit its internal culture. However, the latest DORA report makes it clear that the more empowered a DevOps team is the more proficient they tend to become.

  • Scaling Predictive Analytics With AIOps to Drive Next-Gen SRE

    Scaling Predictive Analytics With AIOps to Drive Next-Gen SRE

    Enterprise systems are only as valuable as they are reliable, in the sense that they don’t suffer excessive breakdowns. Otherwise, companies experience costly downtime and added stress for engineers due to the additional burden of managing issues. This critical function of ensuring systems run reliably and optimally, at production scale and with minimum human intervention, is the purview of site reliability engineering (SRE) teams.  

    The SRE professional’s job is to reduce human toil by developing and implementing reliable and highly scalable systems that optimize software and applications. Their goal is to proactively identify and, where possible, anticipate potential disruptions to minimize risk and ensure optimal system performance. However, to be successful, SRE teams require a level of enterprise-wide visibility that can be difficult to provide without the right tools to capture and analyze data at the appropriate level of detail. 

    Let’s examine how artificial intelligence for IT operations (AIOps) can support the SRE mission by connecting data enterprise-wide for unprecedented visibility and control of systems and processes, enabling auto resolution of most issues and more efficient triaging for the few remaining cases where SRE teams must collaborate around a fix.

    Challenges of Complexity and Scale in Pursuing SRE Excellence

    As more enterprises digitize their operations and move to greater automation, their IT operations must leverage all data assets skillfully in order to improve reliability and reduce human toil. The SRE profession arose to satisfy this need, with a focus on monitoring systems, accessorizing automated releases, understanding change impacts and automating some of the most common system processes. 

    To do their job effectively, SRE teams need a wide variety of data and analytics capabilities at their disposal. This includes the ability to deep dive into descriptive and diagnostic analytics to look backward and at present conditions to discover what happened in the past and why and to baseline current operations. But this is just the beginning. The true value  of SRE comes with the scaling of predictive and prescriptive analytics to draw on that historic data and apply detailed analysis to generate predictive insights into what is most likely to happen in the future; these insights are the basis for identifying proactive measures that can serve to address any potential problems and optimize those future outcomes, minimizing adverse impacts on operations 

    These analytic capabilities must be fed by robust data that comes from across the entire IT estate. Developers assigned to the SRE role face an especially strong mandate to have this holistic visibility as they plan, build, test, release, monitor and secure systems; their job is hampered to the extent that organizational silos or problems of scale get in the way of achieving that visibility. It is here that AIOps can help evolve IT operations to become more proactive and autonomous by scaling the power and reach of predictive and prescriptive analytics. 

    AIOps Empowers the SRE Mission Enterprise-Wide

    AIOps is an essential tool for the SRE community in the battle to reduce operator stress, configure IT systems to be more stable and run efficiently with less human intervention. AIOps employs artificial intelligence (AI) and machine learning (ML) for observability, context, normal behavior analysis and automated health diagnostics. This, in turn, enables anomaly detection in real-time and closed-loop automatic resolution of most issues. 

    For example, AIOps can uncover patterns showing that, 90% of the time, a particular alert in the organization’s payment system triggers a seemingly unrelated alert within 15 minutes. Moving forward, this gives SRE teams a 15-minute head start on addressing that secondary alert; the discovery forms the basis of an auto-resolution or triaging scenario that uncovers the underlying cause of both alerts and provides a permanent fix. 

    That’s just one illustration of how AIOps uses advanced analytics to discern subtle patterns in data to predict when and where problems may occur, so proactive fixes can automatically be prescribed to head off those problems. In this way, AIOps is the technology backbone that scales and automates the SRE team’s insight and control across all system assets and dependencies, a critical tool for continuous optimization of performance with minimal human intervention. 

    Conclusion: The Game-Changing Role for AIOps in SRE

    AIOps is a game-changer for the critical function of site reliability engineering. Powered by a potent blend of advanced analytics on robust data coming from systems across the enterprise, AIOps delivers unprecedented visibility and control for SRE teams in their mission to reduce toil and ensure the reliability and resiliency of enterprise systems. The result is less human intervention and enhanced value from IT systems that are made more robust, more stable and more efficient.