Category: DevOps Practice

  • Identifying and Abstracting Business Intelligence from Kubernetes Workloads

    Identifying and Abstracting Business Intelligence from Kubernetes Workloads

    In the age of big data, businesses are inundated with data points. While they know there’s an abundance of valuable resources available to them, making sense of this data to derive actionable insights is often still a challenge.

    CNCF industry survey data shows workload complexity and monitoring remain top challenges for enterprises in terms of using and deploying Kubernetes. Many understand there are valuable resources within these environments, but struggle to best identify and extract meaning from machine data. While most of this data is readily available, it just takes the right tools to gather and view intelligent insights.

    The Benefits of Open-Source Data Collection

    Perusing the CNCF website, there are a wealth of tools built around Kubernetes to enable not only monitoring but networking, storage and security. There is even a Kubernetes-specific package manager, Helm, to make the deployment and management of these resources easy and consistent.

    There are a couple of key benefits to taking advantage of these open-source collectors:

    1. They stay up to date. Each of these tools benefits from deep community support. As new versions of Kubernetes are released, the extensive use of each of these tools ensures they are quickly updated.
    2. They integrate with everything. Prometheus, for example, has an impressive list of integrations and exporters.  Regardless of your unique stack, it is likely that there is support for what you might want to export data from. The importance of these integrations cannot be overstated, as they enable the flexibility needed to grow and evolve a Kubernetes deployment over time.

    Ensuring Complete and Organized Metrics Collection

    Prometheus–endorsed by the CNCF–is the de facto tool of choice for metrics monitoring with extensive support for anything you might use to collect metrics data.

    Prometheus works by pulling data from all of the components and jobs running in Kubernetes since every component of Kubernetes exposes its metrics in a Prometheus format. The processes running behind those components then serve up the metrics on an HTTP URL. For example, the Kubernetes API Server serves its metrics on https://$API_HOST:443/metrics.

    Prometheus is particularly good at auto-discovering the jobs and services currently running in a Kubernetes cluster. As pods are added, removed or restarted, the Kubernetes Service construct keeps track of what pods exist for a given service. This auto-discovery capability is one of the primary reasons for Prometheus’ popularity, ensuring that all new and existing components are monitored.

    The Importance of Cluster Level Logging and Event Collection

    Kubernetes does not define a single standard approach to log collection, but the most common method is called cluster level logging. Cluster level logging deploys a node level logging agent to each node which then funnels data to a separate backend for storage and analysis of logs. The primary benefit of this solution is that if a pod dies, the logs detailing what happened are retained. Implementing node level logging, without funneling data to a logging backend, will not retain log data if pods die or are evicted, while cluster level logging ensures that data is captured and retailed. A common tool for implementing cluster level logging is Fluentd—or Fluentbit, a lightweight version of Fluentd—which acts as the node level logging agent funneling data to a logging backend.

    Events provide insight into decisions being made by the cluster and unexpected events that occur in Kubernetes. Events are stored by the API server on the master node and collected using the same method as log collection—via a node level logging agent like Fluentd.

    Establishing a Continuous Intelligence Dashboard

    Finally, collectors for logs, metrics, events and security can be easily deployed using Helm—an open source Kubernetes package manager. Helm can significantly simplify the setup process, reducing hundreds of lines of configuration to one. These collection plugins can be used on any Kubernetes cluster, whether one from a managed service such Amazon Elastic Kubernetes Service (EKS) or a cluster you are running entirely on your own.

    According to Sumo Logic’s recent Continuous Intelligence Report, enterprise adoption and deployments of multi-cloud grew 50% year-over-year, and 80% of users across multi-cloud environments are now utilizing Kubernetes architectures. As Kubernetes continues to become mainstream, it’s essential that businesses understand how these workloads operate and how to best extract valuable insights to inform business decisions.

    — Katie Lane

  • Cloud Native Tracing and Observability: Why You Care

    Cloud Native Tracing and Observability: Why You Care

    Is observability the new monitoring? Or is observability, and tracing, fundamentally different? Like any IT industry trend, it can be difficult to discern as many jump on the trend bandwagon, appropriately or not. The Splunk .conf 2019 event presented Splunk with the opportunity to bring clarity to the terms and the reasoning behind the acquisitions of SignalFx and Omnition.

    Monitoring is mostly about taking events, telemetry data and established data points and thresholds into monitoring, alerting and problem management processes and tools. Its tried and true, and has progressed with the evolution of typical monolith, distributed apps and systems. Enter cloud-native applications, composed containers, microservices and service meshes. With great flexibility comes complexity, and cloud native isn’t immune to such an adage.

    What would have been a monolithic application is now shattered into hundreds or even thousands of smaller pieces of application and app technology software. The complexity of externally monitoring cloud native quickly surpasses the capabilities of most monitoring approaches.

    Observability, as recently acquired SignalFx CTO Arijit Mukherji shared this week, is built upon three pillars: metrics, tracing and logs. Metrics show when you have a problem, tracing points you to the problem and logs help find the root cause—a reasonable way to define and segment observability. It also, not surprisingly, fits well with the logic of Splunk plus SignalFx plus Omnition.

    To move beyond monitoring requires instrumentation, built into the software and APIs as part of the software creation process, a DevOps process. SignalFx in part brought Splunk auto-instrumentation, which during run-time, identifies frameworks and libraries in use within applications and can capture tracing instrumentation. Omnition brings even deeper tracing chops to perform tracing across large service meshes of microservices. Add Splunk’s capability to correlate data across the business, applications and operations data and you complete the picture with the ultimate goal of making observability easy for developers.

    The above might explain why developers, ops and DevOps care about observability and tracing, but should the business care? SignalFx CEO Karthik Rau connected the dots nicely during a conversation this week. Digital transformation strategies require speed and agility, but also demand more risk-taking. Confidence in risk-taking comes when accompanied by the ability to respond rapidly to changes and failures. A software deployed 10 minutes ago may need to be backed out or corrected rapidly when the users’ experience goes negative. That requires a rapid determination of what the problems is, and the ability to take immediate corrective action, including automated action.

    Cloud native and DevOps not only enable disruptive, digital transformation strategies but must be accompanied by rapid and automated responses when negative business and customer impacting conditions occur. Customers don’t care when CPUs are taxed, but they do care when a mobile app’s responses fail or are slow. The move to cloud native is served well when backed up by such capabilities to respond in near real-time when problems occur.

    — Mitchell Ashley

  • The Role of Containers in Business Transformation

    The Role of Containers in Business Transformation

    Containers hold new promise for business and digital transformation. Yet many differences exist between monitoring containers and monitoring other elements of infrastructure, such as VMs, storage, memory and compute. Understanding those differences is vital for ITOps managers as they navigate their businesses’ digital transformation.

    Interestingly, the differences are as much technical as they are organizational. Companies need to explore these differences and consider questions such as, how to ensure that a container-based project performs when it goes into production, and what changes you must make to infrastructure to ensure you have enough compute and storage power to support the containerized applications your development team is going to launch.

    The essence of container management is to be prepared for the changes coming from application development, which means understanding resource and infrastructure as it is today to estimate the effect of those changes tomorrow.

    Here are four differences ITOps managers need to consider with container management as they move their digital transformation journeys forward.

    Containers Versus VMs

    The signature feature of containers is they can hold and run an entire application all in isolation. VMs offer operating system level isolation, but at the cost of a much larger footprint; to begin with, each one has its own copy of the entire operating system. VMs are also far less portable than containers, especially when moving among private and public clouds and data centers. As a step toward digital business transformation, most companies are looking for DevOps tools and for ways to deploy their applications to the cloud, whether for QA or production. Organizations rolling out new applications are also gravitating to a container-based architecture from the start.

    Advantages of adopting containers include:

    • Agility: Instantiating a new container goes as much as 20 times faster than instantiating a new VM. Startup is measured in seconds rather than minutes and once deployed, containers scale up and down rapidly in response to load.
    • Density: Most containers are megabytes in size rather than gigabytes. With their smaller footprint, containers allow for as much as five times greater density than VMs.
    • Cloud-readiness: Containers can be deployed to any cloud (private, public, virtual or physical) which opens up the possibility of using the same containerized application in hybrid and multi-cloud environments.
    • Blast radius: As software developers incorporate and release changes more quickly, they look for ways to control potential damage from bugs. A problem in a container is less likely to cause widespread damage and is easier to isolate and repair than a problem in an entire VM or physical server.
    • Cost savings: Every VM requires a hypervisor and an operating system (OS), which can involve licensing and fees. Containers run side by side, sharing the OS kernel of a single physical machine while holding isolated copies of specific library versions they depend on. Architecturally, VMs tend to contain more components and require greater allocation of resources. Containers, on the other hand, tend to hold a specific component or a single micro-service, minimizing resource overhead.

    Containers, DevOps and Real-time Monitoring

    A company adopting DevOps to speed up deployment of its software products automates as many development processes as possible and relies heavily on automation scripts to move code along, from continuous integration through continuous deployment and continuous delivery (CI/CD/CD) to production. Along the way, multiple developers must check in on new changes. Automated processes, such as health checks and unit testing, take place and then the build is deployed to the next environment, such as integration or QA. With each set of changes, ITOps needs the answers to several questions:

    • How will this affect performance?
    • What will be the impact of the changes when we deploy?
    • Do we have enough compute, storage, memory and networking to support the changes?

    In a traditional environment, developers have plenty of time to answer those questions. But if they’re deploying modern, containerized, cloud-based applications, that window tends to be much smaller which can lead to the kind of guesswork that makes ITOps uneasy. That’s where container monitoring comes in. When ITOps can see real-time and historical analytics of containers and their hosts, across physical, virtual and cloud environments, they can create performance benchmarks to help them make informed choices about infrastructure.

    Microservices Get Added into the Mix

    Microservices are loosely coupled and independent services, each with their own release schedule and lifecycle. Developers are able to make small changes to elements of these applications which allows them to mitigate the risk of negative business impact by reducing the blast radius around those changes. In case of failure in a single change, there’s less to repair and less impact on surrounding, dependent services. We’re seeing developers move away from packaging a single application per container to packaging a single service of an application per container. This allows them to make changes more frequently and keep up with business demands.

    Multiple Silos

    The goal of DevOps is to bring application development and traditional ITOps closer together. However, container monitoring and management changes things. Traditionally, areas such as storage, network bandwidth, VMs and physical hosts that require monitoring have all been in the ITOps silo, an area that developers don’t typically own. Developers write code and build software in the application development silo and then hand the software off to the ITOps silo to run. However, things have changed and now developers aren’t only writing code, but also owning and using containers in the application development silo. Once the software and containers leave this silo, their consumption of resources like compute, storage, network bandwidth and memory will also affect the ITOps silo. That’s why monitoring and management is as necessary for containers as it is in areas like storage, VMs and physical hosts.

    While container technology may be new for the traditional enterprise, the impact it will have on business transformation cannot be ignored. Containerization brings increased simplicity, consistency and portability to production environments, enabling faster IT delivery and increased performance, arming businesses with a new agility and allowing them to rapidly respond to changing customer needs. In fact, according to 451 Research, application containers will be a $2.7bn market by 2020.

    The businesses that embrace this opportunity will be taking a vital step towards transforming into bustling digital enterprises that can deliver innovative products and top-notch customer experiences. To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Yinghua Qin

  • Four Steps to Implement an Observability Strategy for Microservices

    Four Steps to Implement an Observability Strategy for Microservices

    You’ve finally decided. You’re making the move to microservices and re-architecting your entire infrastructure. Some services will still be on-premises (those databases and their legacy apps are never moving), but a cloud-based microservices architecture will allow your teams to build and bring new products to market faster.

    But how do you handle the complexity that comes with cloud and microservices? You know you need a strategy for monitoring and managing the complex dependencies and ephemeral nature of your new architecture, but you don’t know where to start. What’s more, you don’t want to spend time and money now only to realize a few months down the line that you’re on the wrong road. Your investment needs to be future-proof.

    You need to implement a strategy for observability. Observability goes beyond monitoring to give you greater operational insight, leading to shorter incidents, fewer quality problems, a better product and happier customers. Your company has unique observability needs, which means how you approach your observability strategy will also be unique. As is usually the case, it’s important to start with a roadmap and goals. Based on my experience, the following four things are key to making a considered, comprehensive observability strategy that’s built for the long haul.

    Choose an Observability Platform that Fits Your Future

    Perhaps counter-intuitively, the right platform isn’t necessarily the one that’s the right fit for you today. If you’re investing in new technologies such as microservices, containers and Kubernetes, you’re going to see a significant increase in the scale and ephemerality of your environment. A monitoring platform that may suit your current infrastructure likely won’t be able to keep up and meet your future needs. Instead, consider how your infrastructure will look three, four or even five years down the road, and then select the platform that best fits that long-term strategy. It doesn’t matter if you choose a commercial tool or an open source one: What matters is that you give considered thought to your future infrastructure and choose a platform that can address the future needs of your environment—and protects your investment at the same time.

    Monitor the Metrics that Really Matter

    If you’re still in the early days of your shift from monitoring to observability, you’re likely taking a service-based approach, monitoring specific pieces of your ecosystem with a focus on individual incidents. The real value of observability is the ability to provide visibility into big-picture issues, such as measuring user experience, performance against SLOs and other key metrics important to the business. In modern environments, small upticks in a microservice can cascade into increased latency for an entire product, a specific feature, or even a specific customer. Having an observability platform that measures and collects data across multiple dimensions–e.g. customer/business-specific, application/service specific and infra/host/container specific–will allow you to understand the telemetry in many different ways. The platform should also aggregate the interactions between your services and unlock a wealth of data for engineers to investigate when issues do arise, and provides visibility into the metrics the business cares about most

    Embed Observability into Your Incident Management Process

    Incident management is a hot topic right now. I speak with CTOs across organizations and industries who have fantastic tools that provide detailed telemetry, but everything breaks down when an incident occurs. They need to better embed observability as a part of their incident management process. For example, ask your incident management team how observability helped in a given incident and record those results. This keeps track of the ongoing benefit. Next, ask how observability could be improved to get the team closer to the crucial clues they need during an incident. And finally, make sure to fold these items into your remediation plans so the team has a clear playbook when incidents do occur.

    Establish a Culture of Observability Across Your Organization

    Simply deploying a new technology of any type is not enough. You need to ensure you’ve built the appropriate processes and norms around the new platform to ensure its success—this is especially true with observability. Modern observability platforms can be incredibly powerful in providing insight into the performance of your ecosystem, but without an investment in your organization’s ability to use the platform, you’ll barely scratch the surface of its true value.

    Observability requires ongoing investment and improvement. Start by building a core group of champions, then fold training into onboarding, continuing education or brown-bag sessions. Using subject matter experts to create the content is a good way to get everyone off on the right foot. Use the output from observability tools in company meetings, team syncs or support settings to keep everyone on the same page. This sort of standardization raises the collective skill of the entire organization and demonstrates the value of observability to those who are not already on board.

    Following these four steps will set you off in the right direction on your observability journey. If your organization is like most, you keep an eye on what you think could go wrong. While that’s unquestionably important, a mature observability strategy will give you an insight into previous unknowns and help you more quickly understand why incidents occur. And as you continue on your observability journey and your understanding of what and why things break improves, you’ll be able to implement increasingly automated and effective performance improvements that impact your company’s bottom line.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Arijit Mukherji

  • From Pets to X-as-Code: Enabling Control and Predictability for ITOps at Scale

    From Pets to X-as-Code: Enabling Control and Predictability for ITOps at Scale

    Amy Wheelus, vice president of network cloud at AT&T, recently spoke about declarative predictability at the Open Networking Summit in Antwerp. AT&T is the world’s largest telecommunications company providing mission critical communication services where people’s jobs–and lives–can be on the line. As they move away from labor-intensive IT operations toward cloud-native automation, there is a need to trust the declared IT infrastructure state can be predictably controlled and reproduced. This requirement to build predictability, reproducibility and trust into IT systems is not new but has grown in both scale and complexity as IT departments went from a few servers blinking in the basement to the core around which every business rotates. 

    With every customer interaction and business function becoming more digital, companies must be able to rely upon their IT departments if they hope to continue to keep pace in today’s rapidly changing world. This article traces the evolution of IT operations from Pets towards X-as-code with each improvement bringing companies closer to declarative predictability. These best practices enable enterprises to reliably deliver core business value through their IT department and keep pace in the cloud native era.

    Yesterday: Pets Versus Cattle and Infrastructure as Code

    Back when the IT department was just servers in the back room, it was all hands on deck when anything went wrong because work ground to a halt. The CEO couldn’t get their emails and the sales department couldn’t book new orders. From these early days, it was learned that in order to trust IT with critical business services, high availability and reliability needed to be built into the system. This lead to the creation of the Pets vs. Cattle analogy where each infrastructure component is interchangeable and can quickly be replaced when anything goes wrong. This allows companies to quickly recover from or even avoid outages.  

    While treating servers as cattle solves some problems, as any rancher can tell you, handling a whole heard brings its own set of challenges. As the size of managed infrastructure grows, it can be difficult to keep track of where, when and how it is actually deployed. In addition, changes to production systems to keep them healthy can lead to configuration drift creating unique snowflake servers which are pets rather than cattle. It becomes a difficult task to predict how a system will react or rely upon it in critical situations when its actual state is unknown.

    To help eliminate this problem and control how infrastructure is configured and deployed, ITOps teams moved to infrastructure-as-code. In this way of working, applications and servers are never modified once deployed. If something needs to be changed, a new version is created and the old one is decommissioned. Each deployment can be versioned to create an overview of what is in production and how it is deployed.

    Managing cattle rather than pets and using infrastructure-as-code has helped companies move from ticket-based operations with long lived machines to more scalable and dynamic infrastructure. These practices build reusability, scalability, automation and versioning into IT systems to create a simpler, more predictable deployment and management process. By being able to declare the state of its infrastructure, companies are able to predict and trust the outcome.

    Today: Cloud-Native Infrastructure

    Looking at the definition of cloud native from the Cloud Native Computing Foundation, it quickly becomes clear why many companies are turning toward these best practices. They help companies build and run resilient and manageable infrastructure that–combined with robust automation–creates dynamic, yet predictable systems. Declarative APIs and immutable infrastructure will be used as two examples to understand how cloud native builds upon and expands the techniques covered above.

    Declarative APIs make infrastructure as code and automation possible. For example, with Kubernetes, operations teams are able to declare the desired state of the system and automate the reconciliation with the actual state until they match. It originally began with just container orchestration but has since expanded to cover many other types of cloud resources including the physical infrastructure itself through Custom Resources and Cluster API respectively. Declarative APIs make infrastructure management simpler and more reproducible by automating operations and eliminating errors in production. Declarative APIs can be leveraged to create immutable infrastructure.

    Immutable infrastructure goes beyond just servers as cattle and only treating the infrastructure as code. Immutable infrastructure covers every higher layer of the stack until each one is codified and managed like cattle. Only exact copies are deployed and they can be completely replaced at any time. If anything needs to be changed, a new deployment is made and the old ones are decommissioned. Immutable infrastructure works for the whole stack to eliminate variations leading to fewer deployment failures, consistency across environments, easy horizontal scaling and a simple rollback and recovery process.

    As these two examples show, cloud native enables companies to reliably scale out dynamic IT services without having to simultaneously scale out their operations team. Building declarative predictability into systems engenders trust in automatic processes, even when critical services are running on them.

    Tomorrow: X-as-Code

    While cloud-native best practices provide many benefits, applications and infrastructure are just the beginning of the story for enterprise IT teams. In today’s world, they are presented with the Herculean tasks to manage a dynamic and sprawling environment while still keeping in compliance with internal policy along with national and international laws. This challenge moves far beyond mere servers and treating them like cattle to compliance and governance across multiple clouds and hundreds or thousands of developers. With these challenges in mind, the question still remains on how to best deliver on these demands at the enterprise scale.

    Looking across architecture, configuration, blueprinting, policy and governance, if each of these is simply viewed as another layer of the stack above the application, their operations can be radically simplified. By applying the principles of immutable infrastructure and cattle to this further layer of the stack, each of these can be defined and managed using an X-as-code model. These types of management models can already be seen taking root across the cloud-native ecosystem.

    Kubernetes creates blueprints-as-code through the use of Admission Controllers while policy-as-code can be defined in Pod Security Policies and Network Policies. The CNCF even has a policy engine, OPA, as a sandbox project that gives operators fine-grained yet flexible policy control across their entire stack. By using code to decouple policy and other layers from the actual implementation, the resulting stack is easier to understand, flexible enough to handle future requirements and less expensive to maintain.

    At Loodse, our customers were struggling to manage configuration, services and policy across their clusters. Leveraging the Kubernetes controller paradigm in Kubermatic, we are able to automate the deployment and lifecycle of each of these add-ons. This gives users the ability to declare, enforce and automate the required state of not only the infrastructure but the configuration and policy, too. Kubernetes controllers bring predictability and control to dynamic and scalable cloud-native IT even as it begins to handle more and more mission critical services.

    Cloud Native in Production: Declarative Predictability

    With IT becoming the core of every business, bringing cloud-native best practices into production enables operators to predictably declare, run and manage their infrastructure at the enterprise scale. Being able to trust in these automated operations frees up resources and opens up many new possibilities. Developers can be given guardrails and become empowered to do their job rather than waiting in a ticket queue. Operators can easily create highly available self-healing infrastructure that meets governance standards allowing them to focus on delivering a platform with differentiated business value.

    At each step of the development of modern IT practices, from cattle to X-as-code, operational processes have become more streamlined allowing both developers and operators to drive more value to the bottom line. The future of IT infrastructure and operations will be a trusted platform that automates undifferentiated heavy lifting, allowing the whole business to focus on customer value.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Bill Mulligan

  • Legacy Databases Are Holding Back Enterprise Digital Transformations

    Legacy Databases Are Holding Back Enterprise Digital Transformations

    As enterprises rush to digitize their business operations and enhance customer engagement, few are seeing the success they hoped. A recent survey points to a couple of culprits, including the difficulty of utilizing data held in legacy databases.

    The survey, conducted by market research firm Vanson Bourne on behalf of Couchbase, of 450 heads of digital transformation at enterprises across the U.S., U.K., France and Germany found 68% of respondents said getting the right technologies in place for digital transformation can seem an insurmountable task. In fact, 80% report having to scale back ambitions for new IoT or mobile applications.

    The primary reason? Big challenges using their data. A sizable 85% of architects surveyed said legacy databases are limiting their ability to transform.

    These challenges, however, aren’t easing pressure from business leaders to quickly perform. Eighty-five percent of respondents said they were under pressure to deliver digital projects. And 41% said they were experiencing “high” or “extremely high” pressure.

    Despite the pressure to move forward, architects are still scaling back their ambitions, the survey found. It’s no surprise that aging systems and infrastructure can bog down progress, the survey suggests legacy databases may be one of the biggest hurdles enterprises face right now as upgrading legacy databases is something that can be fraught with risk.

    The Couchbase survey found that 60% of respondents stated that too much of the IT team’s time spent working on digital transformation projects is spent managing their way through legacy technologies.

    The survey also found the most commonly supported way to deploy databases, with 50% of enterprises, still remains to be private cloud infrastructure. This was closely followed by hybrid cloud (45%), on-premises (39%) and public cloud (34%), and 31% are using database-as-a-service.

    Some other highlights include:

    • A total of 90% of enterprises rely on legacy relational database technology, 38% “heavily.”
    • Seventy-two percent of those relying on legacy databases said these databases limit the organization’s ability to implement digital transformation projects.
    • Seventy-nine percent of enterprises are actively planning to reduce their reliance on relational databases–with 56% aiming to do so in the next 12 months.
    • At the same time, 74% are moving more slowly than they should because they rely heavily on legacy databases for critical applications.

    Respondents were asked what transformative technologies they are currently using, or plan to use. Interestingly, 50% said they are–or will be–edge computing, 42% augmented or virtual reality, and 51% blockchain.

    Whatever technology enterprises do, or don’t, end up using in their digital transformation initiatives over the long term, one thing should be clear right now: they’re going to be using data to make those efforts succeed. Let’s hope enterprises find a way to unleash their data so they can achieve the transformations they need.

    — George V. Hulme

  • How Monitoring and Observability Feed Each Other to Create a Holistic Approach to Visibility

    How Monitoring and Observability Feed Each Other to Create a Holistic Approach to Visibility

    Monitoring versus observability is a hotly debated topic. It’s been argued they’re two distinct things—the former just a high-level overview of a problem after the fact, while the latter enables you to be proactive. Observability has also been dismissed as jargon, much how DevOps sounds to the seasoned operator.

    The thing is, the whole debate misses the point: it’s not monitoring versus observability–the two are not mutually exclusive, but symbiotic. Like the Ouroboros—the ancient Egyptian symbol of a snake eating itself—monitoring and observability both feed each other.

    Monitoring tells you what’s broken and where you need to have a higher degree of visibility. In other words, if something is broken and you’re having difficulty telling why, you need to increase visibility (i.e., by adding more checks and instrumentation). The same can be said for observability—a term used to describe telemetry, event logging and trace data (and, it can be argued, in many ways a subcategory of the traditional sense of performance monitoring). Observability gives you the richest context, but the difficulty is in understanding the holistic view—AKA, where to look next.

    Say your observability tool shows 99th percentile latency and you see a huge uptick: you have to guess as to why there’s such an increase. Based on your own operator knowledge, it’s either the network introducing the latency or the database is unable to respond in a reasonable or consistent time—for example, the disk could be slow or you’re on a multi-tenant system and someone is consuming CPU time.

    The difference with monitoring in this scenario is it would let you know you exceeded your trend on latency, therefore something has gone awry. It’s the same path, but you still have to make logical jumps based on your own experience—unless you’ve gone ahead and contextualized these from the get-go by creating runbooks and checklists for certain failure scenarios. If a monitoring check is properly created it will provide guidance as to what to look at first, then the observability tool gives you the much lower-level insight to go through each of those prescribed steps. Another way to look at it is monitoring as step one and observability as step two. This way, you can see how monitoring and observability feed each other, rather than existing as wholly separate concepts or toolsets.

    It all comes down to context. Traditional tools for monitoring and observability encompass everything from traditional logging to telemetry data, but none of that matters unless you have context as to why a certain behavior is happening. With this traditional approach, your users become your monitoring–tweeting at you when your site is down—and that’s bad for business. You’re still going to have to guess the context, spelunking through a multitude of data points to figure out what went wrong. It’s a polarizing topic—perhaps not quite as polarizing as monitoring versus observability—but there is such a thing as too much data. My experience has taught me a curated approach to monitoring and observability makes better use of resources and helps combat alert fatigue.

    Context is key. Monitoring is the “what is down?” and the context that helps lead you to determine your “why.” Observability tooling lets you dig further into those whys. A modern solution needs to go beyond just alerts to offer rich context and actionable insight.

    Pairing monitoring best practices with an effective observability solution can both tell you something is wrong and offer rich context. You get to the why faster, making it easier to arrive at the right conclusions in a timely fashion. One approach that marries the concepts of monitoring and observability is to apply workflow automation principles to monitoring. Operators need to have the tools to automate their monitoring workflows (such as auto-remediation), and reserve alerts for complex tasks that can’t be automated.

    By laying aside the debate of monitoring or observability and acknowledging the ways in which they feed each other, operators can have a holistic view and deep context into their systems—ultimately improving their workflows and offering better end-user experiences.

    — Sean Porter

  • Is Release Management Dead in the DevOps World?

    Is Release Management Dead in the DevOps World?

    In the world of enterprise application development and delivery, release management was born from the operations team attempting to reduce risk in the delivery pipeline. It’s the operations team’s job to ensure all production runs are stable, while the development team focuses on creating and shipping new products and applications.

    While this seems well-defined, integrated DevOps teams are left to wonder if they need release management, and how it fits into their processes. The answer is a resounding yes–release management is a crucial aspect of continuous delivery. Enterprises that fail to implement faster and carefully coordinate release cycles, will ultimately fail to keep up with their competitors.

    What is Release Management?

    The aim of release management is to consider the bigger picture, and to view software not only in relation to how the technology works in its production and during development, but also how it relates to the overall business objectives. It’s about much more than coordinating the creation of new and improved software–it’s also about coordinating all of the resources required, the features and the testing, and understanding how applications progress through the lifecycle. Essentially, true release management is not just about risk. It involves everything required to facilitate software moving into production while coordinating all of the different teams to ensure every release follows company procedures. It also makes sure all of the stakeholders are in communication to understand how the outputs of each individual team work together in the production environment.

    For a DevOps team to fully embrace release management, there needs to be a change in the traditional structure that the teams are used to. Product managers need to take ownership of the deployment process with the ultimate goal to ship finished software. They should own the entire process from start to finish, and thereby become the connection between the business, the customer and the development team. However, product managers are unlikely to be experts at release management, so they need help to fulfill this role effectively. This is where the product-oriented team comes in. As DevOps adoption matures, release management responsibilities need to be transferred to the product-oriented team, though there may still be guidance from a release management group.

    Why Does Release Management Still Exist?

    For businesses that either don’t have a release management system in place, or that struggle with how to make it work effectively, they may question why release management is still a concept, and whether it still needs to be one. Release management is necessary for teams to manage the complex amalgamation of DevOps and distributed microservice-based architectures.

    Businesses today frequently still have monolithic applications, independent from all other applications. Having these monoliths means there are dependencies, and dependencies are the death of anyone trying to run autonomously, as you still have to connect these applications with all of the others. Teams also tend to still have more stable systems of record, including ERP (Enterprise Resource Planning) applications, which are more complex to manage, particularly when changes are being made and if there is a hybrid environment involved with both on-premises and cloud. If DevOps teams do not integrate a suitable release management strategy to cope with this landscape, there can be potentially severe disruptions to day-to-day business processes.

    Where Do Autonomous Teams Fit in?

    Though autonomous teams are becoming increasingly self-sufficient, aspects of the business such as accessibility, security, usability and architecture reviews will never be 100% autonomous. Therefore, these teams will still require some level of guidance. Release managers are beneficial here because they have an overview of the entire process to see how every tool operates individually and alongside others, and can easily spot where bottlenecks are occurring so they can be resolved.

    Not only this, but as mentioned, release management accounts for all of the areas that can’t be automated for one reason or another. To make this work efficiently, businesses will ideally introduce either a coach for the product manager, or a part-time release manager in the product team.

    Whenever people are not available, there are also tools that can be implemented to make this process easier. Having a virtual release manager tool spans all of the delivery teams–it’s a combination of release process orchestration matched up with templatized and standardized releases approved by the release management team. The templates are like the blueprints for the release–they provide an example of how the release should look, creating a foundation that developers can then build on with the specifics of the desired release.

    In addition to templatized releases, you should shift left governance, risk and compliance requirements left in the development and delivery. Create a series of non-functional requirements that help ensure development performs necessary tasks during the development cycle. Tasks such as accessibility reviews of the design, threat modelling or architecture review performed early can reduce risk later on, since any problems to those areas have the potential for large changes.

    So, is release management dead? The answer is no. Though some businesses may be struggling to find a way to implement or adapt this methodology to fit around their existing teams, having the support and visibility of release management and any tools that are introduced can enable applications and the teams working on them to work in harmony, and ultimately improve the value that is delivered to customers.

    — Jeffrey Keyes

  • Building Your Data Science Team from Within

    Building Your Data Science Team from Within

    The global machine learning (ML) industry is increasing at a compound annual growth rate of 42% and will be worth $9 billion toward the end of 2022. Despite this figure, there are many cases of data science teams’ failure to deploy a reliable artificial intelligence (AI) product or service.

    Part of the failings and shortcomings of AI concern the ramp or process for getting there. For an AI project to succeed, it is critical to have your data fully deployed, available, structured and cleaned. You also must have some algorithms (ML/deep learning/natural language processing) ready to pull the insights and focused data, effectively putting the intelligence into AI.

    This requires a very specific skill set and talent pool.

    Empower Your Data Analysts

    With so many different technology fields colliding, machine learning is a difficult area to master. Deep reinforcement learning (DRL), natural language processing (NLP), AutoML tools, ML Ops, neural networks and model-based reinforcement learning are just some of the subjects required to master ML.

    With a shortage of talent and shortfall of data scientists, this is easier said than done. Part of this is because the demand far outweighs the supply, with Bloomberg estimating job postings for data scientists rose 75% from 2015 to 2018. Almost every organization shares this same urgent need.

    When faced with a skills gap in their teams and stiff competition in recruiting, how can organizations effectively build a data science team?

    One way is to start by looking at your data analysts. They are often swimming in disparate, federated data sources, operating on legacy databases, working with mixed data sources and using Excel to do things it was never intended to do. There is an enormous opportunity to empower data analysts to become data scientists.

    From Data Analyst to Data Scientist

    Companies looking to hire data scientists from within need to think about how to upskill, reskill or preskill their data analysts to perform the roles needed to implement AI and ML fully. I’m a believer that if you provide prescriptive and progressive curricula around the essential topics a budding data scientist needs, you can equip them with the skills and knowledge to make a difference and move them forward in the organization.

    However, it’s not enough to simply equip these employees with a curriculum; the program should have numerous twists and turns. Why? When thinking about how you can train the prototypical ML expert of the future, you must consider all the deep tech skills needed. You also want the business and social skills that are required to attain the expert moniker. A well-rounded ML architect will see the business imperatives, understand how to communicate with engineering and business, and have the tech skills to deploy ML models that benefit your business and customers.

    When organizations take roles commonly found in the workplace, such as data analysts, provide them with a sequenced path of instruction that moves them toward an aspirational role, they’ll be well-positioned to realize the full potential of AI and ML.

    — Mike Hendrickson

  • Fast Data is Forcing New Strategies in DevOps

    Fast Data is Forcing New Strategies in DevOps

    DevOps has established itself as a critically important discipline, developing and leveraging unique tooling and processes to deliver many types of applications more rapidly, efficiently and reliably. As data has become a more central component in these applications, DataOps has emerged to work hand-in-hand with DevOps to better support the role of data in the modern enterprise.

    Yet, a new generation of applications–such as real-time, data streaming and microservices applications, including a growing share that run natively in and across the cloud and datacenter–is already threatening to upend established practices and tools that have been the foundation of DataOps and DevOps collaboration. DevOps is built around an agile mindset, but what must the discipline itself do to adapt?

    These new applications are born of the concept of fast data: acting and reacting to data immediately as it hits the enterprise. In contrast to classic big-data applications that gather, aggregate, store and then later process information–typically in batches–fast data focuses on immediacy to transform, refine and analyze data as it arrives, enabling users, applications and services to quickly act on that information. In many instances this is in support of a larger breed of intelligent applications expected to act on the data without requiring any sort of human intervention.

    The organizational benefits come in the form of speed and improved insight. While the former might be obvious, the latter is no less important: Knowing and acting on what’s happening right now significantly improves accuracy, nimbleness and responsiveness.

    For DevOps, success in this new era of fast data applications is not possible by applying existing practices and solutions. It requires an evolution, both in those tools/practices themselves, and in how teams approach and think about the overall process of being part of a data-driven organization.

    That’s because a number of things change in the world of fast data:

    • Applications are no longer self-contained but comprised of many interdependent components that may stretch across geographies, infrastructure and disciplines.
    • Data flows are the critical link between these components.
    • Data is being collected, processed, analyzed and acted upon before it reaches traditional repositories such as data lakes or data warehouses (if it ever reaches them at all).
    • Fast data applications in production must always be on to keep up with the flow of data, and must frequently handle significant scaling challenges, both up and down.

    As an example of these new considerations, contemplate a classic scenario that might consist of a database and content application, with middle-tier logic in between. A typical DevOps process might involve an update to that mid-tier logic that is then deployed, tested and iterated.

    In the realm of fast data, you might instead have eight different data services that talk to a dozen different components, all of which communicate with yet more downstream processing applications. Deploying any changes in isolation without an understanding of the various data service and application interfaces might cause the whole system to fall apart. Working in the world of fast data requires the DevOps team to work with DataOps to validate that individual components can be updated and deployed without harm, or establish how to deploy the whole system or portions of the system as a set. These are considerations that weren’t in play when the number of interface points was relatively small and relied on standard protocols or processes.

    Fortunately, there are steps DevOps can take to successfully enable these new fast data applications, including:

    • Recognize the necessity of delivering streaming/real time/fast data infrastructure not only for the production environment, but also for the development environment. Most of development and testing for monolithic batch applications can be done using basic infrastructure. However, development and testing of fast data applications requires infrastructure that can stream and process data on-demand. DevOps teams need to deploy data infrastructure that can easily support that.
    • Work with DataOps professionals and/or principles to implement technologies and processes that make it easy to move fast data applications from testbeds into full production environments. Fast data applications are typically composed of a set of services, so moving an application into production requires a carefully coordinated and orchestrated process. DevOps needs to make that process as simple and reliable for developers as possible.
    • Support an always-on environment. Fast data applications by definition need to act on data as soon as it arrives. That means that maintenance downtime for upgrades or reconfiguration is not allowed. DataOps teams need to identify and choose technologies that are designed to operate without interruption or disruptive degradation not only in the face of failures but also in the face of day-to-day maintenance and operations.
    • Design for the cloud from the start. Fast data applications are typically deployed all or part in the cloud, collecting, acting on and distributing data inside and outside the enterprise. That makes it critical for DevOps teams to choose fast data technologies that offer cloud-native resiliency, scalability (up and down), high performance and ease of configuration/operation.

    As mentioned earlier, it’s also important DevOps teams adjust their perspective toward data flows supported by infrastructure, rather than just considering application components.

    Holistically, data is flowing through a series of interconnected components toward an outcome; the components themselves are just transitional steps in that journey. Changes to any given component must be framed in terms of implications both upstream and down. If a component is changed, does the upstream source need to adjust accordingly? Does the adjustment impact downstream users/applications that rely on the data flow? In larger scenarios this upstream/downstream journey might entail multiple hoops to different systems and business processes. It’s no longer possible to approach changes with a break/fix mentality of a few interconnected components, it must instead consider the deployment or revision to an entire data flow that might rely on a large number of microservices.

    Fast data applications—from retail and manufacturing to financial services, media/entertainment and more—aren’t just coming in the future, they’re already here and are enabling a wealth of new business opportunities. DevOps teams need to adjust their practices and tools to best accommodate this new paradigm that’s equally about the data flow and the applications. And they can start preparing for this new fast data landscape by asking a single question: What could I do if I knew what the customers, partners and systems were doing right now?

    — Karthik Ramasamy