devopsy.kinsta.cloud

Tag: DevOps

Elevated Resource Levels
A microservice in your Kubernetes cluster has been exhibiting intermittent performance degradation after a recent code change. What could be potential root causes of this issue? (Select two correct answers)
1. Incorrect Prometheus alerting rules
2. Elevated resource limits for the microservice pods
3. Inadequate PodDisruptionBudget configurations
4. CPU and memory pressure on worker nodes
5. A misconfigured HorizontalPodAutoscaler (HPA)
Such an issue is challenging to debug with observability tools alone and requires a deeper understanding of the Kubernetes infrastructure. 123 people answered this question with 24% getting it right.

Here’s a detailed explanation.

Correct Answers:
2. Elevated resource limits for the microservice pods:
When dealing with intermittent performance degradation of a microservice in a Kubernetes cluster, elevated resource limits for the microservice pods can be a significant root cause. Resource limits for pods are defined in their YAML configurations using the resources field. This issue can lead to resource contention, causing performance bottlenecks.

4. CPU and memory pressure on worker nodes:
Worker nodes in a Kubernetes cluster can experience CPU and memory pressure when resource demands from pods exceed the available capacity. This can lead to performance degradation for all workloads running on the affected nodes. SREs and DevOps need to monitor node resource utilization and take corrective actions.

If high resource usage is detected, it may be necessary to scale the cluster by adding more nodes, tune resource requests and limits for pods, or optimize applications to use resources more efficiently.

Incorrect Answers:
1. Incorrect Prometheus alerting rules:
Prometheus is a powerful monitoring and alerting system used in Kubernetes, but issues with alerting rules are unlikely to directly cause intermittent performance degradation in a microservice. While it is crucial to have correct alerting rules set up to detect issues, issues with alerts are typically associated with visibility and observability, not the root cause of performance degradation.

3. Inadequate PodDisruptionBudget configurations:
PodDisruptionBudgets (PDBs) are used to control the disruption of pods during maintenance or updates. While they are essential for ensuring high availability, they are not directly related to performance degradation. Inadequate PDB configurations may lead to pod disruptions during updates, but this would result in unavailability rather than intermittent performance issues.

5. A misconfigured HorizontalPodAutoscaler (HPA):
A misconfigured HPA could potentially lead to over-scaling or under-scaling of pods, but it’s unlikely to be the root cause of intermittent performance degradation. HPAs primarily deal with pod scaling based on resource utilization, and their misconfiguration would affect scalability rather than performance degradation.

In summary, when dealing with intermittent performance degradation in a microservice within a Kubernetes cluster, SREs and DevOps should focus on resource allocation (resource limits) for pods and monitoring node resource usage. Elevated resource limits for pods and CPU/memory pressure on worker nodes can directly impact performance. While observability and alerting (Prometheus) are essential for detecting issues, they are not typically the root cause of performance problems. Similarly, PDBs and HPAs are more related to availability and scaling but do not directly address performance degradation issues.
October 12, 2023
4 Mobile Software Testing Use Cases Where Device Clouds Don’t Work

A device cloud, which provides on-demand access to a variety of different types of mobile devices, may seem like the most efficient and effective way to run mobile tests–and it is, in many scenarios.

But depending on which types of mobile tests you need to run or how you need to run them, they aren’t always the best solution. If you blindly turn to device clouds by default to meet your test infrastructure needs for all use cases, you could end up shooting yourself in the foot.

To prove the point, I’d like to walk through four mobile testing use cases where you either fundamentally can’t use a device cloud or where the disadvantages of cloud-based mobile testing outweigh any benefits of the strategy.

What is a Device Cloud?

Before diving into a discussion of mobile testing scenarios where device clouds don’t make sense, let me make clear what I mean by “device cloud.”

I’m referring to a cloud-based mobile testing environment where developers and QA engineers can run software tests on remote devices. In other words, a device cloud is a “cloud” of mobile devices you can access on demand for executing tests. Device clouds are an alternative to running tests on mobile devices that you have to set up locally and manage yourself.

They have become a popular solution for mobile testing because they offer several benefits compared to testing with local devices:

● Testers can easily test applications across hundreds or thousands of different mobile devices without having to purchase and set up each device themselves.
● You typically pay only for the time during which your tests run, making device clouds a more cost-effective solution in many cases than testing on devices that you have to acquire locally.
● Because most providers add new types of mobile devices to their clouds on a regular basis, testing teams always have access to up-to-date mobile hardware.

A variety of vendors (including Kobiton, where I work) offer device clouds that deliver these benefits.

Why Device Clouds Don’t Always Work for Mobile Software Testing

