devopsy.kinsta.cloud

Category: Features

So Many Options, So Little Time

So many language/framework options, so little testing time, that is.

Recently, two projects I was working on drove me to check out a breadth of languages and/or frameworks to handle cross-platform development. While Unity and Unreal have traditionally been my game platforms of choice and I typically use Xamarin for cross-platform (though native development is more common for us on both Apple and Android), I decided I needed to do the occasional sweep to find out what is new out there.

The two projects are a game on which I’m helping a new game developer learn and a graphics-heavy application that is unsuited to web development. Both would work best in a cross-platform environment; both would benefit from a game engine’s graphics manipulations. But both could be done in any language that supports graphics, as there isn’t a heavy physics requirement to the game.

So I went looking at what’s available now and how it fits. From React Native to Godot to Flutter and even Kivy, I kicked the tires on each, got them running, ran and traced samples, wrote some code of my own, even talked with friends that were using them to get their opinion.

The one thing that came through loud and clear? There is no way that security and testing are keeping up with this language/framework proliferation. Kivy has a language (more of a specification than an actual language, but still—source code) that can run on top of Python (it’s not required to use the framework, but it’s kind of assumed you will if the app gets beyond a certain size); Godot has a language that is integral to the framework and that you use pretty much everywhere. React has a ton of add-on code and both Flutter and Dart are new languages.

I like stuff from each of them. I don’t like that we’re going to use them in ever-increasing amounts and we’re going to expect testing to stay on top of those implementations. Each of these platforms/languages/environments has a large following that is doing some of the testing, but since they’re all relatively new, “How much testing?” is a valid question. And tests have to be done in those languages, implying that those writing need to know them and so do testing teams.

Where did we end up? We haven’t made a final decision yet, but taking input from the person I’m mentoring, coworkers and those who are using each of the above, we’ll probably end up using Godot. For 2D apps, it is the bomb. Our team is small, so I can offer my knowledge of Godot to shore up testing and everyone agrees that its Python-like language is acceptable, while the graphic design element is nicer than the competition. Both applications will benefit from Godot’s graphics processing capabilities and the game will benefit from game elements built into the Godot Engine.

Here is an interesting side note: All of the products we looked at are open source. Both of the default products that we (and just about everyone else) would choose for the game are commercial. That’s interesting, but we don’t need the weight of those commercial solutions for a simple 2D interactive game/app.

For you all, the questions might be harder to answer. With larger projects come larger requirements for source size, test, you name it. Choose carefully, with an eye on the future. Personally, I think React Native, Godot and Flutter would all be good choices for cross-platform applications, with Godot the best solution for cross-platform 2D games. And all three are likely to be around with a good size following for a long time, making them safer choices. That is less clear with Kivy, though the popularity of Python appears to be driving growth in Kivy use.

Whatever you choose, plan for all phases of development, not just writing code. That’s true of everything, but new cross-platform tools are complex beasts, so it is worth reminding you all.

And hey, if you have a cool app you developed with one of these tools, point me to it. Always good to see what you all are doing, and nice to see the breadth of solutions these languages can create.

August 25, 2021
Majority of Software Engineers Want Remote Work Options

The pandemic brought unprecedented change to the digital ecosystem, impacting users, companies and software engineers alike. COVID-19 accelerated ongoing digital transformation and forced many organizations to innovate rapidly. Newfound reliance on digital experiences increased demand for software programmers, exacerbating demand in a market already short on talent. In this era, work-from-home (WFH) became commonplace and most engineers moved toward full-time remote work positions.

Having had a taste of freedom from corporate settings, most developers now want remote work options in a post-pandemic future. A significant amount also desires to work 100% remotely. As a result, many companies have instituted permanent work-from-home policies. Yet, they are still grappling with the repercussions of a fully remote workforce. For example, there are differences of opinion about whether to adopt location-based salary adjustments and whether or not those remote workers should be granted unique employee benefits.

The 2021 State of Remote Engineering Report, conducted by Terminal, surveyed 1,100 software engineers in North America and explores how the pandemic has affected the remote developer workforce; showcasing both the positive and negative effects of remote work on engineers. Interestingly, the report exposes international talent’s declining interest in physically moving to the U.S. as domestic conditions worsen and remote work becomes more globally accessible. Below, we’ll explore the key takeaways from the study to posit how this new normal is influencing the productivity, morale and recruitment of software engineers in North America.

