devopsy.kinsta.cloud

Author: Bill Doerrfeld

  • What Are the Seven Layers of the OSI Model?

    What Are the Seven Layers of the OSI Model?

    Working in the software field, it’s not uncommon for engineers to refer to different “layers.” Perhaps you’re working with protocols at the “networking layer” or evaluating a solution that sits at “Layer 4” or “Layer 7.” Although these concepts are obvious to some, not everyone knows what these layers refer to. To get you up to speed, below, we’ll define the seven layers of the OSI Model.

    What Is the OSI Model?

    The Open Systems Interconnection model (OSI model) is a conceptual model to help visualize a computerized network. Made up of seven layers, it represents the distinct levels that make up an end-to-end computing system. In the spirit of promoting open interoperability, the model is intended to represent a universal standard that’s agnostic to a specific technology or vendor.

    The OSI Model was co-conceived by International Organization for Standardization (ISO) and Internet Engineering Task Force (IETF) and first published in 1984. It has since been redefined as ISO/IEC 7498-1:1994. Although the OSI Model has been around for decades, it’s still referenced quite often.

    The Seven OSI Model Layers

    The OSI Model is split into seven abstraction layers: Physical, data link, network, transport, session, presentation and application. You can think of the bottom one, Layer 1 (the physical layer), as the closest to the most rudimentary electrical connections. The farther up you rise, the closer you get to Layer 7 (application layer), which is the most user-facing category.

    1. Physical Layer

    The physical layer, Layer 1, represents the lowest level of data transmission. This category refers to raw unstructured data bits—and the process of converting them into electrical signals for a device to read. “Physical” hardware like network hubs, modems, adapters, cabling and network controllers work in this layer. Bluetooth, Ethernet and USB describe physical layer specifications.

    The data link layer deals with data packaged into frames. Technologies in this layer assist in node-to-node data transfer, and the protocols here describe how to establish and terminate a connection and how the connection should flow. The data link layer is further divided into two sublayers: Media access control (MAC), responsible for how nodes connect with one another, and logical link control (LLC), which checks for errors and orchestrates the frame flow and synchronization. An example data link layer protocol is Point-to-Point Protocol (PPP). MACsec also can work to apply encryption at this layer.

    3. Network Layer

    The network layer is responsible for sending and receiving data frames structured in packets. Technologies in the networking layer use routers to send packets to nodes on different networks. The network layer might split or fragment the message if it exceeds the maximum network packet sizes. You’re probably familiar with the network layer if you’ve looked up your IP address—the network layer uses the IP protocol (or other logical protocols) to find locations. Such protocols specify a message along with the address of the intended recipient node.

    4. Transport Layer

    The transport layer deals with the transmission of data segments, which are sequences of data at variable lengths. The goal of the transport layer is to optimize data transmission by performing data segmentation and adjusting the size of the package or the rate of transmission. Transport layer protocols include TCP and UDP. Tunneling protocols also operate at the transport layer. The OSI Model also defines five classes of the connection-mode transport protocol.

    5. Session Layer

    The session layer handles the communications between two or more computers. Protocols here are used to create a “session” between entities, which is common in applications that use remote procedure calls. The session layer handles the connection and authentication between a client or server, including actions like logon, look up, log off or session termination. DNS, along with name resolution protocols, operate in the session layer.

    6. Presentation Layer

    The presentation layer is about data translation and formatting. In this layer, protocols handle things like encryption, decryption, compression and decompression. The goal of the presentation layer is to transform data in such a way that it can be sent over a network in syntax that fits the constructs specified by the application layer. For example, technologies that serialize data structures to XML or JSON can be thought of as working for the presentation layer. This sort of data translates into what is graphically displayed for the end-user.

    7. Application Layer

    The application layer is the top layer of the OSI Model and sits closest to the end-user application. User-facing software directly interacts with the application layer through functions like file sharing, message handling or database access. High-level protocols such as HTTP and FTP are used in this layer to share resources. Web browsers and email clients are examples of applications that interact with the application layer.

    The OSI Models: A Helpful Taxonomy

    There you have it—a primer or refresher of all seven OSI Model layers. It’s important to note that the model does not intend to serve as an implementation specification itself—it’s purely a conceptual framework. But it does help provide context into where tools operate and how they interact with elements of a distributed computing system.

    In the context of DevOps technologies, Envoy-based service mesh is often described as working on Layer 4 (the transport layer) and Layer 7 (the application layer). Or, since eBPF filters network frames, it can be said to work at Layer 2 of the OSI Model.

  • Majority of Open Source Devs Open to Change Jobs in 2022

    Majority of Open Source Devs Open to Change Jobs in 2022

    Open source is the foundation of most modern software applications. Now more than ever, retaining developers with experience working on and with open source projects is critical to maintaining software development agility. Yet amid the Great Resignation, it can be challenging to keep talent happy—organizations must demonstrate a commitment to employee benefits, mentorship and cutting-edge technologies to remain competitive.

    The EDB Open Source Talent Survey 2022 surveyed over 1,400 developers and DevOps professionals working on open source projects. Below, we’ll highlight the key takeaways about their volume of work, the quality of on-the-job training and top motivators that could influence workers to take a job elsewhere.

    The Great Resignation Persists

    It’s not news that IT is under mounting pressure to deliver new features and applications to meet surging digital demands. As a result, the amount of work has increased across the board. The report found that 67% of respondents said their volume of assigned work has increased in the past 12 months.

    Employer favorability has also declined slightly—28% have a less favorable view of their employer over the last 12 months. Although 46% are satisfied with their current job, 44% are satisfied but would be open to new opportunities. And 10% said they were not satisfied with their current position. Taken together, that means 54% are open to or actively looking for new roles.

    Mentoring: An Enticing Benefit

    So, what are the main drivers that would influence IT workers to change jobs? It’s no surprise that increased pay and benefits are a top reason behind most resignations. However, salary is not the only factor—43% say improved career opportunities influence a job shift, a steep rise from 21% in 2021.

    On-the-job mentorship and training are also becoming more desirable. A little over a third (38%) said that better access to mentorship would make them consider another job opportunity. This was followed by working with more cutting-edge technologies (32%), greater access to training and certifications (30%) and allotting more time for open source projects (19%).

    Interestingly, one-fifth of responders who said they were satisfied with their current employer said their organization introduced a mentoring program in the past year. This indicates that investment in employee career advancement helps increase morale and retain skilled workers.

    Career Advancement And Training

    Out of the above reasons developers are open to switching jobs, one factor in particular is increasingly important: Working with cutting-edge technologies. This figure doubled in the last year, rising from 16% to 32%. Most engineers prefer not to work with cumbersome legacy technologies or manage rising technical debt. And if an organization isn’t evolving its software infrastructure, employee skillsets become stale.

    Working with new open source or cloud-native technologies can help retain workers, but will likely require training. In terms of specific categories, 41% said that training in emerging technologies, like cloud, is a favorable factor in considering another job opportunity.

    From a security perspective, ongoing training is also vital to staying on top of emerging exploits. As a result, 43% said security training is an interesting perk when considering a job shift. These areas are followed by training on core technologies like database and infrastructure (38%) and training on compliance (37%).

    Final Thoughts

    Open source software is pervasive and at the heart of today’s digital innovation. Nearly all applications depend on some form of open source software, but it’s no less prevalent in the DevOps sphere, where open source projects are used in continuous delivery, container orchestration, observability and a multitude of other stages of the software life cycle.

    Supporting the needs of skilled labor will be necessary to leverage the benefits of open source projects. As such, organizations will require not only competitive wages but also relevant training and investment into cutting-edge technologies to retain such developers.

    Another factor that could drive workers away is unnecessary toil, which can negatively affect morale. A company’s environmental, social and governance (ESG) initiatives can also affect its talent pool. Furthermore, a commitment to high-quality developer experience can ensure the needs of developers are heard and respected.

    The EDB Open Source Talent Survey 2022 surveyed over 1,400 application developers and IT professionals from around the world. It targeted open source technology users, specifically those holding application development, information technology and operations titles. For additional insights, you can read the full report here.

  • The Quest To Unify With GraphQL, The Modern Data API

    The Quest To Unify With GraphQL, The Modern Data API

    There is an ongoing trend in enterprise software: Using GraphQL as an aggregation layer to unify access to underlying data sources and REST APIs. Some call this the supergraph, and others refer to it as a meta layer. The idea is that by providing a more consumable layer to a wide range of internal sources, frontend developers are better equipped to access whatever data they need when constructing applications. But the quest to unify all data sources into a single schema doesn’t come without its share of trials.

    GraphQL adoption is steadily increasing, with significant large enterprises making up some of the early adopters. For example, Netflix engineers recently shared how one approach gaining traction is “GraphQL microservices (GQLMS) as a backend platform facilitating rapid application development.” As the use of GraphQL increases across a large enterprise, though, scalability and security hurdles present themselves. These include retaining proper authorization throughout multiple layers and mitigating the risks of an inherently open schema.

    I recently met with Hasura CEO Tanmai Gopal to discuss why GraphQL should be used as a middleware element to access and expose underlying datasets and APIs. According to Gopal, GraphQL is becoming the data API for modern applications—this could be a massive positive shift. However, the potential downside is around the time involved in integration. Thus, the key will be automating the integration of data sources so that developers and DevOps teams can focus on the apps and services they’re building instead of maintaining the data model itself.

    The Underlying Issue: Data Access

    “Data access is a bottleneck,” said Gopal. “It needs to be self-service.”

    On one side, there are data producers, such as databases, internal services and external SaaS services. On the other side, there are the clients that consume this data, such as mobile apps, web apps, microservices and APIs externalized for third-party developers.

    The problem, according to Gopal, is that the link between both sides is increasingly challenging to implement. It takes time to integrate with HTTP-based APIs and parse JSON payloads. The exchange protocols are dissimilar and you must solve for performance issues, caching and concurrency in data access. What’s more, the authorization context must be maintained for all data sources. These issues are exacerbated since not all developers are accustomed to the nuances of maintaining integrations.

    Frontend developers want to communicate with a centralized data store, but also need to mix and match various sources. At this point, Gopal explained, a data access layer is necessary to handle the communication between both sides. Such a layer requires some integration automation to truly get APIs to developers at the edge. And it also requires a simple, unified schema—this is where GraphQL comes in.

    Solution: A GraphQL-Based Data API

    “GraphQL is an absolutely delightful API to consume,” said Rajoshi Ghosh, co-founder of Hasura. “Using GraphQL as a data API can remove a lot of requirements of legacy knowledge of integration systems and how to securely fetch data.”

    The concept involves using GraphQL as an intermediary data API—this would consume all sources, whether they are RESTful APIs, GraphQL services, an Amazon Aurora database or a PostgresSQL-style database—and unify them in a more accessible, pleasing construct. To create a unified API over these disparate sources, a middleware solution must map API resources to logical models and methods and add authorization rules to logical models, explained Gopal.

    Although GraphQL enables developer agility, it’s the part in the middle that’s difficult to assemble. Building these connectors from scratch requires a lot of relearning and tedium to maintain, Ghosh said. And to truly cater to all data sources, organizations will likely need to craft custom plugins for legacy sources, he added.

    Solving Unified Graph Problems

    Data-driven initiatives are a common technology goal, but the breadth of data sources is rising. GraphQL can play an important role in uniting these sources and providing flexibility for frontend developers to call precisely what they need. A unified graph is thus a boon for developer experience but will be challenging to set up from scratch.

    Arguably, authorization is the biggest challenge when approaching GraphQL as an aggregation layer for multiple APIs. Any system that unifies multiple backend APIs must ensure that only the person with the correct permissions can access underlying data. A unified GraphQL layer must retain granular permissions that are endpoint-centric and unique to the specific caller.

    “Most enterprises don’t have a good authorization story,” Gopal said. Implementing authorization for data APIs is hard, Gopal said, as it’s unlike REST where the user ID can literally be specified within the URL request. These kinds of fine-grained attribute level entitlements must be recreated as a policy engine and applied to the graph API as well. For example, Hasura implements authorization by using a token that scopes the entire experience to the particular user.

    The Future of Unified API Strategies

    Looking to the future of this area, Ghosh noted that frontend stacks are becoming more robust and code in the backend is essentially becoming business logic deployed as serverless functions. And in this new reality of increasing abstractions, the role of modeling experts will likely become more important.

    Furthermore, GraphQL must go beyond read-only capabilities to embrace another trend—real-time. Although most GraphQL APIs retrieve persistent data, GraphQL-based data brokers must also evolve to implement streaming, said Gopal, as real-time data and event-based subscriptions are becoming more common.

    Today, you probably don’t need to unify all your sources into a unified data model all at once. This activity will likely be relegated to particular business domains or products to help them accelerate and demonstrate a proof-of-concept. But in the coming years, there will be mounting pressure to adopt a unified approach, Gopal said. “In a few years, if you don’t have a unified API strategy, you’ll have a massive problem.”

  • DevOps Is Not a Role — It’s a Culture

    DevOps Is Not a Role — It’s a Culture

    The full-stack developer is becoming increasingly rare these days. Due to the accelerating complexity of modern software development, programmers often specialize in specific languages, frameworks or levels of the software stack, such as frontend or backend.

    These same fractures seem to be occurring within DevOps, too. Nowadays, large companies no longer have one strain of DevOps—there are often many flavors of rapid deployment and various DevOps toolchains used across an organization’s development teams. DevOps now requires specific training in the nuances of each cloud service provider’s platforms, too, requiring specialists trained on individual cloud platforms, like AWS, Azure or GCP. The role is expanding and taking on new forms, with platform engineering and site reliability engineering coming of age.

    Therefore, companies should be viewing DevOps not so much as one specific role or a set of tools, but as a culture. I recently met with Sashank Purighalla, CEO and founder of BOS Framework, to gather insights into the evolving role and culture of DevOps. According to Purighalla, “DevOps is a combination of culture, practices, processes and tools.” Below, we’ll identify the challenges that come with introducing DevOps and consider the right blend of technology, human specialists and governance required to get the job done.

    The Challenges of Implementing DevOps

    One challenge of implementing DevOps is simply defining the position itself. “DevOps is not really a job,” Purighalla explained. Instead, it encompasses many aspects, such as CI/CD, provisioning, maintenance, and compliance, all of which now adopt a plethora of different tools. There is also overlap between CloudOps and DevOps, an ambiguity that makes it tricky to write a job description for a DevOps engineer.

    Various roles make up the teams responsible for modern cloud-native operations. In the same way that programmers have particular specialties, DevOps has specialized areas too. This segmentation might be based on the cloud vendor suite or the tools in use, such as familiarity with Jenkins, Docker or Kubernetes. Particular domains, such as DevSecOps or BizDevOps, may require dedicated focus as well. Purighalla shared some example roles that often exist in a modern CloudOps team:

    • Cloud architect
    • App architect
    • Security expert
    • Compliance expert
    • DevOps engineer for AWS
    • DevOps engineer for Azure
    • SRE for AWS
    • SRE for Azure

    Complicating things further, DevOps can transcend cloud-based systems and be applied to on-premises or edge network maintenance. Given the many possibilities, crafting a job description for a DevOps position requires “awareness of and vision for how you want to build the DevOps function in your organization,” said Purighalla. Unfortunately, most people don’t have a clear picture of where to begin, he said. Setting this roadmap will vary from sector to sector and require intimate knowledge of and context about the company and its technological assets.

    DevOps Shouldn’t Create Another Wall

    DevOps is a mechanism to deliver high-quality code more quickly—this business outcome has been the guiding principle since its origin. To get there, DevOps sought to place development and operations ‘in the same room’ to reduce friction. Yet, in some organizations, DevOps emerged as an entirely new role on an org chart. “In certain cases, it created a wall,” says Purighalla. “Developers can’t think beyond when they hand off code to the infrastructure team.”

    If this wall stays in place, it could further divide team motivations. Of course, building a healthy DevOps culture will vary from company to company and will require clarity about the end goal. But creating common incentives could include shifting left some security and provisioning responsibilities so developers have more perspective and can participate in DevOps.

    Another reason to embrace a DevOps culture is simply the talent scarcity in this arena. This is a problem facing businesses of all sizes. Startups may not be large enough to hire a DevOps or site reliability engineer, but are beginning to see the necessity of greater focus on reliability and compliance as a core business function, says Purighalla. Enterprises typically have multiple clouds and hybrid environments, which are challenging to find talent to support. Middle-market companies often lose out to the attractiveness of startups and the big bucks of large corporations.

    Outsourcing DevOps: Is It Ever a Viable Option?

    So, given that it is so challenging to find engineers, is outsourcing DevOps ever a viable option? According to Purighalla, “outsourcing is a good option if your company has pre-built solutions for clouds and if it’s able to give you similar capabilities without requiring ground-up custom work.” A cloud enablement solution could be used to reduce the barrier to entry but is never a replacement for an entire DevOps practice.

    The reason is that software programming is a creative engineering process. “I’ve never found an engineer that does the same thing every time.” People continue to experiment with a ‘build and fix’ mindset. This means that, in general, hiring external engineers is tricky as they don’t have intimate knowledge of the system at hand.

    Furthermore, a platform that applies a standard way of working with multiple cloud providers must be flexible and open to change, as backend infrastructure is constantly evolving. As such, DevOps must be viewed as something that’s much more continual and requires ongoing maintenance. It’s not something you can outsource once and be done with.

    “It’s becoming like accounting—you’ll fail an audit if you don’t do it,” said Purighalla. “Outsourcing needs to be viewed that way. You need to bring in a cloud enablement solution in combination with experts. You can’t have one or the other.”

    DevOps: Not Just a Role or Toolset

    Many assume that DevOps is just a set of tools. Instead, some experts argue that DevOps is more of a combination of varying roles, tools and processes. “DevOps started as a model—it’s not a tool,” Purighalla reiterated.

    In essence, it’s more of a culture than a specific job title. And when viewed this way, organizations can begin to eliminate silos, which DevOps ought to eradicate in the first place. With the right technology and collaborative spirit, a company can create a culture that meets the goals of efficiency that DevOps aims to achieve.

  • 5 Mean-Time Reliability Metrics To Follow

    5 Mean-Time Reliability Metrics To Follow

    Most folks working in DevOps or SRE roles are familiar with metrics like mean-time-to-recovery (MTTR). Keeping track of the average time a team takes to respond to incidents is crucial to identifying bottlenecks in the support process. It’s also something executives like to show higher-ups when sharing a snapshot of overall platform performance. However, focusing on one single metric might be missing the greater picture.

    For example, how long did it take to discover the incident? How long did it take from discovery until action was taken? What was the timeframe between filing a ticket and updating all clients that had a bug? When can you say you’ve completely resolved an issue? As you can see, there are many potential metrics that could inform software reliability and the platform engineering process. “One number is never going to tell you a complete story,” said Emily Arnott, community relations manager, Blameless.

    I recently met with the Blameless team for a closer look into mean-time reliability metrics. Below, we’ll explore the nuances behind five different types of MTTX metrics and consider the business value of keeping tabs on each type.

    1. Mean-Time-To-Detect

    Mean-time-to-detect is a measurement of how long it takes, on average, to detect that an incident is present. This often happens automatically within a monitoring system. Perhaps a tool sends out an alert when latency meets a certain threshold, for example. But, detection could also come from other sources, such as a customer complaint.

    For example, consider Log4j. Perhaps a runtime vulnerability scanning tool noticed one of your components is impacted by a novel CVE and automatically sent a notification to the appropriate team channel.

    2. Mean-Time-To-Acknowledge

    Now, just because an incident is detected doesn’t mean it’s immediately acknowledged. Mean-time-to-acknowledge, then, is a measurement of how long it takes a human being to realize the incident and begin to act on it.

    In our CVE example, this would be the time between vulnerability detection and initial response. For example, the on-call incident manager received a vulnerability notification, read the exposure details and then filed a JIRA ticket and contacted the relevant team members.

    Many factors might extend mean-time-to-acknowledge. Perhaps someone isn’t logged into Slack, or a hardware issue stalls the notification. Alert fatigue may also get in the way, or there may be a reluctance to file a ticket and introduce more toil. Depending on the severity of the incident, someone simply might not believe the alert is worth responding to.

    3. Mean-Time-To-Recover

    Now, the following metrics are a little more open to interpretation, but we’ll do our best to define each. Mean-time-to-recover is the average time it takes to introduce a temporary fix after discovering an incident.

    For example, if a particular region is experiencing outages, engineers might temporarily divert traffic to a more stable server. This is not a permanent fix, but the system recovers and operations are generally unaffected. This helps maintain the status quo while a more permanent solution is ideated, tested and applied.

    4. Mean-Time-To-Repair

    Mean-time-to-repair (or restore) is the mean time it takes to issue a permanent repair to a system after discovering an incident. In order for a system to be considered fully repaired, it has to not just be working, but working robustly.

    For example, let’s say the incident in question involves performance issues. Perhaps a patch is issued to the core branch to remove bulky code that’s causing slow load times for clients. Mean-time-to-repair introduces a more permanent solution but still might not be the complete resolution to the problem.

    5. Mean-Time-To-Resolve

    Mean-time-to-resolve can be thought of as the average time between when an incident occurs to when the issue is completely resolved. Not only is the core codebase patched, but all clients reliant upon the software have been updated, as well. Lessons are learned and mitigation plans are set to respond to similar incidents or vulnerabilities in the future.

    Mean-time-to-resolve is about resolving the incident entirely, said Jake Englund, senior site reliability engineer, Blameless. This includes addressing the underlying fundamental contributors, completing all logs that remain on the back burner and following up with a retrospective.

    Using Mean-Time Metrics

    Mean-time metrics can provide a quantitative picture of incident response performance, which can be valuable for overall business operations. Mean-time-to-acknowledge, for example, can expose gaps in the remediation process, such as cognitive strife in reporting incidents, said Matt Davis, intuition engineer, Blameless. Understanding these technical and human factors are the first step to making the resolution process swifter.

    Of course, the above metrics rely on incident data, which may not always be a top priority. According to Davis, encouraging a culture that declares incidents—even minor ones such as a configuration change—can improve knowledge sharing within a team. “If you declare an incident, you could enact more systemic change,” added Arnott.

    Limitations of Mean-Time Metrics

    These mean-time metrics do have some limitations. “A number is only one part of the story,” said Davis. As a result, teams might struggle with deciding precisely what to detect. MTTR can be a helpful metric, but it’s the context that matters, he explained. Therefore, tracking multiple metrics can help provide a more sophisticated, nuanced picture. This involves looking beyond averages to consider outlier events, added Englund.

    There are also semantic nuances between the MTTX metrics defined above. “There’s a lot of ambiguity around these words,” said Davis. As a result, organizations might compute each figure differently. Some of these figures use time-markers which may not be technically possible to track consistently, especially since each incident is unique. Demarcating the precise moment an incident began might require guestimation. You might know when a service is fully restored, but the lasting customer perception is harder to gauge.

    Also, another potential downside is that mean-time metrics could easily be manipulated or misinterpreted, whether deliberately or inadvertently. Operations leads might selectively recall specific windows when showing MTTX metrics to higher-ups, leaving out other statistics that paint a different picture.

    Treat MTTX As A Guidepost

    Improving incident response is becoming mission-critical to maintain fully-functional systems as things like outages, downtime, slow speeds and zero-day vulnerabilities can negatively impact user experience. Sometimes, these issues must be addressed immediately to maintain SLAs.

    But tracking reliability averages isn’t all that simple, and they will likely mean something different to each organization. “It’s about embracing complexity and asking the right questions,” said Davis.

    In summary, mean-time reliability metrics provide helpful insight into the ongoing state of incident response. Yet, such metrics shouldn’t be imposed as a strict target — instead, they should be viewed as an informative guidepost. “Metrics can help you find what is discussion-worthy, but it’s not a discussion itself,” said Arnott.

  • Quality Is a Top Challenge for Data-Driven Projects

    Quality Is a Top Challenge for Data-Driven Projects

    Software systems continue to produce more and more data. And making use of it has proven benefits — so much so that many analysts have, over the years, referred to data as the new oil. As a result, the majority of organizations are expending effort into refining their data — in fact, a recent study found that 84% of organizations have either already deployed or have data-driven projects on their roadmaps.

    Corporations like Facebook and Google are the poster children for business models that harvest and monetize end-user data. However, this is only one aspect; valuable data is being produced by internal systems as well, which, if leveraged correctly, can provide insight into software observability and increase process automation for DevOps teams and developers. For example, time-stamped application logs are necessary for informing SLOs to maintain reliability standards. There is an ongoing parallel investment into AI/ML deployed with cloud-native tools to act upon production data to drive further business growth. As such, 63% of IT decision-makers say new revenue opportunities have emerged due to data and analytics.

    The 2022 Data & Analytics Study, conducted by Foundry (formerly IDG Communications), explored how data-driven initiatives continue to be an important investment area for executive leadership. Below, I’ll review the key results from the survey to consider how organizations can continue to make intelligent decisions now and into the near future.

    The State of Data-Driven Investments

    We undoubtedly live in a data-driven world, and investment in related projects continues to rise. More than half (55%) of IT decision-makers plan to increase their data-focused investments — the report found the average spend to be $12.3 million in the coming year. This figure rises to an average of $23 million for financial services, which makes sense given the nature of modern banking.

    Naturally, the use of analytics platforms is increasing in tandem with the amount of data generated. In terms of specific analytics tools, 50% of respondents said they used business intelligence platforms while 47% used relational databases and 19% planned to invest in them in the next one to two years.

    We’re also noticing an increasing use of cloud-based solutions. For example, 27% of an organization’s data analytics workloads now run in the cloud. The report also found an uptick in cloud-based enterprise-scale data warehouse technologies, an area that shows signs of increasing in the coming year.

    Common Objectives

    So, what are the most common driving factors behind these types of projects? Well, automating internal business processes is the top goal for data-driven projects—half of IT leaders described this as a primary objective. This is closely followed by other ambitions such as improving customer insights (46%), aiding customer support (43%) and automating IT operations (43%).

    In terms of type, transactional data tends to be the most useful—54% of companies are using transactional data in their data-driven projects. This includes consumer purchasing behaviors such as sales, returns and credits. The next-most-common type is machine-generated data, which includes information from logs, sensors, telemetry, networks, security systems and/or IoT devices. The third-most-common type is customer profile information.

    Data has a powerful impact in a business context as a means to refine existing digital products. Other respondents added that a data-driven approach to DevOps helps increase visibility and drives continuous improvement.

    Data Quality: Highest Ranked Challenge

    Undoubtedly, particular challenges remain. The greatest hurdle is retaining data quality—41% of organizations reported dealing with this issue. Quality may be poor because data is unstructured or incompatible with other sources. Other widespread challenges include governance issues and integrating data from multiple sources.

    For those undertaking data-driven projects, 44% said they lacked appropriate skillsets, such as analytics training, data management, security, business intelligence and integration expertise. Companies also often faced funding and talent-related quandaries when beginning data-driven projects. For example, 26% of small-to-medium-sized businesses lacked the necessary funding to take on data-driven projects, according to the research.

    Another challenging area (that I’ve covered previously) is optimizing how data is collected and stored. As cloud storage fees rise, organizations will likely want to refine retention and resolution to avoid creating unnecessarily large, expensive data lakes.

    Rising Deployment of AI/ML

    AI/ML is already well-established as a way to advance the use of data. More than half (54%) of companies used predictive analytics or planned to incorporate it into their systems in the next 12 months. Just under one-third (31%) also either used or planned to use anomaly detection in the future. These areas along with other functionalities (such as natural language processing and predictive analytics) can be used to aid applications such as process automation, decision support, customer analysis, virtual agents and others.

    The industry is at an exciting moment for leveraging data in DevOps. Data is becoming more and more accessible to enable DevOps with a full-stack picture of the application life cycle. To direct future engineering investment, data-driven decisions will rely on things like performances and usage habits. Thus, it’s an interesting time to consider how you might leverage data for greater process automation and software development fluidity.

    The 2022 Data & Analytics Report surveyed 872 IT decision-makers (ITDMs) from around the globe working in various industries. The respondents’ average company size was about 12,000 employees. To view the report for more insights, you can pick it up here.

  • The Age of Software Supply Chain Disruption

    The Age of Software Supply Chain Disruption

    The software supply chain is swiftly becoming a widespread attack vector, and securing it is now in the spotlight. Software supply chain attacks have become a given in 2022, reports Darktrace.

    SolarWinds, Kaseya and GitLab are just a few examples of organizations that have been vulnerable to attack in recent years. We’ve also witnessed an increasing number of exploits, like Log4j and Log4Shell that have the potential to affect billions of devices. What these instances have in common is they leverage vulnerabilities in open source software and third-party dependencies commonly used in the software delivery process — meaning one corrupt package could have broad encompassing impacts on the tech industry at large.

    I recently chatted with Doug Dooley, COO, Data Theorem, about the consequences of today’s intricate software supply chains. “The software supply chain problem is bad, but it’s only going to get worse in the next five years,” he said. According to Dooley, application security requires a continuous context of how the app functions at runtime in a software ecosystem—otherwise, it will continue to miss gaping holes in the big picture.

    Understanding Software Supply Chain Disruption

    Most people understand what a traditional product supply chain is—it encompasses all the components involved to bring a product to the end consumer, from raw materials to manufacturing, distribution and retail locations. But, amid the pandemic and recent international conflict, we’ve witnessed how brittle this chain is. If you shut down one of these components, all consumers feel the effect, resulting in everything from gas hikes to baby food shortages. A full 61% of organizations were hit by supply chain attacks in 2021.

    In software, the supply chain can be thought of similarly—there are many components involved between a software product and the end consumer. The developer writes code, integrates third-party libraries and frameworks, puts it in source code systems, pushes it to test environments and eventually deploys it to production. And often, DevOps has the view of this whole picture.

    “DevOps has become some of the most powerful people in the business,” said Dooley. “They can take a business person’s idea and turn it into reality in the form of an application.”

    Third-party exposures can create huge disruptions in this above workflow. This could take the form of insecure libraries, underlying cloud vulnerabilities or API vulnerabilities, says Dooley. “Customers will embed APIs in the software stack—to them, it’s a black box.” There’s also the potential for misconfigured S3 buckets, which continually leak millions of records. More serious application security threats include remote code execution, which can invoke a detrimental loss of control.

    Why Now?

    So, why the sudden peak in software supply chain-related security incidents? After all, open source software, APIs and third-party vendors have been around for decades. Well, according to Dooley, there are several factors at play here.

    For years, the Silicon Valley mantra has been to ‘move fast and break things.’ Take Netflix engineering, for example, which is constantly evolving services and releasing dozens of changes per day. According to Dooley, such rapid application development often means that security is following development rather than preceding it or becoming integrated into the process, à la DevSecOps. This could lead to what he calls an “ambulance chaser moment.”

    The attack surface is heightened as the number of third-party suppliers and dependencies increases. The average company has 254 SaaS apps, Productiv data found. Also, on the attacker side, we’re seeing increasing levels of automation and sophistication. “You only have to be right one time when attacking,” said Dooley. “The deck is stacked in an attacker’s favor.”

    Strengthening The Chain

    The software supply chain issue is a complex problem that won’t be solved by any single action. However, Dooley offered several tips for companies to consider as they confront this broad problem:

    • Source code analysis and vendor management. It’s important to vet partners and have a process to audit new software by scanning for common vulnerabilities and exposures (CVEs). Yet, source code analysis falls short in many areas, admitted Dooley, as it is unlikely you will be able to view the source code behind cloud API calls and production behavior doesn’t always match documentation.
    • Continuous runtime security monitoring. New exploits are being found constantly. Thus, organizations require a continuous defensive posture at runtime, even if they were found to be secure in development. Continuous full-stack discovery must consider many third-party components, like SDKs, open source code, mobile apps, web services, cloud services, APIs and identity and access management, explains Dooley.
    • Increased transparency with SBOMs. More widespread use of software bills of materials (SBOMs) will be critical to increasing transparency across the industry. Just as nutrition facts describe the food we eat, SBOMs spell out the internal makeup of software components. “We’re trying to get to a place where we get more transparency into the software we depend on,” Dooley said.
    • Rapid vulnerability detection. Have a good handle on the attack surface. Businesses will want to collect an accurate inventory of what can be attacked.
    • Build protection around the “crown jewels.” Sometimes, you must prioritize which steps to take first. Dooley reiterated that securing applications that interface with customer data is critical, as these are the “crown jewels”—leaks here could have serious consequences around regulatory penalties and brand reputation.

    Caution: Heavy Lifting Required

    “The moment you ship a piece of software, you’ve taken on a risk,” said Dooley. But at the same time, if you’re not creating digital interfaces, you’re missing out on massive opportunities.

    Reusing code and open source packages have become necessary to maintain agility to help continuously release digital products. “Even if you build everything from scratch, you’re still reusing a lot,” said Dooley. “Without it, you’d never get to market.” While these tools enable unprecedented speed, we can’t overlook the potential vulnerabilities that may lie within the software supply chain.

    With its unique window into the software deployment and automation process, the DevOps sphere will undoubtedly have a role to play in protecting this paradigm. “Let’s push for more transparency and disclosure,” said Dooley. “But don’t hang your hat on that to make your program great—if you really care about this problem, you’ll have to do some heavy lifting in the real world.”

  • Supergraph: One GraphQL Schema to Rule Them All

    Supergraph: One GraphQL Schema to Rule Them All

    GraphQL has been garnering much interest as a way to seamlessly interact with backend services. The query language is a boon for frontend developers, too, as it conveniently allows you to fetch the specific fields you require, thus eliminating the potential overfetching or underfetching concerns of REST APIs. And as GraphQL adoption matures within organizations, there is increasing interest (and investment) in how enterprises can use GraphQL to securely unify their growing catalog of disparate microservices and APIs.

    Using GraphQL as a meta layer could help unite many disparate systems under a single unified schema. This would enable the age-old promise of composability, in which software building blocks are seamlessly pulled together to assemble applications and unique experiences for different client types. However, managing GraphQL at scale can become tricky. And when a schema gets really large, it then may require a schema of its own! This is where the concept of the supergraph comes in.

    I recently met with Geoff Schmidt, Apollo GraphQL CEO, to discover what a supergraph is and how it may help platforms aggregate their backend microservices. According to Schmidt, “Developers want this composition layer for one abstract view of all their services.” Below, we’ll explore the concept of the supergraph and look at some new open source components that may help you enable GraphQL-based composability in your organization.

    Microservices Enable Composability

    First off, what do we mean by composability? Well, composable architecture is intrinsically linked with microservices. You can think of each microservice as a single lego piece that makes up one aspect of an application. For example, Uber uses 4,000 microservices to power its backend. These services span from maps, currency conversions, driver reviews, payments and other components. When combined, they ultimately create the convenience and the sleek user experience that is Uber.

    Historically, software developers were overseeing larger monolithic applications in which a single client was interconnected to a web server, Schmidt explained. On the other hand, microservices tend to be more domain-specific and used in tandem with other microservices. They’re also typically easier to iterate on and faster to ship when compared to monolithic codebases.

    The Need for Aggregation

    As a result of the microservices age, applications typically pull in far more data from various sources. For example, a banking application might loop in a mortgage service, investment service and other data sources to display a combined net worth on a screen. This explosion in microservices has created a “polygon environment” spanning databases and APIs, increasing service complexity, said Schmidt.

    Nowadays, many third-party components must be combined to render an experience. However, supporting this composability can be challenging for developers and backend API teams—not to mention that handwriting a backend-for-frontend could be burdensome. “App developers are slowed down by the need to integrate or compose these backend services,” said Schmidt. “Developers need a way to put all those pieces back together.”

    What is Supergraph?

    Supergraph can be thought of as a graph of graphs. The vision is to have one GraphQL schema and one ingress port to oversee many services. Creating a supergraph is becoming more accessible, too, as more open source projects emerge to enable this paradigm. For example, Apollo recently open sourced some components that can help to build and operate a supergraph. These include Federation, which helps to create a data graph across multiple services, and the Apollo Router, a tool written in Rust that decides how to route queries. Apollo has also open sourced a supergraph demo along with other resources.

    A supergraph architecture is already powering Expedia, Walmart, Netflix, Paypal, the New York Times and other large environments, said Schmidt. For example, Expedia has used a supergraph to combine flights, rental cars and other microservices to create integrated experiences. Hivee, an upstart modern supermarket chain, also uses a supergraph to unite its investment into APIs.

    According to Schmidt, the fundamental benefit is that less time is spent writing integration code which means faster development speed and the ability to quickly pivot your business. “It allows you to change business quickly to meet the needs of your customers.” A supergraph could also enable greater visibility into your API estate, making auditing easier.

    A key benefit of the above components is that they already have a proven track record running at a commercial scale. But outside of the Apollo projects, other groups are attempting to codify a similar GraphQL schema aggregation concept, as well. For example, WunderGraph utilizes GraphQL within a “virtual graph” that acts as a common language to call various underlying APIs.

    Repercussions of ‘One Graph to Rule Them All’

    Schmidt said the hope is that, at the end of the day, this abstraction can contribute to “making the world a little more human-centric.” This is because GraphQL can enable less rigid apps that conform to unique user tastes. But a robust composition layer will be necessary to allow such reconfigurations.

    Of course, as I’ve covered previously, there are significant security hurdles to address when supplying so much power to a single entryway. Increased GraphQL reliance will require forethought into new potential security risks, such as schema introspection and object-level authorization control.

    According to Schmidt, a GraphQL composition layer presents an opportunity to enforce security controls. He defines these as contracts that create access rules for a particular set of users. By declaratively managing GraphQL security, a development team, in essence, could expose a subgraph of the supergraph for a partner to consume. The graph could even be segmented for internal teams.

    A central point of ingress will require authorization rules to protect user privacy and avoid breaking the rule of least privilege. Schmidt also advocates for backend schemas to be built for app developers who understand their needs, instead of precisely mapping logic to business models.

    Supergraph: A Graph of Graphs

    Software is becoming more modular, which has resulted in an explosion of unique microservices and APIs. And we’re now at another tipping point in how software architecture is divided and combined, said Schmidt. He now sees GraphQL as a prime opportunity to create software architectures that call multiple backend services with a single GraphQL query.

    “GraphQL is the composition layer you need to build modern applications,” said Schmidt. “We’re super excited about this. Users have shown that GraphQL is the future. Supergraph is such a powerful technology, and we’re excited to bring this to everybody.”

  • CDEvents Aims To Standardize CI/CD Interoperability

    CDEvents Aims To Standardize CI/CD Interoperability

    Companies are under mounting pressure to continuously release new applications and features. And as software development life cycles become more iterative, continuous integration and continuous delivery (CI/CD) has become a necessary ingredient to enable more rapid deployments.

    Many development teams now embrace DevOps, but fully automating a CI/CD pipeline from source code to production deployment is no easy task. For one, the number of tools in use continues to balloon, meaning CI/CD poses an ongoing maintenance hurdle. Furthermore, CI/CD tools often adopt varying formats to describe their events. A CI/CD pipeline, a form of event-driven architecture, may require a lot of special “glue” to patch events together if the output from each tool is not in a standardized format.

    Interestingly, CDEvents, an emerging open source standard from the Continous Delivery Foundation (CDF), is working to standardize the root semantics of how CI/CD tools describe the payloads of their events with more granularity than CloudEvents. The project aims to establish schemas for how common CI/CD events are described, easing integration and providing more actionable data surrounding the CI/CD pipeline.

    I recently met with Andrea Frittoli, open source developer advocate at IBM, to understand why the CDEvents project exists, how it works and what they’re hoping to achieve. According to Frittoli, who is also co-creator of the CDEvents project and a member of the CDF Technical Oversight Committee, CDEvents has the potential to bring much-needed interoperability to the sprawling CI/CD tooling ecosystem. Below, we’ll investigate where the project is and consider where it’s heading.

    The Problem With CI/CD

    At its core, the problem CDEvents is trying to solve is a lack of interoperability in the CI/CD field, explained Frittoli. As it stands today, DevOps engineers must routinely make point-to-point integrations between CI/CD tools. “No single tool will take you entirely from managing source code to production,” he said. A single development team could be using up to 15 unique components in one pipeline, and tooling preferences can vary dramatically across teams, he adds, further complicating CI/CD interoperability.

    Although CloudEvents has made inroads as a specification to describe event data, nothing has yet existed specifically for describing CI/CD events. According to Frittoli, CloudEvents falls short here, as it’s agnostic about what is inserted into the payload.

    Understanding CDEvents

    CDEvents is “a common specification for Continuous Delivery events.” Frittoli describes it as a shared dictionary or shared semantics for common events. These events could be a change in source code, running a test, or a code execution or deploy. CDEvents uses JSON object schemas to describe the event types and can work alongside CloudEvents as an attribute. “CDEvents is a standard format for the payload as well, not only for the envelope,” said Frittoli.

    As Frittoli explains, the CDF special interest group is still drafting the CDEvent specification’s exact semantics and common names. Currently, CDEvent organizes these objects into four main buckets: Core events, source code version control, CD events and CI events.

    While the group is still finalizing the format of events as they work toward the initial release, the example below is an approximation of what the final format will look like:

    "meta": {
  "version" : "draft",
  "event_id" : "A234-1234-1234",
  "source" : "/staging/tekton/",
  "type" : "dev.cdevents.taskrun.started",
  "timestamp" : "2018-04-05T17:31:00Z"
},
"subject": {
  "id": "/namespace/taskrun-123",
  "type": "taskrun",
  "content": {
    "URL": ...
    "pipelinerun": ...
  }
},
"extensions": [{
  "name": ,
  "content": ...}
],
"links": [{
...
}]

    Benefits of CI/CD Event Standardization

    So, why is it necessary to define the format of CI/CD event data? What benefits does this bring to developers and the business as a whole? Well, Frittoli sees two potential primary use cases. First off, CDEvents could reduce the effort spent writing and maintaining glue code between common DevOps tools like Spinnaker, Argo or Flux. “This will allow a smoother integration between all the parts,” said Frittoli. Alleviating this could help scale CI/CD initiatives and increase overall agility.

    Another positive side effect is collecting more detailed information about workloads and their performances. If all these components generate similarly-formatted events, Frittoli explained, then you can begin to create a true end-to-end visualization of the entire CI/CD pipeline. Then, you can start to measure things such as deployment frequency, failure rate, time to change and other metrics.

    If events begin to use a common language, you could do many interesting things with that data, says Frittoli. Event data could help ascertain the root cause of incidents and aid debugging. One could even foresee some AIOps potential to further automate operations and increase observability around CI/CD.

    Final Thoughts and Ways to Participate

    CDEvents emerged at a time when iterative software development has become commonplace. A slew of helpful CI/CD tools is at our disposal to enable niche operations. Yet, the space still requires a standard way to operate between them. CDEvents is an exciting prospect, yet the project is still in its early stages. It has yet to reach a full release or any production use and proofs-of-concept are still being developed.

    Of course, encouraging a vendor-neutral specification requires the tooling community to get on board. “It’s vital for the different tools to implement CDEvents for it to be successful,” said Frittoli. He encourages the tooling community to join the working group to collaborate in building proofs-of-concept. The SIG plans to continue working on finalizing the first version of the specification. In the meantime, the group has produced a proof-of-concept using Tekton and keptn and the project has its future sights set on Knative and Jenkins.

    The CDEvents project is in incubating mode and maintained by the Events Special Interest Group (SIG) at the CDF. For more information, you can peruse the CDEvents documentation here or become involved with the community here. The Events SIG also holds biweekly meetings and a CDEvents Community Summit will be part of the upcoming CDcon.

  • Increasing Use of SLOs to Enable Observability

    Increasing Use of SLOs to Enable Observability

    Observability is a growing discipline among most IT and operations departments. To release stable software faster, operators need continuous visibility into metrics like performance, uptime and availability. As a result, engineers are increasing their use of service-level objectives (SLOs) across the board—a recent study found that 82% of companies are increasing their use of SLOs.

    SLOs enable deep visibility into specific applications’ performance and are often used by site reliability engineers (SREs) to ensure quality and avoid service interruptions. Not only that, but various teams are correlating SLOs to aspects of the business to reduce cost and help direct decision-making. But while many environments have visibility, there are still gaps present.

    Nobl9 recently released a global survey of IT professionals and executives that tracked the state of service-level objectives in 2022. Below, we’ll look at the key findings from the report and consider what they mean for the state of SLOs and observability in general.

    State of Observability and SRE

    In general, site reliability engineering is still maturing across organizations. Though only 31% of companies have adopted SRE, it’s slated for much future growth, as 46% said they plan to embrace SRE in the future.

    These operators are now faced with many cloud-native observability tools, which are producing a sea of data in the form of metrics, logs and traces. A full 39% of companies use anywhere from six to 10 observability and monitoring tools and 35% use more than 11.

    With so many tools now deployed, who is using this observability and monitoring data? Namely, at 74% of companies, observability data support operational requirements. Operations teams are the ones most likely to use SLOs to monitor uptime, performance and overall efficiency. After operations teams, security teams also use this observability data (71%), which makes sense as SLOs can inform incident response. Other areas that follow are customer support, compliance and capacity planning.

    One interesting finding is that only 42% of companies use SLOs for service-level agreement (SLA) adherence. This indicates that SLOs are most often applied to internal optimizations and decision-making.

    Hybrid Environments Complicate Visibility

    Companies are mostly tracking SLOs to increase their visibility into networks (83%), databases (76%) and applications (75%). Other top areas include private cloud environments and legacy computing arrangements. But although observability is trending, organizations still lack complete visibility across the entire stack.

    Of note is that nearly half (46%) of respondents said their monitoring and observability tools don’t provide full visibility into all of their company’s IT assets. For example, only 45% of companies have visibility into their containers and just 35% have visibility into their microservices architecture.

    A lack of full-stack visibility may be complicated due to rising hybrid and multi-cloud conditions, as 78% say a hybrid cloud environment makes monitoring infrastructure more difficult.

    Benefits of Tracking SLOs

    The report defined SLO as “a performance and availability target set for a given system, application [or] service over time.” And the benefits are readily apparent for organizations following such targets—they can help increase performances, direct decision-making and help avoid outages.

    As a result, 70% of companies are currently using SLOs in some fashion. Here are some benefits of tracking SLOs:

    • Increase microservice performance: 87% said using SLOs for microservices architecture would improve service performance.
    • Enable full-stack observability: 58% said some of their company SLOs are mapped to business operations.
    • Improve business decision-making: 91% agreed using SLOs can help drive better business decisions.
    • Prevent service interruption: 67% said their company prevented business interruptions thanks to SLO thresholds alerts.
    • Reduce expenses: 90% indicated SLOs saved their company money.

    Final Thoughts

    More teams are tracking service-level objectives than ever before. And most companies (71%) that aren’t using SLOs now plan on adopting them soon. The data demonstrated that the observability market is an evolving area with room to grow. And, the same can be said about the SRE role.

    Yet, it’s good to point out that not all companies will adopt precisely the same roles or monitoring procedures. Therefore, there will likely continue to be variance in who is using SLOs and how they are applied. Regardless, the study suggested that investigating SLOs has the potential to benefit the software life cycle in many ways.

    The study, “Adoption of SLOs Grow to Increase Visibility and Drive Business Improvements” surveyed 309 participants around the globe in various sectors. The study was sponsored by Nobl9 and conducted by Dimensional Research. For more information, you can download the report here.