Device clouds are great for use cases where teams need to test mobile apps across many mobile devices and don’t face special requirements. However, depending on your needs and priorities, they may not make sense for your testing routine.

Here are four scenarios where you can’t or shouldn’t use a device cloud for mobile testing.

1. Testing for infrastructure disruptions

Devices hosted in a device cloud operate under best-case conditions. They are fully charged, professionally managed devices that are connected to very stable, high-speed networks.

That’s good in the respect that it means the devices can run tests reliably. But it’s bad for teams who want to understand how their mobile software performs under less-than-ideal circumstances. If you want to know how Bluetooth interference or a spotty cellular connection could impact mobile app performance, for example, you won’t be able to simulate those conditions using a device cloud.

You can simulate these conditions by deploying devices locally in what QA professionals call an isolation chamber, where testers can introduce “chaos” like weak network connections to evaluate how the software responds.

2. Testing mobile apps with strict security requirements

Testing software on a device cloud requires you to upload your applications, along with any data that you need to feed into them for testing purposes, onto mobile devices owned by a third party.

In most cases, this isn’t a big deal. Providers secure their infrastructure and network connections to protect sensitive data.

But if you’re dealing with exceptionally rigid security requirements–as you might in highly regulated industries or in situations where you’re testing apps that manage very sensitive data–a device cloud might create too many security risks. You’re better off in that case testing on-premises, where you have full control over data and software.

3. Minimizing test execution time

Mobile software tests that take place on remote devices hosted in the cloud almost always take longer to complete than tests that run locally. The main reason why is that cloud-based tests require data to move over the Internet, which is slower than local network connections.

To be clear, we’re talking about delays of perhaps only 200 or 300 milliseconds. In most cases, that’s not a big deal. But if you require ultra-fast test execution, which is beneficial in scenarios where you need to run a large number of tests and you don’t want them to delay your software delivery pipeline, cloud-based testing might slow you down too much.

4. Testing on obscure devices

Major device clouds cover most of today’s most popular types of mobile devices, which makes them a great solution if you need to test on devices that are widely used by consumers.

But if you need to ensure that your apps run on more obscure devices–such as specialized IoT devices that you might use in your company’s facilities–you’re less likely to find them in a device cloud. You’ll need to acquire the specialized hardware and run tests on it locally.

Conclusion

Device clouds are a great way to meet garden-variety mobile testing requirements. However, not every mobile testing use case is simple enough to support using a device cloud. Sometimes, tests require a level of security, performance and control that only local mobile test environments can deliver.

October 12, 2023
HashiCorp Streamlines Workflows to Improve Productivity

HashiCorp today launched a series of tools to address everything from streamlining the way infrastructure is managed and applications are delivered to how secrets are kept.

Announced at the HashiConf Global conference, these latest offerings extend the Terraform and Vault portfolio to enable DevOps teams to programmatically automate DevSecOps workflows.

Specific capabilities added to HashiCorp Terraform and Terraform Cloud include a test framework to, for example, reduce misconfigurations along with, in beta, tools for generating tests, tools for launching tests across integrated Terraform modules and a private preview of tools for provisioning infrastructure at scale. In addition, the company is generally making available an enhanced editor for finding and resolving errors in code created using Visual Studio Code.

In terms of costs, Hashicorp is also making generally available an ephemeral workspaces capability to limit the amount of infrastructure resources consumed by Terraform itself.

At the same time, HashiCorp has extended Waypoint on the HashiCorp Cloud Platform (HCP) to define golden paths and workflows for application delivery using templates and add-on modules that make it simpler to identify dependencies. Waypoint was previously announced and is still in beta.

Finally, Hashicorp is adding an alpha edition of HCP Vault Radar, a tool to scan, identify and remediate secrets inadvertently stored in software, in addition to making HCP Vault Secrets generally available and adding a secrets synchronization capability, available in beta for Vault Enterprise and HashiCorp Vault 1.15. HCP Vault Radar is based on technology that HashiCorp gained with the acquisition of BluBracket. HCP Vault Radar will be available in beta in early 2024.

Chris Van Wesep, senior director for product marketing for HashiCorp, said, in general, the company is committed to making it easier to securely manage IT infrastructure and applications at scale across multiple IT environments.

While infrastructure-as-code (IaC) tools such as Terraform have been a boon to productivity, the developers that typically employ these tools have little to no cybersecurity expertise so it’s not uncommon for mistakes to be made. The issue organizations are struggling with today is cybercriminals have become more adept at exploiting those vulnerabilities.

At the same time, secrets management has become a significant issue because many developers will store secrets in plain text to streamline workflows while building an application. Unfortunately, many of these secrets wind up being exposed in a production environment simply because no one remembered to remove them.