The New Normal: Remote Work

The new normal has dramatically shifted the status quo. Impressively, findings show that 86% of engineers are currently working 100% remotely. This is in stark contrast to the pre-pandemic numbers, which showed 19% working remotely 100% of the time. Many of these employees prefer to keep these new working arrangements and standards in place going forward. The study found that 80% of engineers surveyed want options for working from both home and the office, and one out of three want to work remotely 100% of the time.

There are many reasons why engineers prefer the flexibility of remote work to the traditional workplace. For one, there is no need to commute, thus saving time and energy. Engineers also cite an improved work-life balance and appreciate the increased autonomy. It also appears that many organizations handled the shift to remote work effectively—74% of engineers say their companies adapted well to remote work. Due to these positive results, 76% of engineers would be happy working fully remote 60% of the time or more.

Remote work not only benefits software engineers but could also bring productivity enhancements to help achieve business goals. Without workplace distractions, 70% of engineers surveyed reported they are more productive when working from home. Yet, this new normal isn’t without its drawbacks. As the traditional corporate firewall diminishes, CISOs struggle with a dilemma: striking an ideal balance between granting new IT freedom and locking down systems and restricting access to adopt a zero-trust mindset.

Issues With the Pandemic and Remote Work

Of course, there are some other drawbacks associated with full-time remote work. A lack of day-to-day interaction with coworkers is a challenge cited by 58% of participants in this study. For 39% of engineers, it’s harder to collaborate or feel part of a team in this new dynamic. Burnout or lack of motivation and home-based distractions can also be barriers for remote-working engineers. The loneliness of at-home work can take its toll; 38% say their mental health has gotten worse amid the pandemic.

Companies also face challenges recruiting within this new paradigm. The talent shortage remains a big issue for many companies trying to rapidly deliver new software; 64% of engineers say there is a software engineer shortage and 65% say this gap holds back technical development. Though there is a clear skills gap, most companies are not offering adequate benefits coverage to entice full-time workers. Of these benefits, 23% of engineers would like a home office stipend for utilities, internet and other expenses; 22% also want more flexible work hours and 11% desire new technology and productivity tools. And 26% of engineers also ranked support for mental health as one of their top three sought-after benefits.

The report also addresses some inefficiencies associated with hiring engineers for remote positions. For 59% of engineers surveyed, recruitment involves far too many interviews. Many of us working in IT can likely attest to being approached by LinkedIn scouts with irrelevant offers. As such, 40% of engineers say they are often interviewed by people who don’t understand the technology. Other recruitment issues include generic interviews and long delays, both of which could frustrate candidates. It appears companies must fix their hiring practices or risk losing potential talent.

The Era of Employee Choice

If anything, the State of Remote Engineering report drives home the imperative to consider full-time remote work as a viable option for prospective hirees. To fill engineering labor shortages, some U.S.-based companies have historically flown in international talent. Yet, the desire to move to work in the U.S. is declining. In fact, 39% of engineers have no interest in moving to the U.S. for a job. Engineers cite crazy politics (56%), gun violence and safety concerns (55%), racism (47%) and mishandling of the coronavirus (51%) as reasons not to move to the U.S. The idea that employees must remain in physical proximity with a company’s headquarters is changing; thus, companies will have to go where the existing talent already lives.

In addition, today, engineers have more bargaining rights than they did in the past. “The era of employee choice is here,” said Clay Kellogg, CEO, Terminal. If we’re in a seller’s market, engineers are the ones to profit. Increased bargaining rights could mean remote engineers may demand equal pay, no matter their location. The study found that, on the whole, engineers are not in favor of location-based salaries; 49% say they would only accept a location-based salary if their cost of living dropped by 20%.

In addition to offering competitive wages, teams are finding creative ways to maintain culture and avoid burnout. For example, 55% of engineers think virtual get-togethers like happy hours and social activities help stave off burnout. With all these findings in mind, companies should consider instituting a work-from-anywhere policy wherever possible and provide additional benefits and support for remote workers to attract more engineering talent.

