Posted on

Containerized 5G Infrastructure Visibility

Cloud native and containerized architectures are becoming the de facto design standard for 5G networks and applications. In the telecommunications industry, the players are focused on building out 5G Stand Alone (SA) deployments to deliver the promise of faster connection speeds to enable IoT, medical, and autonomous use cases – not to mention improved communications, support for streaming real-time content, and the promise of myriad new applications and services. In working with Tier 1 operators, MVNOs, and analytics providers, we are encountering a staggering issue: they can no longer adequately monitor, correlate, and measure critical network and application communication events at the container level and across the infrastructure.

As we have illustrated through our demonstrations and proof of concept deployments of our Containerized Visibility Fabric (CVF) with telco and related technology suppliers, the most common phrases we’re hearing during the engagements are:

Posted on

Gain Better Visibility Into Kubernetes Cost Allocation

The Complexity of Measuring Kubernetes Costs

Adopting Kubernetes and service-based architecture can benefit organizations – teams move faster, and applications scale more easily. However, visibility into cloud costs is made more complicated with this transition. This is because applications and their resource needs are often dynamic, and teams share core resources without transparent prices attached to workloads. Additionally, organizations that realize the full benefit of Kubernetes often run resources on disparate machine types and even multiple cloud providers.

In this blog post, we’ll look at best practices and different approaches for implementing cost monitoring in your organization for a shrowback/chargeback program and how to empower users to act on this information. We’ll also look at Kubecost, which provides an open-source approach for ensuring consistent and accurate visibility across all Kubernetes workloads.

Posted on

Inclusively Hidden

Scott O'Hara recently published "Inclusively Hidden," a nice walkthrough of the different ways to hide things on the web. Nothing is ever cut and dry when it comes to the web! What complicates this is that hidden begs the question: hidden for whom? Different answers to that have different solutions:

  • Hidden for everyone? display: none; or visibility: hidden; or the hidden attribute. (But watch out for that hidden attribute, says Monica Dinculescu.)
  • Hidden visually, but present for assistive tech? A .screen-reader-only class with a smattering of properties to do the job correctly.
  • Hidden for assistive tech, but not visually? The aria-hidden="true" attribute/value.

It's worth grokking all this because it's is a perfect example of why HTML and CSS is not some easy bolt-on skill for front-end web development. This is critical stuff that isn't done as correctly as it should be.

If you like video, I did one called "Hiding Things with CSS" that goes over a lot of this.

As I write this, I'm freshly back from Smashing Conf in San Francisco. Sara Soueidan had a wonderful talk that covered some "hiding things" situations that are even less intuitive than what we might be accustomed to seeing.

One thing she covered was the inert attribute and how it can be used to skip interactive elements from keyboard tabbing. It can even be used on a parent element, nullifying everything inside it. I understood that part, but not entirely why it's useful since it seems like you might as well use display: none; if an element is hidden and the elements inside aren't meant to be in focus. But I'm sure it's my lack of understanding, so I'm looking forward to Sara's video to come out so I can re-watch it. It had to do with maintaining a non-awkward tabbing order.

Another thing Sara covered is that some folks who use assistive technology also tend to explore touch screens with haptics, moving about the page with their fingers looking for interactive elements. If you, say, replace a native checkbox with a styled checkbox, it's possible to do that in a way thats mostly accessible by using a real checkbox that you hide and replace with a graphic, but Sara demoed how you can resize the checkbox over the top of the replacement and hide visually with opacity: 0; — that ensures someone can still find the element by touch. That doesn't seem to be the default way this kind of thing is taught or built, so it's great to see Sara calling it out. Yet another example of HTML and CSS being nuanced and tricky languages.

Direct Link to Article — Permalink

The post Inclusively Hidden appeared first on CSS-Tricks.

Posted on

Four Ways to Improve DevOps Visibility

Overview

DevOps, by design, works quickly and accomplishes deadline-driven projects rapidly. With this high amount of project turnover, visibility into key operational data is easy to mismanage and can lead to simple mistakes, lack of optimization, and organizational misalignment. To examine the effect of DevOps Visibility, SmartDraw commissioned the 2019 DevOps Visibility Report. The results were decisive: each company surveyed is seeking ways to better DevOps visibility, and 84% of respondents list it as somewhat to extremely important to their organization. But achieving DevOps visibility is not always simple.

Roadblocks to Achieving DevOps Visibility

Respondents identified that visibility reports take skilled workers away from their other priorities. In a small, fast-moving, lean team, removing a skilled worker from a key deadline-driven task can cause performance and timeliness to suffer.

Posted on

Sharing Mutable Objects Using a Safe Accessor Service

On page 54 in his distinguished book "Java Concurrency In Practice," Brian Goetz describes how objects can be safely shared across threads. He lists four options:

  • The object is thread-confined, meaning updates to the object are performed by only one owning thread
  • The object is shared read-only, meaning this object only needs one-time publication
  • The object is inherently thread-safe, meaning it performs synchronization internally
  • The object is guarded by some lock

In this post, I will describe a variant that falls into the fourth category. The objects shared are not thread-confined, not read-only, and aren't synchronized internally. I am going to use a read-write lock to guard the object's state. As the presented technique is highly concurrent, it will not require synchronized blocks and gauruntees that no needless thread contention will slow down application performance. Without using synchronized, it is still garanteed that any change will be visible across all threads that share the object instances; this is achieved by applying certain rules to the shared objects' mutable state.

Posted on

Stripe’s Will Larson on Designing a Performance Management System from Scratch

"In Engineering, we tend to hold this idea that these people systems —career ladders, performance reviews, calibration — are these evil things that aren't very valuable. They're thought of as bureaucracy. But it's a shame. These are really powerful systems, and I'm actually excited to personally spend a lot of time with them."

Will Larson, who was previously an engineering leader at Digg and then Uber, now leads Foundation Engineering at Stripe. His organization partners with Infrastructure, Data, and Developer Productivity teams to build the tools that support every Stripe engineer and keep Stripe reliable and performant.

You can go about building a performance management system in uncountable ways, but Larson points out that most of them are comprised of three core elements: career ladders, performance designations, and performance cycles. These combined systems focus your team's efforts on the activities and metrics that ultimately help the organization succeed, by providing direct feedback to engineers on how valuable their work is (and by measuring it against expectations).