devopsy.kinsta.cloud

Category: Blogs

Survey Sees Observability Costs Spiraling Out of Control

A survey of 200 DevOps professionals working for organizations that generate $50 to $500 million in revenue found observability costs have become more challenging to control.

Conducted by Wakefield Research on behalf of Edge Delta, a provider of an observability platform, the survey found nearly all respondents (98%) have experienced overages or unexpected spikes in costs at least a few times a year, with 51% seeing overages or unexpected spikes in spending at least monthly. Only 1% of companies claimed their observability costs are not rising.

The most common causes for those spikes in cost are product launches and updates (46%), followed closely by log data being mistakenly included for ingestion (42%).

A full 93% said their leadership team is very or somewhat aware of rising observability costs, with 91% anticipating increased scrutiny to reduce costs in the next 12 months.

As a result, 84% agreed they’re paying more than they should for observability, even when they limit how much log data gets ingested.

Edge Delta CEO Ozan Unlu said it’s clear that while organizations are investing in observability to increase overall resiliency, the cost of that investment is higher than anticipated because the underlying platform being used was not designed to consume, store and analyze data at the level of scale required.

As a result, the survey found DevOps teams are attempting to reduce those costs by limiting log ingestion often or all the time (82%), with 98% also limiting the amount of log data they collect.

Despite those efforts, 83% noted that their decision to ingest or not ingest data has led to a dispute within their company.

Other issues that arise include increased risk or compliance challenges (47%), additional staff time spent preparing data for ingestion (47%), internal tension from not ingesting data for some teams/functions (42%), disruptions to processes dependent on data pipeline (42%), loss of valuable insights and analytics (38%) and failure to detect a production issue or an outage (31%).

On average, log data has grown 5x over the past three years, and nearly a quarter of respondents (22%) experienced a growth rate of 10x or higher. Well over a third (38%) generate between 500GB and 1TB of data daily, while 36% generate over 1TB. Only 15% generate more than 10TB of data daily.

Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue. In comparison, legacy monitoring tools are designed to enable the IT team to track a pre-determined set of metrics that are typically less granular.

It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments grow and become more complex, the need for observability is becoming more acute.

The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. Instead, the issue is understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs.

In the meantime, the rate at which IT environments are becoming more complex is clearly outpacing the amount of budget dollars being allocated to manage it.

October 9, 2023
Five Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Indeed.com

Intel
Chandler, Arizona
Cloud Software DevOps Engineer
$156,410 to $250,410

LinkedIn

General Dynamics Information Technology
Remote
Cloud FinOps Analyst
$122,336 to $204,360

CareerBuilder.com

Infoway Software
Doral, Florida
DevOps Lead
$120,000 to $190,000

SimplyHired

Peraton
Herndon, Virginia
DevOps Systems Engineer
$112,000 to $179,000

Dice.com

University of Virginia
Charlottesville, Virginia
DevOps Developer
$95,000 to $125,000

October 9, 2023
FB Scrolling

October 9, 2023
Building Scalable Cloud Applications With MySQL

Relational database systems such as MySQL have long been the go-to choice for handling large and complex data handling tasks. But, with the introduction of new technologies like NoSQL, many developers started to question whether traditional relational databases still have the upper hand. However, when building high-scalability cloud applications, relational databases like MySQL still have the edge over NoSQL. Here are five reasons MySQL remains superior to NoSQL in supporting developers of high-scale cloud applications.

1. Enablement of Complex Queries

Structured query language (SQL) is the most widely adopted language for relational databases, and MySQL is no different. SQL gives developers a powerful platform for creating complex queries and ad hoc reports, efficiently managing large datasets and creating tables and indexes for data optimization. By contrast, NoSQL usually offers only rudimentary query and data manipulation capabilities, often proving inefficient when handling complex data sets. Most data analysts are also familiar with SQL, so it’s a drop-in tool they can use to help gain insights.

2. Scalability and Reliability

MySQL is noted for its scalability when handling massive data loads and is particularly well suited to cloud-based applications that require consistently high performance. MySQL ensures that the consistency of data is maintained. MySQL is the go-to option for scalability and reliability for larger cloud applications. Companies such as Facebook, GitHub and WordPress have built billion-dollar businesses on MySQL, and it’s been tested and validated in some of the harshest and most demanding workloads of any database.