The State of Remote Engineering surveyed over one thousand software engineers across the U.S., Canada and Latin America. For more granular details, consider viewing the full report here.

August 24, 2021
F5 Networks Planning Open Source Projects Beyond NGINX

F5 Networks today revealed plans to launch multiple projects in the months ahead that will extend its commitment to open source beyond the NGINX proxy software the company acquired in 2019.

The announcement was made during an online NGINX Sprint event; two of the projects are extensions of NGINX that will address networking requirements between microservices-based applications in addition to the management of fleets of NGINX instances. The third project is a platform-agnostic open source developer tool for building modern applications that does not necessarily require NGINX proxy software.

At the same time, F5 Networks also unveiled an open source NGINX Modern Apps Reference Architecture that gives IT teams access to a complete, fully operational microservices-based application that can be deployed in minutes on a Kubernetes cluster. Based on a modular approach made up of open source components that come pre-wired and pre-integrated, F5 Networks is committing to extending this framework in collaboration with multiple third-party vendors and organizations.

Rob Whiteley, general manager for the NGINX product group at F5 Networks, said the company is also committing to modernizing its NGINX proxy software to leapfrog rival open source Envoy proxy software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). NGINX is still more widely employed than Envoy largely because it is lighter-weight and easier to deploy, but Whiteley conceded that Envoy has more advanced capabilities.

Envoy, of course, is at the core of the Istio service mesh. F5 Networks supports both Istio as well as a service mesh it has developed on top of NGINX. Depending on the number of application programming interfaces (APIs) that an organization needs to support, an IT team might make use of proxy software, ingress controller or an API gateway for a service mesh to manage them.

Finally, F5 Networks said it will participate in the Kubernetes ingress project and that it is joining the gateway API community as its implements its own NGINX-based gateway controller to ensure its proxy software and Kubernetes remain tightly aligned in the future.

In general, Whiteley said F5 Networks also is making a commitment to be clearer about where the line between the open source and commercial editions of its offerings is drawn. As a rule, the open source editions are designed for developers and small teams while the commercial version is designed to scale within enterprise IT environments. The overall goal is to promote innovation without enabling cloud service providers to reap all the revenue benefits of F5’s research and development by creating a service based on that open source software, said Whiteley.

As part of that effort, F5 Networks is expanding the number of open source projects it supports to make it easier for developers to contribute code beyond the core NGNIX proxy software, said Whiteley.

It’s not clear to what degree F5 Networks will be able to rally the open source community to advance additional projects beyond NGINX. The company is promising to provide additional details at an unspecified future date. However, Whiteley said there is still plenty of room for innovations not only in emerging technologies such as service meshes but also proxy software that is already widely employed within many enterprise IT organizations. Especially since most of them are embracing microservices-based applications that will ultimately change every aspect of IT.

August 23, 2021
Infrastructure-as-Code Security will Improve Your Cloud Security

Moving to the cloud creates a tremendous opportunity to get security right and reduce the risk of a data breach. Most organizations start their cloud security efforts by ‘shifting security left’ thereby addressing issues in the CI/CD pipeline. Fixing known vulnerabilities and risky configurations before pushing images to production makes sense. But there is an opportunity to shift security even further left—as you set up your cloud infrastructure—to reduce risk. Infrastructure-as-code (IaC) security allows you to define security controls as you configure your cloud infrastructure.

Getting Started on Your Cloud Journey

Before we dive into IaC security, let’s talk about why platform teams want to deploy infrastructure-as-code as they move through their cloud journey. Most organizations have not yet tackled IaC. They start their journey by experimenting with cloud configurations until they have defined a stack that works for their teams. In this early stage, application teams may be defining their own cloud stacks. They are manually configuring infrastructure or using scripts. Configurations may not be standardized across teams.

Standardization of Infrastructure Saves Time

Although experimentation is reasonable early on in the journey, standardization of infrastructure saves time. Cloud services are no different than applications that run on premises. When your teams are using different versions of tools in their stack, getting an application up and running can be a nightmare. Interoperability between services is challenging, and it can feel like you are fixing a different flavor of the same problem over and over.