It’s not clear to what degree organizations are centralizing the provisioning of IT infrastructure to improve cybersecurity. As forthcoming regulations increasingly require them to lock down their software supply chains, however, it’s only a matter of time before most organizations that build software will need to revisit their DevSecOps workflows.

In the meantime, the hope is those goals can be achieved without adversely impacting developer productivity. The level of cognitive load on developers today is already too high, so the more processes are automated, the less time developers should have to spend managing infrastructure. The challenge, as always, is achieving that goal in a way developers will actually embrace.

October 11, 2023
The Ultimate Measure of Software Development Effectiveness

There is a famous quote by Peter Drucker that states, “You can’t manage what you can’t measure.” In our industry, measuring how quickly we can get working software into the hands of our customers has become a mantra for agile development teams, and it’s even being talked about in the boardrooms.

Customers measure the value of software by how quickly it can solve their problems. Customer needs change constantly. Just like us, they are responding to the needs of their own customers. Reacting quickly to customer feedback and turning that feedback into working features is key to customer satisfaction and retention.

Having these directives in mind, it’s no wonder our teams are being asked to deliver working software sooner. Often, the main roadblock in achieving this goal lies not in developing the features but in getting them deployed.

Let’s focus on three areas that determine your team’s deployment performance, which, in turn, directly impacts your software development effectiveness.

1. Frequency of Deployments

When I meet developers, I ask them a simple question: How often do you typically commit your code? A typical answer is a few times a day or even a few times per hour. However, if you ask the same person a question about how often their application is deployed to production, the answer varies widely.

Some will say weekly or daily or still – very rarely – even a few times a day, which is software development nirvana. However, a more common answer is monthly or quarterly. I’m also not surprised if someone says that they release annually. They say it with an honest level of pride and accomplishment.

Let’s put these two things – code commit and deployment frequency – into a broader perspective. If the goal of measuring software development effectiveness is getting working software into the hands of the users, it doesn’t matter how often you commit your code but how often you can give your users new value.

Delivering small improvements to your customers has more impact on client satisfaction than giving them a big gift (new release) once a year.

2. The Control of the ‘Launch’ Button

Triggering a deployment includes someone instructing a deployment, pushing a “deploy” button, or committing triggered deployments. How many people in your organization can promote the application to a production environment? If this privilege is limited to a single person or just a handful of people – we have a problem.

There are many reasons you might want to limit access to production. It could be because you don’t have safety measures built into your deployment process, such as role-based access control. You may believe in the delusion that you can protect your organization just by having fewer people with access to the production environment.

The reality is that artificially limiting user access to production significantly reduces your chances of deploying frequently. Imagine if the “person in charge” must take a sick day or is traveling. Remember that access to the production environment is also required for bug fixes when your organization applies a fix-forward versus rollback strategy.

3. The Level of Deployment Automation

Measuring software development performance is directly correlated to the level of process automation. You can’t manually deploy to hundreds or thousands of customers in a reasonable amount of time. The manual process does not scale, as time is the one thing we can stretch.

Ask yourself: Is your deployment process manual, partly automated (where parts of the process are automated, such as scripts that can be triggered to perform application deployment tasks), or can you claim that you fully automated your deployment process where there is no manual intervention, apart from push-button approvals.

The more you automate your deployment process, the more productive your development team can be. For complex deployments, you may need to target many customers, sets of infrastructure or even physical locations. You might need to apply different configurations or hit agreed maintenance windows for customers or regions. One way to accelerate software delivery for these scenarios is tenanted deployments.

Tenanted deployments capture these differences and apply them to a shared deployment process, allowing the complexity to be automated. You can manage tenanted deployments with tags, variables and customizations while reducing the cognitive load for team members.

There are many ways deployment frequency impacts software development effectiveness. When you deploy more often, you reduce deployment risk, increase quality and get feedback sooner. One action you can take to reduce batch sizes is to increase deployment frequency. Smaller batch sizes will also allow you to recover faster when a problem arises.

Remember that the longer the time between deployments, the more changes and points of failure build up.

As you think about ways to increase software development effectiveness, think about the deployment process as a way to get close to the ultimate measure of developer success–getting the working software into the hands of customers sooner!

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.

October 11, 2023
Using DORA Metrics to Measure DevOps Success

The DevOps Research and Assessment (DORA) metrics have fundamentally changed how leaders interact with developers—and, in turn, how developers interact with their code. Although these metrics have changed significantly since their introduction in 2014, their intent remains to provide a numbers-based approach to improving the developer experience.

DORA metrics play a critical role in many development workflows. These metrics posit that four focus areas—deployment frequency, lead time for changes, change failure rate, time to restore service and reliability—can differentiate high-performing software engineering teams (elites) from lower-performing teams (non-elites).