3. High-Performance Replication at Scale

MySQL replication offers a reliable solution for cloud applications that need to scale. Unlike other databases, MySQL’s replication capabilities provide effective data safety, making it a robust choice for applications that require high availability and durability. Additionally, MySQL enables seamless version upgrades without disrupting operations, ensuring the system always has the latest features and security patches. The read scaling feature of MySQL improves performance by distributing the read load across multiple instances, making it ideal for large-scale cloud applications. With a proven track record at scale, MySQL replication is the optimal choice for applications that want to grow and scale efficiently.

4. High Availability and Durability

MySQL provides enhanced high availability and durability, ensuring that critical data is always available even during maintenance and disaster recovery. This is because MySQL is fully ACID-compliant (atomicity, consistency, isolation, durability) and provides full support for transactions. Even when the system fails, the transaction can be rolled back and the data is not lost. With NoSQL databases, data is primarily written in memory and doesn’t provide the same degree of durability or consistency.

5. Ease of Implementation and Debugging

MySQL is easy to install, implement and debug compared to NoSQL. MySQL is supported by a large community of developers and database administrators who use it for a diverse range of applications. MySQL is also open-source and free to use, making it a great choice for businesses of all sizes. NoSQL systems require the installation of additional tools, libraries, and other components for implementation, making it more complex and time-consuming.

MySQL provides many benefits for developers of high-scale cloud applications, ranging from its powerful SQL language for complex querying to its high availability and flexibility for managing multi-table joins. NoSQL remains a viable option in some cases, but developers who are building high-scale cloud applications are mainly sticking with MySQL due to its scalable and reliable nature, easy implementation and flexible query-handling capabilities. Choosing the right database engine is critical for any organization that relies heavily on large and data-heavy applications. MySQL continues to stand the test of time when it comes to ensuring performance and getting consistent results.

October 6, 2023
How Event-Driven Architectures Drive Real-Time Operations

People, events, the human brain—in fact, the whole world operate in real-time, but businesses have struggled to keep up. With the help of event-driven architecture (EDA) and the Open API economy, businesses can now do the same. The power of an event-driven world means that, after years of geopolitical events affecting how businesses operate, many businesses are starting to uncover real value by truly being able to operate in real-time.

Whether it be retail and manufacturing or energy and resources and financial services, locating and responding to vital issues within a company’s supply chains or product lines in real-time, is key to success.

Amazon’s CTO, Dr. Werner Vogels, said that “the world is event driven” in his keynote speech at AWS re:Invent in December 2022. Now, new IDC research unveils that nine out of 10 of the world’s largest companies will deploy real-time intelligence driven by event-streaming technologies by 2025.

But What’s the Secret Behind Such Success?

A recent IDC Infobrief, sponsored by Solace, surveyed over 300 enterprise IT professionals in North America, Asia and Europe, all of whom work for large companies implementing or considering EDA. The results are quite telling–an overwhelming 93% of respondents at companies that have deployed EDA across multiple use cases said EDA has either met or exceeded their expectations. In addition to technical advantages from EDA, most businesses also see clear business benefits: A full 23% of respondents reported increasing productivity; 22% said better customer acquisition and 18% saw revenues increase as a result of EDA efforts.

1. Get Support From the Top to Ensure Alignment Throughout

Expanding the footprint of EDA across the enterprise is a journey, and every journey starts by assembling those that are critical to its overall success. Business sponsorship and engaging key stakeholders is vital, especially in the early days of EDA adoption – 56% of respondents in the early EDA stages cited this as a priority when ROI and business benefits may not be immediately clear.

The impact of well-aligned C-suite, operational and technical teams is reflective of business-level digital maturity, too. As 35% of respondents at an advanced stage of EDA rollout felt C-level support was critical, it comes as no surprise that respondents with higher levels of EDA maturity also have higher levels of overall digital maturity, including digital strategy and change management support.

2. Tackle Complexities Head-On With the Backing of IT