Mature cloud platform teams typically prefer to create a ‘golden image’ with a baseline set of services for development teams. They may create a menu of a few standard options to meet different teams’ needs. Because they are standardized, the platform team can take time to validate that they interoperate and are secure. For example, these golden images will be regularly scanned for vulnerabilities and updated to ensure they meet internal security standards and any relevant regulatory requirements.

Automating Infrastructure Deployment Reduces Errors

Manually configuring the environment in the cloud for each team is tedious. Once these configurations have been standardized, the cloud infrastructure can be provisioned as code using templates. A declarative approach defines the desired end state, whereas an imperative approach defines the detailed steps to achieve the end state. The templates are normally stored in a Git repository and version controlled. Automating the configuration of infrastructure not only saves time but also reduces errors that can disrupt operations.

IaC Security Shifts Security Further Left

Once you have templates that define your infrastructure, standardizing permissions and access rights for services-as-code is a logical next step. The security team typically defines the guardrails or policies for accessing cloud services. These policies can then be defined as code along with the infrastructure configurations. This IaC security is a further ‘shift left’, allowing security to be embedded into infrastructure, even before an application can be deployed. Implementing policy-as-code minimizes the opportunity for human error in configuring security services. By defining these policies and enforcement guidelines together, the DevOps and security teams can establish a trusted partnership.

Although some organizations may start their journey by implementing IaC security, for most organizations it happens later in the cloud journey. The order is less important than ensuring you take a DevSecOps approach and embed security at each stage to manage risk. Be sure to address the following areas as part of your cloud and container security program:

Continuously Check Cloud Permissions and Configurations

Even if you have IaC templates, you need a program to regularly take inventory of all cloud assets and confirm permissions and configurations. The Center for Internet Security (CIS) benchmarks are commonly used to check passwords and access rights. Beyond enforcing these best practices for security on cloud services, continuously checking for changes to permissions and suspicious activity is critical. The cloud vendors capture logs across all of their services, and your security tool should continually monitor and alert using those logs.

Scan Images for Vulnerabilities and Risky Configurations

Scanning for vulnerabilities and ensuring configurations use best practices allows you to shift security left into the development pipeline. Scan everywhere you have images—including within registries, pipelines and also check for new vulnerabilities identified for images running in production. Be sure to scan hosts as well as containers. Defining scanning policies and enforcing through the development process creates guardrails for the development team and clarifies expectations. Most regulatory compliance standards have image scanning requirements as well.

Detect Threats and Respond to Alerts

Prevention is fundamental but must be supplemented with threat detection and response. Alerting on unexpected behavior can identify the presence of a threat. Initially, teams may use out-of-the-box detection rules as a way to get started and then customize rules over time. Checking configs against dockerfile best practices is a good way to get started. Overly permissive access rights for containers is common in Kubernetes environments and should be allowed only when required.

As your team develops more expertise with containers and Kubernetes, you can also implement zero-trust network security policies to block unexpected communication between pods, services and applications.

Some DevOps teams handle triage of alerts, as they can quickly determine if the issue is a configuration issue or an indicator of compromise. Teams often map detection rules to the MITRE ATT&CK framework, allowing their security teams to manage alerts consistently across their environment. For any team to effectively respond to a security alert, it is important to capture a detailed record of exactly what happened before, during and after that event. This visibility can be particularly challenging with containers but it is critical because containers have short lives. The 2021 Sysdig Container Security and Usage Report revealed that about half of containers live less than five minutes.

Complying with Regulatory Standards

Complying with regulatory standards can be painful. Some standards were written with cloud computing in mind, like NIST 800-53 and SOC2, and others were not. With those broader standards, it is important to understand the controls that are relevant to containers and the cloud.

As you consider your compliance program, be proactive—don’t wait until you are ready to roll into production. Start early by engaging your compliance team and helping them get up to speed. Your role is to provide evidence of compliance to pass an audit at any time using the documentation from your security platform.

Getting Cloud and Container Security Right

The move to the cloud creates a tremendous opportunity to get security right and reduce risk. The fact that physical security and a chunk of operations are delegated to cloud vendors frees up security and development teams to focus on their more narrow scope within the shared security model. By taking a secure DevOps approach and inserting security into every stage of the application life cycle, your team can confidently and securely run cloud and containers.