Why is this a meaningful difference? High-performing teams reliably achieve faster time-to-market by removing menial tasks from their workload and expediting the development and deployment processes. Elite teams provide a better customer experience, deploy robust code faster and maintain better availability. And engineering teams that codify their procedures and track using DORA metrics are more likely to achieve these results in a shorter time frame.

Why are DORA Metrics the Baseline for Many Developers?

Most departments have tangible objectives and key results (OKRs) to present to executives. For example, the finance department typically looks to achieve a certain revenue threshold, while the marketing department may report on social media traffic or engagement.

Software engineers have spent years grappling with how to demonstrate success to non-engineering departments. Although it’s relatively easy to identify when a deployment goes wrong, many developers have difficulty translating how these breakdowns occur. Engineering teams cannot generate buy-in for necessary process improvements or tool adoptions without the vernacular to discuss success benchmarks.

DORA metrics provide a language for developers to use when speaking with executives and other teams. Moreover, DORA metrics enable developers to understand their process’ weak points and identify areas for improvement internally.

Making the Most of DORA in 2023

It’s incredibly frustrating to fall short of development goals or hit roadblocks like post-deployment errors and bugs. DORA metrics are the secret to circumventing these challenges. Here’s how DORA can go beyond codification to help your team achieve quicker, more reliable development and deployment:

Accelerate Time to Market

Tracking DORA metrics can significantly curb a team’s time to market—a key competitive advantage in the fast-paced world of software development. Enterprises that deploy more quickly and frequently accrue greater revenue over time than less efficient enterprises.

A streamlined deployment process looks different from organization to organization. That is why DORA metrics are essential; they pinpoint each organization’s specific areas of improvement, enabling DevOps leaders to make informed decisions about remediation. Common indicators for lagging time to market include non-orchestrated deployment processes and manual testing procedures, which distract developers from what they do best: coding.

Leaders looking to isolate issues with time to market should scrutinize their organization’s deployment frequency, as this metric can indicate process inefficiencies. Deploying irregularly? Your team may be batching too many updates, leading to overloaded, riskier deployments. Alternatively, infrequent updates may mean your organization has outgrown manual deployments. If that’s the case, consider adopting continuous integration and deployment (CI/CD) processes—these offerings improve time-to-market through immediate feedback and automated testing. Successful CI/CD implementations are proven to increase daily deployments by over 1000%.

Improve Development Processes

Although highly interconnected, deployment and development delays stem from different issues. Think of it this way: Low-performing engineering teams might deploy frequently—several times a day, even—but without quality assurance, those deployments are likely erroneous and may lead to extended system downtime.

DORA metrics are a powerful way to isolate deployment issues from gaps in the development process. For example, an engineering team that tracks DORA may find their deployment frequency optimal, but their time to restore service and change failure rate lagging. This discrepancy indicates the team needs to improve its testing practices by rigorously reviewing code and managing application dependencies better. Additionally, the team should consider implementing more advantageous deployment and rollback processes, including but not limited to progressive deployments and automated rollbacks.

Remove Menial Tasks From the Workload

Some organizations approach DORA metrics and other OKRs as productivity benchmarks that can be wielded against individual engineers. This perspective has even tinged how many developers view DORA metrics. Yet Google research demonstrates DORA metrics are most successful when adopted by high-trust, low-blame cultures. In these enterprises, DORA metrics reveal organizational opportunities for improvement—never should they reveal lagging individual performers or provide reasons for unnecessary busy work.

In fact, DORA metrics often eradicate rote tasks from developers’ workloads. Teams that use these metrics to identify and implement better incident management processes spend less time fighting fires (e.g., reworking code after a costly manual rollback) and more time doing higher-value work, like building new experiences. Automated processes like automated rollbacks and CI/CD empower developers to improve the quality of individual deployments while also reducing stress

Make DORA Work for Your Engineering Team

DORA metrics aren’t going anywhere soon. While they continue to evolve, like the recent removal of the elite category, they remain the industry standard for engineering OKRs, they provide a robust framework for success and a common language for developers and non-engineering stakeholders to communicate about performance, challenges and improvements in the software development process. DORA eases the collaboration and decision-making processes, creating an environment where leaders can consistently and effectively make data-driven improvements.

But these improvements are only possible when engineers are empowered by beneficial processes and tools. I encourage leaders who implement DORA metrics into their benchmarking to take results seriously. Is your organization’s time to market lagging? Interrogate your current developer workflow—and actively take steps to address issues through developer-first solutions. Doing so will not only improve your organization’s software delivery capabilities but also foster a culture of continuous learning and improvement.

October 10, 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
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
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