As EDA becomes more pervasive across an organization, demands on IT become more sophisticated, requiring a deepening of EDA skills in the IT organization, notably with DevOps teams, developers and architects. More than one-third (36.1%) of respondents cited the lack of skills to execute EDA as a hurdle to adoption. Approaches to logging, governance and oversight (30.7%) can also become increasingly challenging and must be thought through carefully.

This is where EDA providers themselves need to step up and provide adequate training and a certification path for architects DevOps and developers looking to gain the fundamental knowledge and skills to design and implement event-driven systems. This should include technical details such as understanding various design patterns for EDA, microservices choreography versus orchestration, the saga pattern and RESTful microservices. Education should also clearly define and demonstrate key concepts and tools for EDA success, such as event portal, topic hierarchy best practices and event mesh.

3. The Benchmark for Success Chops and Changes: Businesses Need to Go With the Flow

The right measures of EDA success in the early days of adoption are not the same measures as EDA adoption grows over time.

Fewer EDA-mature organizations cited “cost reduction” (23%) and “number of projects completed” (31%) as top measures of success. In the medium term, after two or three use cases, most organizations saw “operational stability” along with “number of projects” to measure success. Further, after broad adoption, “increased revenue” (43%), “operational stability” (32%) and “amount of resiliency” (30%) become more important measures.

This changing set of measures is reflective of the maturity curve of EDA adoption across multiple applications within a business’s ecosystem. A business is truly operating in real-time when deploying EDA across key customer-facing, employee-facing and supplier-facing organizations. This is where revenue is being generated in high volumes, organization-wide – hence stability and resilience become key to ensuring things continue to run smoothly on what can often be a global scale.

4. Keep Everyone in the Loop

It is essential to take the company with you along the entire journey. The research showed the bumps in the roadmap. In the early stages of EDA maturity, lack of understanding of EDA benefits and inconsistent buy-in are the most frequently cited organizational challenges (38%). As organizations progress to a centralized EDA status, cost concerns (42%) and finding the right use cases (36%) can hamper success. More advanced stages of EDA also cite a lack of understanding of EDA benefits (45%), and cost concerns (39%) but change resistance (38%) becomes a major hurdle.

Continuous focus on change management and communicating business benefits is vital. The core group of invested stakeholders who began the journey must band together to demonstrate the value of EDA clearly and consistently to other areas of the business on a regular basis.

5. Recognize the Benefits That Partners Bring to the Table

To accelerate business and technical benefits and reduce the impact of challenges, survey respondents cited “finding a supportive partner to assist with the implementation of EDA” (37.7%) as a critical consideration. Partnerships and product integrations with the providers of preferred business software and SaaS services can make it easy to event-enable an organization. Given the amount of new technical skills and learning previously cited, this can provide peace of mind for organizations taking their first steps on the journey to EDA.

EDA isn’t just a change in IT architecture, it’s a mindset that applies to modern business leadership organization-wide. To keep the momentum during the journey, respondents also noted the use of a robust change management plan that “ensures coordinated middle management support” (35.1%), as they are typically accountable for getting work delivered and reporting across the organization.

EDA Becomes the Norm

The InfoBrief results speak for themselves – EDA is quickly becoming the “normal” process for businesses looking to operate in real-time. As more and more companies recognize the business benefits at stake, understanding these five requirements will be a necessity for successful EDA deployment.

October 6, 2023
Latest DORA Report Highlights Importance of DevOps Culture

A 2023 Accelerate State of DevOps Report published today by the DevOps Research and Assessment (DORA) team at Google Cloud found teams with generative cultures composed of people who felt included on their team have 30% higher organizational performance than organizations without a generative culture.

The report was based on a global survey of 36,000 IT professionals and tracked deployment frequency, change lead time, culture, change failure rates and failed deployment recovery times.

Overall, the survey found that while just under a third of respondents were successful in terms of their ability to deploy on demand (31%) and keep remediation efforts after deployments to 5% (33%), only 18% had lead times for changes of less than one day, while only 17% had a failed deployment recovery time of less than an hour.

This is an area where DevOps teams appear to need the most amount of help; nearly two-thirds (64%) of software releases or updates required some level of remediation after deployment, according to the report.

Nathen Harvey, developer advocate for DORA and Google Cloud, said the one area most underappreciated when it comes to improving performance is documentation. High-quality documentation leads to 25% higher team performance, the survey found.