August 23, 2021
Kentik Open Sources Five Projects to Advance Network Observability

Kentik today unfurled a developer hub, dubbed Kentik Labs, through which it is making five open source projects available as part of an effort to advance observability across network operations (NetOps).

The five projects are:

kTranslate: A system for pulling and pushing network data that is the basis of the Kentik Firehose integration the company created for the New Relic observability platform

NetDiag: Scalable, asynchronous implementations of low-level network diagnostics

Convis: Example code showing how to attribute process and container information to network traffic via the Linux kernel using eBPF

kProbe: A high-performance host and sensor network probe (PCAP)

Grafana App: A real-time tool for ingesting and querying network data

Nick Stinemates, vice president of business development at Kentik and co-chair of Kentik Labs, said the goal is to enable DevOps teams to incorporate NetOps within the workflows already being employed to programmatically manage the rest of IT.

Stinemates noted that, as IT environments become more distributed, managing NetOps has become more challenging. If there is a failure, it can be difficult for DevOps teams to determine if the issue is due to application code, the underlying infrastructure or some other root cause. Kentik Labs is committed to providing tools that will help DevOps teams reduce their mean time to recovery (MTTR), he added.

Most NetOps teams increasingly rely on software to manage distributed networks either in the form of graphical tools provided by router and switch vendors or by using the Python programming language and the open source Ansible automation framework that enables IT teams to declaratively manage IT infrastructure.

As the teams that manage network operations gain more proficiency with those tools, it becomes simpler to incorporate them within the construct of a larger DevOps team. While DevOps teams have been programmatically managing IT infrastructure-as-code (IaC) for years, network management has largely remained in a separate silo. However, as more applications are deployed in the cloud, it’s clear NetOps needs to become more integrated with the rest of the workflows employed to deploy and manage a highly distributed IT environment, said Stinemates.

Less clear is to what degree the networks that make up a hybrid cloud computing environment will continue to be managed by network administrators versus site reliability engineers (SREs) that are starting to assume responsibility for managing compute and storage.

Regardless of who manages the network, the next generation of microservices-based applications that are dependent on application programming interfaces (APIs) to call various services are much more latency-sensitive than previous generations of applications. Many of those applications will regularly experience performance issues due to networking issues that are often not readily apparent to DevOps teams. The goal should be to, at the very least, arm those DevOps teams with the tools required to confirm the source of those issues before a “war room” is convened to determine how to address the issue.

August 19, 2021
Micronaut Taps Moderne to Automate Java Framework Updates

Micronaut, a provider of a framework for building applications based on microservices and serverless computing platforms, today revealed it is allying with Moderne, a provider of a tool for refactoring code, to create a “recipe” that will automatically update the Micronaut framework.

Moderne CEO Jonathan Schneider said the open source OpenRewrite refactoring tool for code, originally developed at Netflix, makes it possible to automate updates to codebases, remediate vulnerabilities and provide a foundation for high-level building blocks that will make authoring custom transformations simpler. That approach will eventually be embraced by other providers of application development frameworks.

Fresh from raising $4.7 million in initial funding, Moderne makes OpenRewrite available via a software-as-a-service (SaaS) platform to enable IT teams to search and transform millions of lines of code in minutes. OpenRewrite currently supports Java, but the company is working toward adding support for additional languages, including infrastructure-as-code (IaC) tools such as Kubernetes, YAML and XML.

Moderne has also developed “recipes” for common search and refactoring operations that can be assembled into more complex recipes for framework migrations involving, for example, an upgrade from Java 8 to Java 11. Micronaut is the first provider of a development framework to create a recipe for its own framework using OpenRewrite.

At a time when applications are more distributed than ever, updating codebases is a major challenge. In fact, the manual effort involved in making those migrations is one of the primary reasons many organizations continue to employ older versions of frameworks such as Java 8. OpenRewrite is designed to automate that process at scale in a way that leaves it up to the individual developer to determine how involved they want or be or if they simply prefer to have a DevOps team manage the upgrade process on their behalf, said Schneider.

