devopsy.kinsta.cloud

Tag: performance

  • Arm Extends Processor Architecture to Transform IT

    Arm Extends Processor Architecture to Transform IT

    Arm today extended its processor portfolio to add two offerings that increase the performance-per-socket provided by 50% and performance-per-watt provided by 20%, respectively.

    Part of the Arm Neoverse Compute Subsystems (CSS) family of processors, these third generation Neoverse IP processors include an Arm Neoverse CSS V3 design to improve performance and Arm Neoverse CSS N3 design to improve energy consumption. Arm, for example, envisions the first instances of the N3 being used in networking and data processing units (DPUs) that require thermal design power measurement of as low as 40 watts.

    Dermot O’Driscoll, vice president of product solutions for the Infrastructure Line of Business at Arm, said Arm is already working with partners to manufacture these next-generation processors that will find their way onto system-on-chip (SOC) subsystems. Arm assumes responsibility for configuring, optimizing and validating a complete compute subsystem for key use cases on behalf of its partners, he noted.

    As part of that effort, Arm is continuing to work with partners to provide early access to SoCs to enable their software development teams to construct applications using simulation and emulation tools as next-generation platforms are being developed and deployed, he added.

    That approach helps ensure that software that is optimized for these processors is available at the time when SoCs become available, noted O’Driscoll. Variations of those Arm processors now routinely show up everywhere from the network edge to cloud computing environments to provide IT teams with an alternative to x86 processors that, so far, are not able to match the price/performance of Arm processors that are also more energy efficient.

    DevOps teams are under more pressure than ever to improve application performance without increasing the overall carbon footprint of their IT environments. Achieving those goals will require everything from more energy-efficient processors to modernized software that makes optimal use of IT infrastructure resources, especially as more inference engines are deployed to run artificial intelligence (AI) models, noted O’Driscoll.

    The challenge right now is many DevOps teams lack the tools needed to track overall energy consumption within the context of their application environment, but as DevOps continues to evolve, it will only be a matter of time before energy consumption metrics become a standard element of an observability platform being relied on to optimize DevOps workflows.

    In the meantime, as IT infrastructure environments continue to evolve, IT teams should expect to be deploying applications on a wide range of Arm, X86, graphical processor units (GPUs) and other classes of processors designed to optimize specific types of workflows. At the same time, Arm is advancing the development of “chiplets” that are optimized to run specific types of workloads within a larger SoC rather than deploying different platforms to run a specific class of processors.

    It may take a while for IT teams to wrap their arms around all the different processor options that are now at their disposal, but as the number of processor architectures being used continues to expand, the need for DevOps expertise will continue to increase.

  • How to Build a Data Platform for Self-Service, Ad-Hoc Analytics

    How to Build a Data Platform for Self-Service, Ad-Hoc Analytics

    In a digital world, data is often the differentiator between success and failure. Whether it’s defending against cybersecurity threats, improving application performance, or resolving full-blown outages, data is critical to the modern DevOps team.

    In fact, there are plenty of situations where DevOps engineers, SRE teams and other observability-focused departments need to explore reams of data rapidly and flexibly. An SRE trying to figure out the root cause of latency may need to dissect the movement of data across endpoints to find the malfunctioning one. Another engineer may need to compare historical and current performance to find anomalous behavior. Lastly, a DevOps engineer may have to dissect user performance metrics to understand the scope of a slowdown—whether it is global or regional.

    Every use case requires dashboards that can provide detailed data through a wide variety of visualizations, including choropleth maps, stack areas, pie charts and bar graphs. Ideally, a dashboard will enable teams to isolate dimensions, apply filters, and dive into data for deeper insights.

    Unfortunately, not all dashboards can support this type of fast, flexible analysis. Many still utilize outdated technologies, which lack the flexibility, agility and scalability required to seamlessly explore data. Many were also designed without the urgency that today’s data requires—after all, in previous years, most uses for dashboards (such as internal reporting) were not time-sensitive.

    Other dashboards are constrained by templates, which offer a finite array of widgets, tools and drill-down capabilities. These dashboards may feel unwieldy and sluggish, unsuited for a rapidly evolving situation like an application outage.

    Requirements

    To truly fulfill the promise of self-service, ad-hoc analytics across huge datasets, teams need to work in real-time—and so they need a database capable of timely responses.

    When an application goes down, an SRE may not know what to look for and, hence, needs to quickly comb through lots of data. While some dashboards rely on workarounds for faster queries, such as pre-aggregations, precomputing, or rollups, this is not possible in this instance because the SRE simply won’t know what to look for. After all, they can’t necessarily predict what will go wrong, and even if they work on assumptions from previous failures, this current issue could be much different.

    Therefore, dashboards must provide plenty of functionalities and visualizations. Users should be able to filter data by time, isolate variables like location, and zoom into specific time intervals with a few clicks. Dashboards should also accommodate diverse data types, including intricate parent-child relationships and nested columns.

    Further, dashboards must offer a depth of insight. An online streaming media platform may need to assess user metrics (such as latency or load times) across different devices, operating systems, and regions to fine-tune performance. A cloud provider has to monitor their physical hardware for high temperatures, slowed network switches or devices, and other anomalies.

    Because data is now so important to success, many more people across a company, including data scientists, product managers and external users, themselves require data-driven insights. In these situations, dashboards must handle the increased user traffic and query activity, maintaining fast responses even under load. This is especially important considering that a single-user operation (such as a zoom) will require multiple queries on the backend to execute.

    A database also must scale seamlessly. If an organization’s environment generates millions of events an hour, that equates to billions of events per day or week—challenging for any database to ingest, store, analyze and query. In fact, many databases cannot successfully provide fast response times while managing large datasets and high query volume. As an example, transactional databases (OLTP) can often query rapidly but cannot execute analytics at scale, while analytical databases (OLAP) can analyze massive volumes of data but not at speed.

    Apache Druid for Independent, Ad-hoc Data Exploration

    This is where open source Apache Druid comes in. Combining the scale and advanced analytics of an OLAP database with the speed of an OLTP database, Druid offers swift, real-time data exploration.

    Upon ingesting data, Druid makes it immediately available for querying and analysis, removing the need to first batch or aggregate the data in some way. In addition, Druid natively integrates with streaming technologies like Apache Kafka and Amazon Kinesis, removing the need for workarounds or connectors.

    Druid powers interactive visualizations, providing millisecond response times, enabling more versatile exploration, expanding the range of available dimensions and filters, and even maintaining subsecond speeds in the face of surging user and query volumes.

    Druid’s unique architecture also enables easy scaling. By separating key duties among separate node types—data nodes for storage, master nodes for data ingestion and availability, and query nodes for executing queries and returning results via the scatter/gather method—Druid ensures that nodes can be independently scaled based on need. Afterward, Druid also automatically rebalances traffic to ensure consistent performance.

    Salesforce: A Druid Success Story

    Salesforce pioneered the customer relationship management (CRM) space, serves 150,000 customers worldwide and earns billions in annual revenue. 

    The Edge Intelligence Team is the division of Salesforce that tackles the massive task of ingesting, processing, filtering, aggregating, and querying the entirety of their log data — anywhere from billions to trillions of lines daily. Each minute, Salesforce ingests 200 million metrics, while each day, Salesforce processes five billion daily events globally. In total, Salesforce accumulates dozens of petabytes of data in their transactional store, five petabytes of logs in their data centers, and almost 200 petabytes in their Hadoop storage.

    Salesforce teams use Druid to unlock real-time insights into product performance and user experiences, diving into large datasets instantly. Anyone from engineers to account executives can query a wide variety of dimensions, filters and aggregations to better understand trends, troubleshoot any issues that arise and set strategies for the future.

    By using Druid’s compaction abilities, Salesforce also decreased the number of Druid rows by 82%, leading to an overall reduction of their storage footprint by 47% and accelerating their query response times by 30%.

  • Consider Performance, Growth & Budget When Buying Data Analytics

    Consider Performance, Growth & Budget When Buying Data Analytics

    So, your business needs to invest in data analytics technology to improve efficiencies, competitive advantage or business outcomes. There are a ton of things to consider, but underlying each decision are three driving factors:

    • Performance – The need to meet service level agreements.
    • Growth – The need to accommodate success, as well as deal with inevitable industry changes.
    • Budget – The need to do both of the above while keeping costs low enough to not erode the profit gain from analytics.

    These three forces underpin nearly every technology selection decision, but what frequently isn’t noticed is how much these three drivers interact.

    1. Concurrency and Growth

    Test both for current levels of concurrency and the level you hope to achieve in the next few years as the organization grows.

    When evaluating benchmarks between vendors, consider that benchmarks are designed to make that company’s software look good. For example, if they are good at concurrency, you will see various levels of concurrency represented in the benchmark. If the benchmark shows only one workload at a time, or maybe ten, you can safely assume that concurrency is probably not something that technology is good at. Similarly, if the benchmark is done at 10 TB scale, the vendor probably isn’t that good at high-scale analytics.

    When bringing vendors in for a proof-of-concept, one mistake I’ve seen (more times than I can count) is testing the capabilities of the software with only one user at a time. People do not line up politely to use analytics one at a time.

    In addition to current levels of concurrency, over time, hopefully, the organization will grow, and the number of both internal analytics users and external customers will increase. Testing for the number of users you have now may not uncover problems that will invariably reveal themselves when a lot of people hit the system at once. The last thing your organization needs is to turn away customers because they’re overloading your systems.

    2. Performance & Price

    Evaluate price/performance, not performance alone.

    Everyone understands the importance of performance. Not one user has ever gone to a data architect or engineer and requested for their analytics to “please execute more slowly.” But performance isn’t simply how fast the analytical software can process queries, how fast the data pipelines can move data or how fast the response is between data input and reaction output. There’s also a monetary aspect of performance to bear in mind.

    In a recent benchmark, three data management and analytics stacks were compared with 60 simulated concurrent users/workloads. The difference in queries per hour on 250 TB of data was minor, perhaps 16 queries per hour for the slowest and 23 queries per hour for the fastest.

    (Mcknight Benchmark – SaaS Data Analytics Platform Comparison – vendor names removed)

    It looks like performance is just not that big a consideration for this technology. But there is no such thing as an unlimited budget. Let’s look at how much it would cost to get this level of performance out of each stack.

    (Mcknight Benchmark – SaaS Data Analytics Platform Comparison – vendor names removed)

    Price-performance is a far more useful metric of value to the organization. How much the software can do is irrelevant if the budget limits how much the business can afford to do with it.

    3. Software Efficiency

    Consider how much efficiency and control you’re willing to trade for ease-of-use.

    When you analyze data in the cloud, you’re not just paying for software, you’re also paying for hardware, a.k.a. cloud compute instances. Bundling the two costs in one bill makes things easier. But it also means that cloud providers make more money the more instances, or compute nodes, you use. You trade ease-of-use in billing for a higher price. And they no longer have a financial incentive to provide efficient software.

    Similarly, to make a cloud-based analytics software scale up in performance and concurrency with zero effort on your part, the software has to use only defaults for all settings internally. It can scale only by throwing more compute at the problem; compute that you’re paying for every time you use it. You’re trading control of the software–tuning, scaling guidelines, shut down conditions, etc.–for ease-of-use, again for a higher price.

    Throwing more compute at a problem isn’t always the best solution. Recently, I saw a POC where the customer implementation included 278 EC2 nodes on Amazon cloud. The organization didn’t initiate the POC because of inefficiency. They were having performance problems, even with that much compute power. A competing product was able to run on only nine EC2 nodes with the same workload and better performance. The company was paying 25 times as much for the compute hardware because it was convenient.

    Be aware of the tradeoffs.

    4. Affordable Scalability

    Paying for only what you use can become impractical when you use more and more.

    The volume of data that is being created, consumed and captured is growing exponentially. By 2025, it is estimated that nearly 30% of data being generated will be real-time. Instead of pulling data in batches, data will be pulled in continuously. Queries will be responded to in seconds, not hours, or in milliseconds, not seconds.

    Going to the cloud can make tremendous sense when a company or a workload in that company is new. But studies show that as businesses scale and growth slows, the pressure the cloud puts on business margins eventually outweighs its benefits. This is why most enterprises today are considering repatriating some or all of their workloads off the cloud.

    5. Flexibility for Change

    Make certain your stack will continue to work even as conditions change, and you won’t have to rebuild from scratch to do the same thing in a different location.

    When you’re building a long-term architectural strategy, you want to ensure you cover as many bases as possible because, the fact is, you really don’t know what the future holds. Ten years ago, maybe you had a Hadoop on-premises strategy or a data warehouse appliance. Today, you may have a cloud-focused strategy. Tomorrow, maybe you’ll move some or all of those workloads back on-premises due to performance, security, costs, regulations or other reasons.

    This is why you want flexibility that doesn’t mandate a “cloud-only” or an “on-premises-only” or a “this-cloud-only” architecture and which doesn’t integrate with only the same vendors’ software. You want an architecture that can work equally well both on the cloud as well as on-premises, hybrid or multi-cloud, providing the flexibility of going where business needs are best met.

    Containerization offers possibly the highest level of flexibility in deployment, but it can also add to deployment complexity, so again, be aware of what you’re trading. If the software you choose is platform-agnostic—not tied to any particular location, ecosystem or deployment model—then that will make future choices a lot more flexible.

    Regardless of what analytics you choose, what you decide to build or what use cases you have to meet, striving for balance in performance, growth and budget will create a strong data architecture, now and for the future:

      1. The analytics architecture is high-performance: it should meet SLAs, get things done on time and meet or exceed expectations and requirements.
      2. The analytics architecture is resilient to growth and change; even if there is rapid growth or sudden or extreme changes, it’s future-ready.
      3. The analytics architecture should control costs and live within an allocated budget.

    Keep these guidelines in mind when choosing an analytics provider. The decisions you make today will have direct ramifications on the growth, profitability and success of the business tomorrow.

  • The Power of Observability: Performance and Reliability

    The Power of Observability: Performance and Reliability

    Observability has become an essential aspect of modern IT, and its importance is only expected to increase in the years to come. The ability to monitor and understand the behavior of systems in real-time provides organizations with a wealth of information that can help them improve the performance, reliability, and overall health of their networks and applications.

    By collecting and analyzing data from a variety of sources, observability enables organizations to proactively address issues before they escalate into major problems. This proactive approach to problem-solving can help businesses avoid costly downtime and lost productivity, ultimately leading to increased customer satisfaction and business growth.

    Current Challenges Facing Today’s Organizations

    Despite its many benefits, achieving proper observability can be challenging, particularly in today’s complex and highly dispersed technology landscape. The sheer volume of data generated by siloed networks and applications can overwhelm even the most sophisticated monitoring tools. However, with the right approach, tools and processes, organizations can overcome these challenges and fully realize the potential that observability has to offer.

    One of the biggest obstacles to achieving comprehensive network observability is the fragmentation of data sources. Logs, metrics, events and other types of data all require different tools to collect and store them, making it difficult to get a complete picture of network performance. To overcome this challenge, organizations must adopt a holistic approach that integrates the right tools and processes to collect and analyze all relevant data.

    This holistic approach involves the use of advanced monitoring tools that can collect and analyze data from multiple sources, as well as the implementation of best practices for data management and analysis. By taking a comprehensive approach to observability, organizations can gain a deeper understanding of their networks and applications, identify potential issues before they become major problems, and ultimately drive business growth and success.

    Best Practices for Performance and Reliability

    First, proper tooling is crucial for organizations to perform a comprehensive analysis of data. This enables cross-domain correlation to achieve meaningful insights. A data-centric approach relying on contextual information can help organizations “connect the dots” and make informed decisions. In addition, organizations must also prioritize data quality to ensure that they are analyzing accurate and reliable data. Poor data quality can lead to incorrect conclusions and poor decision-making, which can have negative impacts on network performance and business outcomes. To ensure data quality, organizations must invest in proper tooling and processes that can validate and verify data accuracy, consistency and completeness.

    Second, having a network data source of truth is crucial for organizations to effectively analyze and make informed decisions based on their data. The ability to extract metadata from existing sources to provide contextual information is also vital to “connecting the dots” across multiple domains to uncover valuable insights. The metadata serves as the ultimate enabler in this process, allowing organizations to gain a comprehensive understanding of their data to make informed decisions. By establishing a network data source of truth and extracting the necessary metadata, organizations can effectively analyze and use their data for more meaningful insights.

    Third, it is important to ensure that observability is incorporated into the entire development lifecycle to support end-to-end visibility. This means accounting for instrumentation as part of the design and planning phases, as well as testing, deployment and ongoing maintenance. By making observability a central part of the development process, organizations can identify and resolve issues before they become major problems. Additionally, incorporating observability into the development lifecycle can also improve the overall performance of the system by identifying bottlenecks and areas for optimization. It can also help to improve the overall security of the system by detecting anomalous behavior and potential vulnerabilities. Moreover, having observability throughout the development process can enable teams to make informed decisions based on real-time data and analytics, leading to more efficient and effective development practices.

    The fourth best practice is to use a centralized observability platform that allows for the collection and analysis of data from all systems and infrastructure. This platform should be able to collect data from all parts of the organization’s technology stack, including databases, servers and applications. Additionally, the platform should be able to correlate data from multiple sources to provide a comprehensive view of the organization’s operations. This centralized approach ensures that all stakeholders have access to the same information, reducing the likelihood of miscommunications and ensuring that everyone is working towards the same goals.

    Last is the democratization of data. This is crucial for organizations as it empowers teams from multiple functions to access and use data effectively. This leads to increased transparency and collaboration, allowing organizations to make data-driven decisions and drive innovation. Democratization also helps to break down silos, increase visibility and facilitate faster problem-solving for improved decision-making. The key to achieving comprehensive network observability is collaboration between teams. Siloed teams and processes can lead to gaps in data collection and analysis, as well as delays in issue resolution. Therefore, organizations must encourage cross-functional collaboration between teams responsible for network infrastructure, application development and operations to promote a shared understanding of network performance and enable faster problem resolution.

    Observability is a Key Discipline

    In conclusion, observability is a key discipline that can help organizations achieve superior performance and reliability in their systems. By following the best practices suggested above and embracing a comprehensive approach, organizations can overcome the challenges of data fragmentation and unlock the full potential of observability. As technology continues to evolve and become more complex, observability will only become more important, making it essential for businesses to prioritize this aspect of their IT strategy.

  • Linux Tweak Brings Big Speedup ¦ DCs in SPAAACE (Redux) ¦ Atlassian Fires 500

    Linux Tweak Brings Big Speedup ¦ DCs in SPAAACE (Redux) ¦ Atlassian Fires 500

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

    This week: Intel optimizes Linux multithreaded networking, data centers in space (again), and more DevOps toolmaker layoffs. (more…)

  • Dependability is Crucial for Real-Time Experiences

    Dependability is Crucial for Real-Time Experiences

    Millions of people around the world experienced a major disruption after an October 2021 outage saw Facebook, WhatsApp and Instagram go offline. A few days prior, the popular workplace collaboration platform, Slack, also went down for some users. And in the last few weeks of 2021, Amazon’s AWS caused considerable global chaos after significant networking issues in its busiest data center, US East 1, disrupting streaming services such as Disney+ and Netflix.

    Downtime can be costly, causing organizations to lose $5,600 per minute and up to $300,000 per hour, on average, according to Gartner. But it’s not only financial and reputational loss that businesses need to worry about. Outages also seriously downgrade—and in the case of real-time experiences, completely disrupt—the customer experience.

    At a time when consumers are demanding more live and interactive digital experiences, organizations can ill afford disruption or downtime, as customers quickly move to other services that ‘just work’.

    It’s not just the capacity within a real-time system that matters, but also globally distributed failover capabilities when something does go wrong. While organizations could try to build their own failover mechanisms, it’s extremely difficult to failover so services continue seamlessly, regardless of the status of its underlying infrastructure. Simple failover systems not only take longer to resume but typically suffer data loss during the time that a region is disrupted. Businesses need to know that even if, say, AWS suffers an outage, they won’t be affected.

    This is why it’s vital that organizations get it right when looking to develop their own real-time infrastructure. Managing tens of thousands if not hundreds of thousands of concurrent connections while synchronizing data in real-time means that if anything does go wrong it’s immediately obvious to users. If tech behemoths like Amazon and Facebook can’t get it right, what chance do organizations with far fewer resources have when building and managing their own real-time infrastructure?

    The Steps to Success With Real-Time Infrastructure

    Regardless of whether it’s for synchronized multi-user collaboration, audience engagement or instant updates, developers have a hard enough time developing even the most basic of real-time infrastructure, let alone making sure it’s dependable. There are four key elements to achieve dependability: Predictable performance, data integrity, reliability of service and high scalability.

    • Predictable performance: When we think of performance we usually imagine more computing power or speed. But when it comes to real-time, it’s not just about minimizing latency and bandwidth, it’s about having a predictable system. If developers have global latencies and bandwidth within certain operating boundaries, it provides certainty in uncertain operating conditions. This makes it easier to design, build and scale features around this certainty.
    • Data integrity: As we all know, the internet can be an unreliable network. Users abruptly disconnect and reconnect all the time, resulting in data that gets lost, is delivered in the wrong sequence or that is sent multiple times. As a result, organizations must ensure their infrastructure can guarantee high integrity without sacrificing anything else.
    • Reliability of service: The live nature of delivering updates in real-time requires total reliability. Outages can cause distrust and annoyance from users. Organizations could find their reputation taking a hit or customers quickly jumping ship if reliability proves to be a recurring issue. To prevent this, organizations should develop infrastructure that’s fault-tolerant and redundant at both a global and regional level so they can deliver a great experience even if there are multiple failures.
    • High scalability: More often than not, delivering an experience in real-time can result in unpredictable traffic; for example, a huge number of people wanting sports updates for a World Cup game. If thousands of devices connect over a short period of time but capacity can’t scale up quickly enough, then an outage will occur. To avoid this, developers must use infrastructure that can be elastic and meet changing levels of demand. Otherwise, the user experience is seriously affected and real-time capabilities crash when the network is swamped with connections it can’t cope with.

    While organizations often build their own infrastructure with the best of intentions, it’s easy for them to run into trouble. Most lack the internal expertise, resources and time; plus, going it alone often results in a huge technical debt. It’s also a massive undertaking, due to the amount of ongoing complexity and cost involved.

    Third-Party Partnerships Enable Dependability

    Unless organizations have the resources, finances and expertise of the likes of Amazon or Google, then building your own real-time infrastructure is just setting yourself up for failure. Instead, they should save on development cycles and focus on generating revenue more quickly by offloading their real-time infrastructure needs to a third party. This will mean organizations can design without limitations and focus on solving the challenges that really matter to them while putting in place real-time infrastructure that is as dependable and future-proof as possible.