DevOps teams that rely on the public cloud also benefited from a 22% increase in infrastructure flexibility, resulting in 30% higher organizational performance, noted Harvey.

The survey also noted that, as far as reliance on artificial intelligence (AI) to automate DevOps workflows is concerned, it’s still early. But most respondents are, at the very least, experimenting with one or more use cases.

In general, the management of DevOps will soon be very different as more AI capabilities are leveraged to eliminate bottlenecks and reduce toil. The immediate challenge is developers are benefiting more from AI than software engineers, which is resulting in more code starting to simultaneously move through DevOps pipelines. There is little doubt that in the months ahead there will be increased reliance on AI to manage pipelines at greater scale. In the meantime, it will be increasingly difficult to manage codebases that are steadily getting larger as developers become more productive.

At the same time, more organizations are embracing platform engineering as a methodology for centralizing the management of DevOps workflows at levels of scale that previously were difficult to achieve.

Hopefully, the combination of platform engineering and AI will result in less overall burnout among DevOps teams. In the short term, the burnout issue may become more challenging to address as the amount of code being created increases.

In the longer term, the results of the DORA survey may be substantially different next year as AI and platform engineering are employed more widely. The current survey results are not substantially different than in previous years, in the sense that DevOps teams are still challenged by many of the same issues.

Of course, as important as it might be to improve those metrics, the most important thing any DevOps team should focus on is developer productivity which, despite the existence of DevOps pipelines, remains relatively low.

October 5, 2023
Observe Inc. Brings Generative AI to Observability

Observe, Inc. today revamped the Hubble user interface to its observability platform that has been infused with generative artificial intelligence (AI).

Fresh from raising an additional $50 million in funding, Observe CEO Jeremy Burton said as the company’s software-as-a-service (SaaS) platform continues to be infused with AI using multiple large language models (LLMs), it’s becoming apparent that observability is rapidly becoming democratized.

Most IT organizations still rely primarily on legacy monitoring tools to track a set of predefined metrics. Observability platforms have arisen to aggregate metrics, logs and traces to enable DevOps teams to launch queries and surface the root cause of performance issues or IT incidents. The challenge is that most observability platforms have required IT teams to master a proprietary query language such as Observe’s RegEx.

However, with the rise of generative AI tools, it is now possible for IT professionals of all skill levels to employ a natural language chatbot to generate a RedEx query, noted Burton. A RegEx generation tool also parses data to add structure to logs on-the-fly, and there is also an OPAL Co-Pilot that generates OPAL code in response to natural language inputs.

The Hubble interface furthers those capabilities by simplifying the onboarding experience anytime there is a new member added to an IT team, he added. Hubble also expands the range of data access options available, including a public application programming interface (API), a command line interface (CLI), export to CSV and data sharing to the Snowflake cloud platform.

IT teams are also coping with an explosion of telemetry data generated by modern distributed applications based on microservices architectures. Legacy observability and monitoring tools were not designed for these data volumes, so when there is an incident, the mean-time-to-resolution (MTTR) is increasingly extended. In contrast, the Observe platform now features a ‘Live’ mode that enables data to be queried in 20 seconds or less from when it was created.

Other capabilities include an assistant embedded in Slack to help users troubleshoot issues and summarize threads for incident response.

While it’s still early days as far as the adoption of observability platforms are concerned, there is already no shortage of options. The pending acquisition of Splunk by Cisco next year will cause more organizations to reevaluate their IT management options, so the pace at which organizations are transitioning to cloud-hosted observability platforms should increase, noted Burton. Even after the merger is completed, it might be several more months before Cisco integrates its AppDynamics platform with the observability platforms that Splunk added to its IT operational analytics platform, he added.

In the meantime, IT environments are only going to become more complex. It won’t be feasible for most IT teams to manage highly distributed computing environments without some help from AI. The challenge, as always, will be finding the budget dollars needed to deploy an observability platform before the number of increased IT incidents makes the need for one painfully obvious.

October 5, 2023
Something is Amiss in the Open Source World
You don’t have to be a psychic to grok that the winds of change are blowing hard in the open source world. For the last few months, I’ve seen hints and heard whispers about a new direction for what I believe is the most passionate and enthusiastic community in tech. I think we are about to sail off into unchartered territory—and it will be interesting to see what the repercussions are.