In the longer term, Schneider said he expects recipes will be created to address everything from mass migrations to remediating specific types of vulnerabilities across an entire codebase.

Too much reliance on legacy development frameworks generally stymies innovation. The latest versions of Java, for example, are designed to make it simpler for developers to build microservices-based applications.

It remains to be seen to what degree DevOps teams will embrace automation to upgrade code. Many developers are hesitant to rely on automated tools of any kind. However, given the need for most developers to spend more time writing new code, it’s only a matter of time before most of them come to terms with automated approaches to updating existing code.

In the meantime, the cost of supporting legacy frameworks should decline as organizations begin to migrate their codebases faster. One of the reasons there is so much technical debt in the enterprise is because different development teams tend to adopt different framework versions at different times. DevOps teams can find themselves being asked to simultaneously support multiple versions of the same framework. There may always be multiple versions of those frameworks, but, over time, DevOps teams should eventually see the bulk of deployed applications all using the same framework as the upgrade cycle becomes more automated.

August 18, 2021
MediaOps and DevOps Institute Earn Inc. 5000 Honors

I am really proud to announce today that both MediaOps and DevOps Institute have been honored by Inc. and earned inclusion in the Inc. 5000 list of the fastest-growing companies in America.

For MediaOps, this is the second year in a row we have earned this honor. For DevOps Institute, it is the first year they have been honored. First of all, congratulations to all of the great people who work at and make both MediaOps and DevOps Institute the great companies they are. None of the success of these companies would be possible without their talent, skills, hard work and dedication. Thanks to all of you.

Secondly, as the founder/co-founder of both of these organizations, I can’t tell you how proud I am that both of these companies have not only had the success they have (as evidenced by this honor) but that they have done so in the middle of a global pandemic. It really makes all of the hard work and the long days and nights worthwhile.

For anyone who has ever started a business, you know that you put a certain amount of your blood, sweat and tears into any venture you are involved in. It is no different here! Since 2014 I have put everything I could into growing MediaOps into the company it is today. For DevOps Institute, I was lucky to have my partner Jayne Groll, DevOps Institute CEO, take the lead in making DevOps Institute the leading member organization/certification authority in the DevOps space today.

Yes, you hope the monetary rewards of founding a company make it all worthwhile. But this kind of recognition is also very gratifying. It gives you the extra spring in your step and makes the load lighter.

These awards also highlight something else. The ascendancy of technology. It is no coincidence that both of these companies play in the digital transformation space and have seen such success. Digital transformation is driving the world right now. Software is driving digital transformation, and DevOps, cybersecurity and cloud are driving software.

At the end of the day, it is a great honor to have not one but two companies you started win this award at the same time. I think it speaks volumes about the future of both of these organizations. More news on that front is coming, so stay tuned for more great things coming from MediaOps and DevOps Institute!

August 17, 2021
Measuring Value Streams by Analyzing Flow Metrics

There is increasing pressure and demand for IT administrators to bring software to market quickly and cost-effectively. To achieve that goal, IT departments frequently compile various metrics that measure specific development processes.

Data and metrics are important tools, but administrators sometimes don’t think to look at projects through a wider lens—by measuring total production workflows. This can curb production and adversely affect business outcomes as inefficiencies go undetected across the value stream.

In other words, total visibility across the entire value chain is needed to accomplish lean project management and optimize DevOps workflows.

Let’s talk about the different kinds of flow metrics, why they matter and how to begin measuring them.

Flow Metrics: What do They Mean?

Flow metrics indicate the rate of value delivery with regard to desired business outcomes. This allows organizations visibility into production at a macro level so that they can make more effective decisions. Flow metrics can also produce an analysis of historical performance over time, which can be valuable for businesses that focus on continued growth.

IT leaders now widely use flow metric analysis to bridge the gap between business teams and technology, because it can uncover a variety of problems that affect critical objectives. For instance, teams can identify prioritization challenges, why projects take longer than expected, pinpoint technical debt and more.

When evaluating flow metrics, IT departments measure individual work units—also known as flow items—that clients or product teams hand over to their colleagues. This may be a request for a new software feature, a security flaw or something that needs a fix.

What Are the Different Kinds of Flow Metrics?

With a better understanding of flow metrics, we can now delve deeper into the five flow metrics that organizations should assess throughout the development process.

1. Throughput

Throughput measures the rate at which total number of flow items are completed. By measuring this, throughput can determine the total amount of value attained and distributed during a specific project.

Throughput is generally measured week-over-week. Measuring and evaluating throughput on a historical basis also helps work out how clashes in priorities affect value overall.

Optimizing throughput results in greater end user experiences and customer satisfaction, which naturally drives revenue and growth.

2. Cycle Time

Cycle time is the speed at which an IT team can deliver value. This means timing how long it takes for flow items to progress from work start to work complete, taking into account active and wait times.

Cycle time is just as important as throughput when it comes to driving revenue and growth. Measuring cycle time can streamline the process of determining project estimates and allocating resources, resulting in stronger workflows and enhanced efficiency.

3. Flow Efficiency

Flow efficiency is the proportion of active time to wait time. Measuring flow efficiency uncovers where roadblocks are happening and whether process waste is rising or falling. The desired flow efficiency rate should be higher than 15%.

Most flow time comes from waiting, resulting in roadblocks and increased production costs. Measuring flow efficiency can enable teams to pinpoint when workflows are taking too much time, and they can then take active measures to accelerate individual processes.

4. Work in Progress

Work in progress involves measuring demand. Teams achieve this by measuring the amount of flow items either pending or in active development within a value stream. Measuring work in progress generally enables IT leaders to identify whether value streams are overused or underused.

Nobody’s perfect. That’s why leaders have to be conscious of how each employee’s time is being used. By doing so, they can systematically assign workloads and enhance quality where required. This, in turn, lowers burnout and turnover while also cutting down on mistakes that need to be reworked.

5. Work Profile

Measuring work profile is important when determining priority alignment. It’s analyzed as a ratio of the four other flow items completed in a specific time period.

Assessing work profile allows for optimal quality and productivity. This raises customer experience (CX), which results in better retention and reviews.

Why Should I Track Flow Metrics?

In the past, DevOps professionals largely went without the necessary tools for tracking and enhancing flow metrics, but recent improvements in tracking these metrics have made the process much more efficient and easy.

There are three key reasons for flow tracking:

1. Boost Communication

A lack of communication can be a common issue between business and software teams. Flow tracking enables IT administrators to delve into flow metrics and gain insight into the value stream. This helps teams provide accurate project estimates along with real-time updates, which makes communication with stakeholders much easier.

2. Determine Desired Business Outcomes

Having total visibility across a value stream helps IT and business leaders cooperate on identifying and prioritizing key projects and establishing goals.

Improving software quality could be a goal, for example. Teams can examine various flow metrics to determine what is causing issues in software quality, how to fix those issues and how prioritizing adjustments to software quality could affect other workflows.

3. Act on Intelligence

Software organizations spend a lot of time and money attempting to expedite software development. They hold meeting after meeting, hire consultants or even bring on new team members, but the solutions they need to streamline workflows can be simple. They just need to be discovered.

Organizations can gain total and real-time visibility into the value stream with flow tracking. This makes it quick and simple to act on intelligence and enhance development, leading to accurate, data-driven decisions that don’t require guessing.

Elevate Your Value Stream With Flow Metrics

Achieving optimal efficiency in workflows requires end-to-end visibility, which is made easy by analyzing flow metrics.

Using flow metrics to maximize the value stream improves visibility, accelerates development and cuts software production costs.

August 16, 2021
Foundation Proposes Advancing eBPF Adoption Across Multiple OSes

The eBPF Foundation, which proposes to advance adoption of an approach that enables sandbox programs to run faster at the kernel level, is being launched today as an arm of the Linux Foundation.

The technology known as eBPF was originally developed for Linux. The eBPF Foundation is now committed to expanding use of eBPF across all operating systems. Members of the eBPF Foundation include Facebook, Google, Isovalent, Microsoft and Netflix.

Thomas Graf, CTO and co-founder of Isovalent, a provider of networking and security tools that leverage eBPF, said IT organizations should expect to see the technology become part of Windows, along with other operating systems, as the core technology is tested and validated across a much wider range of platforms.