Of course, this will all play out against the backdrop of continued layoffs and belt-tightening in the broader tech sector. Before I detail what I think are the telltale signals of change, let me state that I am and have always been a big supporter of open source software. I firmly believe we live in a golden age for open source software, which I call the “Foundation era of open source.” At a time when 90% plus of organizations use open source software, many of the leading open source projects are under the domain of not-for-profit foundations (NFPs) such as the Linux Foundation, the Apache Foundation, etc. This allows multiple commercial companies who might otherwise compete with each other to work in coop-etition. This has, in many ways, enabled this golden age of open source. Prior to the Foundation era of open source, there were two prior dominant models. Initially, there was what I call the “Cathedral and Bazaar era,” named after the great book by Eric Raymond. This was a time of idealistic notions of “pure” open source, unsullied by commercial aspirations. To me, Dr. Richard Stallman embodied that time; if you were to make an analogy to history, it was akin to the 1960s era in the U.S.

From that era, let’s zoom to sometime in the early 2000s when we moved to what I call the “Big Brother era” of open source. In this era, open source projects were owned and managed by one vendor, for all intents and purposes. The project could have a vibrant community, but ultimately, it was the managing vendor or “Big Brother” who reaped most of the rewards. This made it difficult for multiple tool vendors to support the same project and stifled progress.

The dawn of the foundation era of open source changed all that, and we have seen transformational growth as a result. But nothing lasts forever—and I think the king of the hill may be on the way down. Why do I say this? Here are several events/trends I’ve noticed recently that lead me to believe this. Some of these things I was told in confidence, so I cannot reveal names to protect the innocent.
1. The move away from “pure” open source licenses. Over the last few months, several pillars of the open source world have moved away from accepted open source licensing. Red Hat has done so with Red Hat Enterprise Linux (RHEL) and now Hashi has, as well. Now, to some, this change is subtle and it’s not a big deal. Only paying customers get access to source code. The overwhelming majority of users never look at the source code anyway. Nevertheless, this is a huge red flag for the community—the accepted licenses and a core tenant of open source, that source code is available to everyone, are no longer being used.
2. Diminishing corporate financial support for open source communities and foundations. I guess this was to be expected in hard economic times. The path to profits from supporting open source foundations, projects and communities can sometimes be more of a dotted line than direct. And a dotted line doesn’t usually work when the bean counters are involved. In looking to cut expenses, these are low-hanging fruit.
3. Closing foundations. This is a natural result of the economic strife. Foundations may operate as not-for-profits, but without operating funds, foundations can’t operate. Generally, foundations get a lot of mileage from volunteers. However, volunteers can only go so far before hard costs are involved. Also, volunteers are able to volunteer because their corporate employers empower them to do so. When their employers pull back the funding for those activities, the volunteers have to do what they can to earn a living. I have heard of at least one NFP foundation forced to cease or curtail operations due to corporate sponsor funds drying up.
4. Orphaned projects. Again, this is a direct result of number two, above. With the foundations closing and supporting funds drying up, I know of at least two bellwether open source projects that are in danger of becoming orphaned. Both of these projects boast huge community numbers and dominate their markets. The fact is though, that supporting a major project costs hundreds of thousands of dollars. While millions of community members may use a project and support it, they don’t contribute dollars. Dollars that pay for hosting, infrastructure and other hard costs. Coughing up a few hundred grand to support a project is a bridge too far for some companies in the current economic climate.
What does this mean for open source software and you? Well, in the near term, if you are just a consumer of open source software, probably not much will change day-to-day. You may have to cough up some money if you want access to source code or support from the community. Bigger picture, though, is the winds of change are blowing. I think we are going to see more companies taking a Hashi-type approach to protecting their source code. This will result in more forks of open source projects. However, my experience is that most open source forks don’t succeed (with some notable exceptions—like Jenkins forked from Hudson). Companies who are building businesses around open source models will be the most at risk. I think an open core business model may be the best bet for an open source vendor. I think the future of NFPs as the stewards of open source may become a bit cloudy (no pun intended). What will take its place or fill the void? That remains to be seen.