In effect, eBPF changes the way operating systems are designed. It bridges the boundary between kernel and user space by enabling developers to combine and apply logic across multiple subsystems that, historically, were completely independent of one another. That approach enables, for example, a security tool to scale to the point where it can identify threats at much higher levels of throughput to improve overall scale at a time when the volume of cybersecurity attacks being simultaneously launched continues to increase.

Currently, eBPF is widely employed by web-scale companies such as cloud service providers. Facebook is using it as the primary software-defined load balancer in its data centers while Google is using open source Cilium networking software within its managed Kubernetes offerings.

However, adoption within on-premises IT environments that have deployed Linux has been more limited simply because the number of vendors that have optimized networking, security and storage offerings to take advantage of eBPF is still fairly limited.

Sysdig, for example, recently launched made available an instance of the open source Falco container security platform available that employs eBPF. Tigera has also made available an instance of its container networking platform that leverages eBPF at the kernel level of Linux.

Ultimately, Graf notes the biggest benefit of eBPF is efficiency. The total cost of processing for security, networking and storage platforms should decline as more vendors take advantage of a capability that will one day be widely employed across multiple operating systems.

In the meantime, IT organizations would be well-advised to ask their vendors when they plan to support eBPF. Cloud service providers generally require it to deliver their own managed services more efficiently, so any vendor that hopes to sell a platform to those providers will need to support eBPF to drive performance at scale. The issue then becomes determining which platforms that have embraced the technology are also available in on-premises IT environments looking for similar benefits.

Regardless of approach, it’s clear there will soon be a reason to upgrade not just networking, storage and security platforms but also instances of operating systems that don’t yet support eBPF. DevOps teams would be well-advised to plan accordingly because the number of platforms that will ultimately benefit from eBPF spans the entire enterprise.

August 12, 2021
Google Unveils Tool to Better Secure GitHub Repos

Google today launched a GitHub app that provides automated continuous enforcement of security best practices for GitHub projects.

Kim Lewandowski, a product manager for open source software security at Google, said the Allstar application enables IT teams to assess any project on GitHub to check for security policy adherence. In addition, Allstar sets desired enforcement actions and automatically applies those rules when triggered by a setting or file change in a repository.

The goal is to provide the open source community with a tool that makes it possible for organizations to have more confidence in the open source software that is being employed within a software supply chain, said Lewandowski.

Allstar is intended as a companion application for Security Scorecards, a tool that Google made available last year to assess whether, for example, an open source project employs branch protection to ensure that malware isn’t inadvertently committed to a project. Allstar continuously checks expected GitHub API states and repository file contents against security policies and the enforcement actions defined by an IT organization. After it detects a policy violation, the tool can be configured to simply send an alert or to automatically enforce a specific policy to remediate the issue, said Lewandoski. Specifically, she said the options available are to log the security policy violation without taking any additional action, open a GitHub issue or modify the GitHub setting to match the original Allstar configuration.

At present, Allstar provides a limited number of security policy checks, but more will be made available over the coming months, said Lewandowski. Current security policy checks include branch protection, vulnerability disclosures, access controls and detection of binary artifacts that can’t be scanned. Additional checks that will be added include automatic dependency updates and frozen dependencies.

Lewandowksi said Allstar and Security Scorecards are part of an ongoing Google effort to give back to the open source community that is being targeted by cybercriminals attempting to compromise software supply chains. Just about every application is now dependent on open source components, to some degree. The maintainers of those projects, however, don’t always have the tools or expertise required to check for malware that has been injected into a codebase, she noted.

In general, Lewandoski noted that achieving DevSecOps best practices will require a lot more automation of application security. It’s not possible for each developer to become a world-class cybersecurity expert. The challenge is finding a way to introduce that automation into the application development process as early as possible, which, she noted, in many cases starts with open source components that are incorporated in applications.

It may take a while for every maintainer of an open source project to revamp the processes through which code is added to their project. However, the easier it becomes to continuously review that software, the more confidence organizations that use it will have in its security. In fact, the maintainers of those projects should expect the downstream users of that software to be asking some pointed questions about how security is being managed in the wake of a series of recent high-profile breaches of software supply chains.

August 11, 2021