For the record I was never a fan of that old Irish proverb, “May you live in interesting times.” This kind of upheaval is a little too interesting for me. But one thing I have learned in 30 years in tech (and more than that in life) is that change is constant. You can embrace it and thrive or shrivel and die.
October 5, 2023
Moving Beyond Legacy API Management Tools and Strategies

What is legacy API management? That’s a question that many organizations haven’t even thought to ask because they don’t realize that the way they manage their APIs is outdated. On the contrary, they assume that if they have API gateways in place to provide security and load balancing for their APIs, they’re already ahead of the curve when it comes to managing and protecting their APIs.

But the fact is that traditional approaches to API management are fast becoming outdated. In a world where the ability to communicate in real-time is more critical than ever, legacy API management solutions can’t keep up, because they’re not designed for APIs that need to share large volumes of data using asynchronous paradigms.

That’s why forward-thinking organizations should be looking for ways to overhaul their API management tools and strategies. They need to embrace next-generation API management solutions, which can do much more than manage traditional, synchronous APIs.

Allow me to explain by walking through the shortcomings of traditional API management tools and explaining what next-generation API management entails.

Legacy API Management

Legacy API management solutions are tools designed to manage and secure synchronous APIs. Typically, these tools come in the form of gateways that sit between backend REST APIs and applications that connect to those APIs using the HTTP protocol. The gateways manage traffic flows and secure communications between the applications and the API backend.

That approach works well if two conditions are true:

1. All of your APIs are synchronous, which doesn’t always work well with continuous data streams.
2. All of your clients can consume data from APIs using HTTP requests.

Traditionally, these conditions were true for most API use cases at most organizations. That’s why the standard approach to API management is to deploy a gateway, configure some load balancing and security policies and call it a day.

Next-Generation API Management

Increasingly, however, not all data is shared synchronously, and not all applications can consume data using HTTP requests. Instead, businesses want to be able to stream data in real-time to multiple types of applications. They might use an open source event broker like Kafka to stream monitoring data from across their IT assets to the tools that IT engineers use to observe and analyze systems, for example. Or, they might need to stream sales transaction data to a fraud detection engine so it can catch fraudulent transactions in real-time.

For use cases like these, legacy API management doesn’t work well at all. Traditional API gateways aren’t very compatible with event brokers because the gateways are not designed to manage real-time data streams. Nor do they typically support protocols other than HTTP, which is a problem because event brokers like Kafka use their own protocols, not HTTP, to enable communication between servers and clients.

Next-generation API management solutions fill this gap. They operate as gateways that can not only mediate between traditional REST-based client and API endpoints, but also support event brokers, asynchronous APIs, and even apply policies at the message level to support message-based communication.

In addition, next-gen API management tools offer the ability to translate between different front and backend protocols. That means that you could have, for example, a Kafka stream on the backend that is exposed to clients using HTTP – effectively allowing apps that can only make requests via HTTP to connect to Kafka data streams, without having to build support for protocol translation into the applications themselves.

Thinking Beyond Internal APIs

At this point, you may be thinking, “We don’t expose data streams externally, so why would we need a next-gen API management solution to support them?”

That’s a fair point. The most basic use cases for data streaming platforms like Kafka involve streaming data internally – from one set of applications to another within the same IT environment, for example.

But this is certainly not always the case. There are plenty of circumstances where you might want to expose a data stream externally and require the security and reliability protections that next-gen API management tools deliver. Maybe you’re a manufacturer who wants to stream data to regulatory authorities so they can monitor your operations remotely, for example. Perhaps you use third-party monitoring or cybersecurity tools and need to stream data from your own systems to that software. Or, even if you are only exposing APIs and data to internal consumers, perhaps that data contains sensitive PII and additional security mechanisms are still necessary. And, for almost all use cases, being able to centrally expose, catalog, and make APIs discoverable is a major leg up.

Even if your business doesn’t currently expose data streams externally, by the way, there’s a good chance it will in the future. As Gartner notes, “Organizations are improving their decision intelligence and real-time applications by tapping the growing availability of streaming data.” The future for most organizations is likely to include more data streams and more complex use cases for those streams, making the functionality of next-gen API management increasingly critical to business success.

Conclusion

In short, it’s time to move beyond the confines of legacy API management – which means no longer being limited to supporting only REST API management. To capitalize fully on the opportunities enabled by streaming data, businesses need a more flexible and dynamic approach to API management, which requires a new breed of API management software.

October 5, 2023
Intermittent Microservice Problem
In a Kubernetes environment, a recent pod scheduling failure occurred due to a specific configuration. Which Kubernetes resource type, often associated with node constraints, might have caused this failure, especially if it wasn’t defined correctly?
1. NodeSelector
2. ResourceQuota
3. PriorityClass
4. Taint
5. PodDisruptionBudget
201 people answered the question. And their answers are reflected in the chart below.

The wording of this question is deliberately tricky, especially the part about “often associated with node constraints”. The correct answer, therefore, is “Taint”. 46 people, 23% got it right. A very close, very likely, answer is “NodeSelector” but one that is not a “node constraint”. An additional 54, 28%, picked this option. Let’s discuss why “Taint” is the right answer in the context of a pod scheduling failure due to a specific configuration, and why the other choices are not as suitable.

Taint (Correct Answer):

Taints in Kubernetes are node-level attributes that can be applied to nodes to affect pod scheduling. When a node is tainted, it essentially broadcasts a constraint to pods that they should not be scheduled on that node unless they have a corresponding “toleration.” Here’s why taints are the correct answer:

Node Constraints: Taints are directly related to node constraints. They allow you to specify criteria that restrict which pods can run on specific nodes based on attributes like hardware, software, or other node characteristics. This makes them a crucial resource for controlling where certain workloads are placed within the cluster.

Pod Scheduling: When taints are applied to nodes and pods do not have matching tolerations, they will not be scheduled on those tainted nodes. If a pod is failing to schedule due to a node constraint issue, it’s likely because of taints.

NodeSelector (Not the Best Choice):

NodeSelector is a Kubernetes feature that allows you to set node affinity for your pods based on labels assigned to nodes. While it does influence pod scheduling, it is not primarily associated with node constraints set at the node level like taints.

Node Affinity: NodeSelector is more about node affinity (i.e., preferring nodes with certain labels) rather than constraints. It doesn’t directly prevent pod scheduling but rather guides the scheduler’s preference.

ResourceQuota (Not Related to Node Constraints):

ResourceQuotas are Kubernetes objects that limit resource consumption (CPU, memory, etc.) within namespaces. They do not directly influence pod scheduling based on node constraints, making them less relevant to the given scenario.

Resource Limitation: ResourceQuotas control resource usage within namespaces, but they do not define node-specific constraints or affect where pods can be scheduled within the cluster.

PriorityClass (Not Related to Node Constraints): PriorityClasses are used to prioritize pods in scheduling order, but they do not define node constraints like taints. They affect the order in which pods are scheduled but do not directly relate to why a pod may fail to schedule due to node-specific constraints.

Scheduling Priority: PriorityClasses are about setting scheduling priorities, not specifying where pods can or cannot run based on node characteristics.

PodDisruptionBudget (Not Related to Node Constraints):

PodDisruptionBudgets are used to control the disruption of pods during voluntary disruptions (e.g., draining a node). They are not associated with node constraints or pod scheduling based on node attributes.

Disruption Control: PodDisruptionBudgets are for controlling disruptions during node maintenance or other planned events, but they do not deal with node constraints affecting pod scheduling.

In summary, when debugging a pod scheduling failure due to a specific configuration, especially one related to node constraints, “Taint” is the most appropriate answer because taints directly influence pod scheduling based on node attributes, whereas the other options are not primarily associated with this aspect of Kubernetes resource management.

DevOps/SRE run into these scenarios all the time. Troubleshooting these scenarios by analyzing each of the above options is time consuming. Coupled with the frequency of their occurrence makes debugging such failures prohibitively expensive unless there is an escalation and this prevents DevOps/SRE to be proactive. It’s the classical example of technical debt on which we never land up making a down payment. The usual answer is “hire more people”. Do you agree with this or have you found a way out of this dilemma? Please send us your thoughts to TheNeoQuiz@webb.ai.
October 5, 2023