devopsy.kinsta.cloud

Tag: application development

  • GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech today launched a CodeSentry software composition analysis (SCA) for binaries that inventories third-party code used in custom applications and identifies known vulnerabilities.

    Vince Arneja, chief product officer for GrammaTech, said the bulk of custom applications today are made up of binaries based on components developed by a third-party that comes in the form of open source, commercial-off-the-shelf (COTS) or existing custom software.

    CodeSentry detects these components and vulnerabilities associated with third-party code, including network components, graphical user interface (GUI) components or authentication layers. It uses deep binary analysis to create a detailed software bill of materials (SBOM) and a comprehensive list of known vulnerabilities.

    Arneja said that as responsibility for security continues to shift left toward developers, there is a need for tools such as CodeSentry that make it easier to identify vulnerability issues in binaries because many developers may not have access to the underlying source code used to construct the binary. CodeSentry identifies components present in native binaries using a range of matching algorithms to gather version number ranges, create an SBOM and provide links to CVE and CVSS scores, said Arneja.

    CodeSentry extends algorithms that GrammaTech developed to detect components in applications, including strings used in natural language processing. It maps components to multi-dimensional vectors and compares them to vectors derived from the components. The upload interface for the tool accepts native binaries, zip files and other archives. Once those files are loaded, CodeSentry analyzes the code that will run rather than the build environment to reduce the number of false positives that would be generated in build environments or components that are not actually being employed.

    GrammaTech next year intends to make CodeSentry available via a software-as-a-service (SaaS) platform, noted Arneja. GrammaTech ultimately envisions CodeSentry being employed as part of DevSecOps workflows driven by a continuous integration/continuous delivery (CI/CD) platform using a set of open application programming interfaces provided by the company, said Arneja.

    While there’s a lot of focus these days on melding DevOps and cybersecurity workflows as part of an effort to embrace best DevSecOps practices, the easiest vulnerability issue to resolve is the one that never existed in the first place. As developers gain access to cybersecurity tools, the number of vulnerabilities making it into applications should significantly be reduced in the months ahead. The challenge IT leaders face is making sure developers have access to those tools, which in turn will ultimately boost the confidence level cybersecurity teams have in application developers, who are often viewed as the primary cause of the problems cybersecurity teams are trying to resolve.

    Regardless of how IT organizations achieve that goal, the return on that investment is likely to be substantial. The amount of time and effort IT teams spend tracking down vulnerabilities that are much more expensive to fix after an application is deployed in a production environment is incalculable.

  • How to Successfully Integrate Security and DevOps

    How to Successfully Integrate Security and DevOps

    As digitalization transforms industries and business models, organizations increasingly are adopting modern software engineering practices such as DevOps and agile to become competitive in the modern marketplace. DevOps enables organizations to release new products and features faster, but this pace and frequency of application releases can conflict with established practices of handling security and compliance. This leads to the enterprise paradox to go faster and innovate but stay secure by avoiding compromises on controls.

    However, integrating security into DevOps efforts (DevSecOps) across the whole product life cycle rather than being handled independently or left until the end of the development process after a product is released can help organizations significantly reduce their risk posture, making them more agile and their products more secure and reliable. When properly implemented, DevSecOps offers immense benefits such as easy remediation of vulnerabilities and a tool to mitigate against cost overruns due to delays. It also enables developers to tackle security issues more quickly and effectively. Getting security right from the start is important due to the growing dependence of companies on digital technologies that can make them more susceptible to cyberattacks, in which an attacker can utilize a system flaw possibly created due to unfamiliarity toward security as a business priority.

    DevSecOps integrates various security challenges into the coherent approach of software delivery. Some best practices followed in DevSecOps throughout the software development life cycle are:

    • Planning and Designing: From the inception, teams are aware of their security responsibilities and trained to handle them. Since the start teams quickly model threats and risks. Product backlog items (PBI) are prioritized in a way to make the product secure and compliant. Architectural design is developed in collaboration with security experts.
    • Coding: Developers practice secure and resilient coding practices. Full advantage is taken of reusable coding patterns and microservices to meet common security requirements for encryption and authentication.
    • Reviewing: Both automated and manual checks are used to review codes as part of regular agile sprints. After that, peer reviews are conducted by senior developers to make sure that software meets appropriate standards.
    • Testing: Automated security tests are run alongside automated functional and performance tests to confirm that testing is consistent. Automated penetration tests look for security cracks in systems as part of every sprint and release cycle.
    • Deployment: Automated processes are used to deploy code securely and reliably into production-hosting environments that can be rapidly invoked through APIs.
    • Operations: In production, automated processes such as real-time monitoring, intrusion detection and compliance validation are used to detect vulnerabilities. Product reliability and security are constantly checked to detect vulnerabilities and prioritize resolutions.

    The success of adopting DevSecOps principles relies on avoiding common pitfalls. The mere implementation of DevOps tools across the organization cannot support the effectiveness of DevOps. To get it right, companies need to:

    • Create a more integrated operating model making privacy and security principles as integral parts of the company culture.
    • Build secure and reliable services.
    • Wherever possible, automate development and release processes.
    • Continually evolve product architectures.

    Leaders play an active part in steering the transformation by endorsing security and privacy at the board level. At the same time, CISO and compliance leaders need to make certain that greater agility does not come at the cost of higher risk.

    Often organizations focus on software security as a business priority only after they are affected by a data breach. But when an organization is impacted by cybercrime, along with the costs of data damage, IP theft and business disruptions, it incurs legal and PR fees, drops in share price and the potential loss of customers and competitive advantage.

    Companies that implement DevSecOps best practices benefit from numerous advantages. Substantial costs can be curtailed by detecting and fixing security issues in the early phases of development, which indirectly leads to an increased speed of delivery and recovery.

    A secure and reliable product has the potential to increase sales. Following best practices leads to the creation of immutable infrastructure and utilization of cloud-based infrastructure that helps improve overall security by reducing insecure defaults, increasing code coverage and automation.

    Automated application testing, automated security review of code and empowering developers to use secure design patterns ensure the “secure by design” principle. In DevSecOps the responsibility for security is shared and encourages a culture of openness and transparency from earlier stages of development and enables constant iterative improvements.

    A central belief of DevSecOps is that security is an integral and essential aspect of DevOps. By adopting DevSecOps best practices in their product development cycles and avoiding common pitfalls, companies can stay current, acquire agility and strengthen their security to withstand exposure to cyberattacks.

  • How To Foster a Culture of Citizen Developers

    How To Foster a Culture of Citizen Developers

    What can leaders do to encourage a thriving environment of citizen developers in their organization?

    Over the last several months, businesses of all sizes have had to embrace rapid change, as have their workforces. When it comes to IT departments, even before the pandemic many were fielding requests to implement new technology, customize solutions to niche problems and automate specific tasks at rapid rates. Unfortunately, these increased demands coincide with an ongoing developer drought, and paired with the pandemic, have put an added strain on some already thinly stretched IT teams.

    As a result, there has been an observable rise in citizen developers being tapped to relieve some of this burden. “Citizen developer” here is used to describe any programming novice or non-developer who has been tasked with the responsibility of constructing custom applications. This person has some familiarity with programming but may not have been formally trained and, therefore, may use their own set of tools and workarounds to complete the work. If leaders don’t make an effort to create standardization, the consequence can be high variability in quality, efficiency and output.

    And it doesn’t seem to be a passing phase. I recently spoke with Dave Garrett, chief strategy and growth officer at Project Management Institute. As we look to the future, Garrett believes that citizen developers will play a critical role in helping organizations stay agile and ensuring projects move forward without delay.

    Though it won’t solve all of your pressing technical concerns, the good news is that with smart strategies, a citizen development emphasis can ease the burden on IT teams and improve output. Garrett spoke to a sea change of new techniques being developed to respond to these growing needs.

    4 Elements of Strong Citizen Developers Culture

    1. Standard Toolsets

    To start, build a solid foundation by choosing standard toolsets. Be sure all development staff is made aware of the toolsets you’ve deemed standard, clarify that adopting them is a priority and ensure that all have access. Standard approaches to using these tools should also be established and communicated, such as programming languages and stylistic standards.

    “If you have a standard toolset and approach, then you have many people who can help,” Garrett said, emphasizing that by doing so, you are building a broader base of support. Having a larger pool of employees to pull from helps an organization stay on top of the necessary tasks and creates more freedom for open collaboration. As a bonus, professional developers are freed to focus on more advanced tasks, such as machine learning and or mathematically complex programming.

    In deciding which toolsets and approaches to make standard, Garrett said, ask yourself, What will get them from A to B most quickly and efficiently? One approach to this is low-code or no-code tools. He considers such platforms transformational in empowering citizen developers to express ideas tangibly without a great deal of coding.

    2. Technical Training

    From here, ensure that all development staff, especially your citizen developers, have been technically trained in adopting the standard toolsets and approaches that have now been established. This may include offering training in low-code UIs and instilling fundamental programming concepts such as boolean logic and conditional programming such as If/Then/Else statements.

    “Set a foundation of success for learners,” he said. For example, have them build something of value during training, making it as actionable as possible for the use cases they will be handling.

    3. Discouraging Use of Shadow IT

    Once you have established toolsets and training, leadership should do whatever’s possible to enforce the established standard’s adoption and discourage the use of shadow IT—tools, applications and workarounds not approved by leadership within the company. Shadow IT, as a practice, can be messy, creating high variability and making quality-control and collaboration difficult. “You want to avoid it,” Garrett said.

    4. Good Mentorship and Governance

    Another benefit of having a standard toolset and eliminating shadow IT use is that it enables more efficient mentorship—critical for inspiring citizen developers. IT teams are advised to identify a mentor or group of mentors proficient with the standard tools to offer ongoing guidance to the team’s citizen developers.

    Quality mentorship goes hand in hand with quality governance. “Governance” here is used to mean technical admins who enforce the use of technical standards, tools and programming styles. No-code tools require access control that reflects a citizen developer’s permissions.

    Building in Hyper Agility + The Two-Pizza Rule 🍕🍕

    One way to think, Garrett said, is hyper agile. This can apply to team size, smart PM cycle lengths and brainstorming techniques.

    Team Size

    In thinking of ideal team size, ask: How can the team be optimized to work quickly and efficiently? One suggestion Garrett had was to ensure your team isn’t too large to effectively train, mentor and govern. For example, as a rule of thumb, he mentioned the old “two pizzas” rule: A team size shouldn’t require more than two pizzas to share a meal.

    Sigh. Remember things like in-person training? Pizza parties? Obviously, old meetups can’t be executed exactly to plan these days, except with some clever contactless delivery tactics, but you get the idea. A strategically sized team will create an efficient workflow and collaboration in your team dynamics.

    Cycle Length

    As projects come in, an agile cycle length, or sprint, for completing a specific set of work should be determined. What is an efficient amount of time to expect a team to turn out a project? To determine this, sprints should start with a planning meeting during which the product owner defines the work criteria. The development team determines a realistic time frame to complete the work scope. The scrum master or team manager typically makes this call.

    The lengths of agile sprints can vary—some may be two weeks, while others may be 30 days—depending on the scope of work. Most project management experts recommend you aim to keep your cycle length consistent, so teams get used to working within a set amount of time.

    Brainstorming

    Bringing attention to how your team ideates together is an excellent way to build agile collaboration. Brainstorming as a development team fosters collaboration and allows you to aggregate the talent and pull ideas together for the best output, whether you’re trying to solve a niche problem or simply join forces around how best to complete the sprint.

    Garrett recommended bringing people together in smaller groups for round-robin brainstorms and creating as you’re ideating. “Thus, iterations happen fast,” and all team members are given a chance to express their ideas in a tangible way.

    Once citizen developers see success, you can then use the excitement of building applications and solutions together to drive things forward, he said. Your anchor is a cool product that gets people excited—great for both morality and high-quality output.

    When Are Citizen Developers Appropriate?

    The question should be asked: When is it appropriate to call on citizen developers? Garrett recommended performing a suitability assessment to identify the best use cases for citizen developers. This will help the organization understand when it’s smartest to bring them in.

    The easiest way to answer this may be to consider: When isn’t it appropriate? Assigning advanced processes to citizen developers such as algorithm-heavy, mathematically complex programming or core product functionality is usually inappropriate, he said. Instead, utilize citizen developer talent for constructing internal business utilities that can be automated easily.

    There are formal suitability assessment tools that look at scores and attributes for applications to help you make this call. “However, everyone’s different,” Garrett noted. “You have your own ways of working, given context, goals and what you’re trying to accomplish.” So it may make the most sense to perform your own internal suitability assessment.

    Do the Numbers

    According to a recent PMI report, over the past five years half of organizations have recognized team members who brought innovative ideas forward, but:

    • Only 25% required dedicated time for innovative thinking and idea generation.
    • Only 19% hosted a creativity lab or hackathon facilitated by a professional.

    By contrast, their research shows that those promoting innovative practices see stronger results. Case in point:

    • 80% of organizations that encourage project leaders to expand their role have invested in at least one innovative idea in the past five years.

    The trend PMI sees on this front is that organizations want to innovate, but don’t always know how to make it happen. So, how might they push innovation forward? If you can implement a strong citizen development toolset, you can “enable innovation to bubble up,” Garrett said. The hope is this guide offers a blueprint for fostering just that.

  • ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth has extended its namesake software-as-a-service (SaaS) platform for orchestrating DevSecOps toolchains to include integrations with Scout Suite, Aqua Trivy, Gitlab and BitBucket Server and the configuration management database (CMDB) from ServiceNow.

    The company is also adding application portfolio reports to surface the security policies applied to each application, scan results and progress of remediation work and the ability to customize both alerts and vulnerability data compression parameters, such as rate of compression, name and type of vulnerabilities and libraries.

    Finally, filtering and search tools that can be applied to vulnerability datasets have been added.

    ZeroNorth makes it possible to centrally orchestrate and manage both commercial and open source application security scanning tools via a SaaS application platform.

    Christian J. van den Branden, senior vice president of engineering and product management, said that as DevSecOps processes continue to evolve and mature, most application development teams will employ multiple scanning tools because not every tool discovers every vulnerability. This defense-in-depth approach to vulnerability scanning requires an orchestration tool to integrated multiple scanning tools within a DevOps pipeline, he said.

    That orchestration tool also makes it easier for DevOps teams to prioritize vulnerabilities based on their severity discovered by various static application security testing (SAST) and dynamic application security testing (DAST) tools, noted van den Branden. Tools from vendors such as Qualys, Snyk, Palo Alto Networks, Synopsys and WhiteSource are supported across multiple DevOps platforms.

    In general, van den Branden said a “perfect storm” of security issues is forming in the wake of the COVID-19 pandemic. Organizations are rushing to build and deploy digital business applications that will appeal to end users who increasingly are working from home using largely unsecured networks. Cybercriminals are looking to both compromise applications as they are developed in addition to targeting end users with weak credentials that could be employed to inject malware into applications after they are deployed in a production environment, he said.

    Most IT organizations will clearly need to up their application security game, given the sensitive nature of the digital business processes that need to be protected, he added.

    Ideally, DevOps and cybersecurity teams will meld their workflows to achieve that goal. In many cases, however, DevOps teams will simply extend their existing pipelines to address security issues of their own accord as part of an effort to reduce the number of remediation issues they might need to allocate time to remediate after an application has been deployed in a production environment. That becomes easier to accomplish using a SaaS-based platform to orchestrate DevSecOps processes and pipelines, noted van den Branden.

    Regardless of how IT organizations improve application security time is of the essence. More applications than ever are being deployed across an extended enterprise that now stretches from public clouds to multiple classes of edge computing platforms. Defending that attack surface relying on legacy tools and processes is all but impossible if the code deployed on those platforms is fundamentally insecure.

  • Netlify Extends JAMstack Reach to Edge Computing

    Netlify Extends JAMstack Reach to Edge Computing

    Netlify, at its JAMSTACK CONF VIRTUAL event today, announced Netlify Edge Handlers, which make it possible to extend a Git-based workflow to edge computing applications.

    Company CEO Matt Biilmann said Netlify Edge Handlers, available in beta, puts the primitives in place for deploying serverless web applications based on a JAMstack software architecture that employs JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as JAM, to isolate front- and back-end components of an application.

    A Git-based approach will also enable DevOps teams to extend workflows to edge computing applications that can be deployed on any number of platforms, he said. As an extension of a Netlify platform written in a modern Rust programming language, Netlify Edge Handlers makes it possible to build and launch web applications and websites based on a JAMstack architecture from within a continuous integration/continuous delivery (CI/CD) environment.

    Prior to the availability of Netlify Edge Handlers, building and deploying web applications on edge computing platforms required extensive coordination across teams, the creation of detailed edge logic with many dependencies and deviation from standard web development best practices, Biilmann said. Now, developers can write simple JavaScript that builds and deploys to the network edge in a way that enables simplified A/B testing, custom authentication and API aggregation, he noted.

    Developers also can build and manage edge logic from preview to production, including deploying those applications via the existing Netlify multi-cloud network.

    More application code is being pushed out to the edge because many organizations are now processing and analyzing data closer to where it is created and consumed, as part of their digital business transformation initiatives. Web applications that execute closest on a node to the user eliminate or reduce roundtrip request and response flows with the client.

    Biilmann also noted that because those applications are employing a platform developed using Rust, they are also inherently more secure.

    There may come a day when there are more application workloads collectively running at the edge than there are on cloud computing platforms. However, if that goal is ever to be achieved, it needs to become easier for developers to build those applications. Given the fact those applications are also likely to be targeted by cybercriminals, it’s critical to ensure those applications are as secure as possible.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, many organizations have accelerated digital business transformation initiatives, many of which depend on edge computing platforms. The only way to achieve that goal, however, is to make it possible to build these applications using JavaScript tools that most developers of web applications have already mastered. Otherwise, organizations will need to invest in training developers to master another framework for deploying edge computing applications. That would require time they might not have.

    Regardless of the path forward, a massive wave of edge computing applications soon will stretch the boundaries and limitations of whatever DevOps processes organizations have in place today.

  • Low-Code, High Risk? Closing the Security Gap of Exposed Source Code

    Low-Code, High Risk? Closing the Security Gap of Exposed Source Code

    There’s no denying that low-code is a rising trend in application development that’s likely to stay for the long run. Its impressive benefits in terms of agility and development time are convincing the enterprise, so it’s no wonder that the industry is on its course to achieve fivefold growth between 2017 and 2022.

    In low-code platforms, building custom cloud applications can be achieved by reusing components through a simple drag-and-drop interface, which means reduced engineering efforts. Then, APIs can be used to hook components together and maximize compatibility.

    Although many steps of the way can be achieved without actively writing a single line of code, many low-code apps include advanced logic written in JavaScript. So, when it comes to understanding the threat model of low-code platforms, we must consider security considerations that arise from using JavaScript code.

    Low-Code and JavaScript

    Because JavaScript needs to be interpreted by a browser to work, it is exposed and anyone can access, read and modify it. This becomes problematic because companies store important business logic on the client-side, which is often unavoidable due to the inexistence of a back end or the need to avoid performance losses. So, companies’ proprietary algorithms and logic end up running on an adversarial environment, which opens the door to a series of attacks—namely, automated abuse, piracy, intellectual property theft and data exfiltration.

    When it comes to protecting code, typically we’re led to the concept of encryption. However, JavaScript encryption is not a feasible strategy; the browser always needs to interpret JavaScript so that it works. If we have a decryption key, we need to supply it to the browser; if that key becomes compromised, all the code will be easily accessed.

    A suitable approach to protect JavaScript is transforming it into a new version that is extremely difficult to understand while also preventing attackers from debugging or tampering with the code.

    When it comes to enterprise or commercial applications, JavaScript must be protected with maximum resilience—that the protected code will prevent attackers from using automated tools against it. On top of this, the code should contain runtime defenses that break the application whenever attackers try to debug or tamper with the app’s source code.

    Conclusion

    Low-code still means a lot of code. Even though most of it will not appear on the front stage, development teams must not forget that it should always be protected. Attackers love low-hanging fruit and unprotected source code of enterprise apps is certainly a low-effort, high-gain venture.

  • AIOps and the Myth of ‘Move Fast and Break Things’

    AIOps and the Myth of ‘Move Fast and Break Things’

    Observability through AIOps enables developers to find problems faster by cutting through the noise

    Years and years ago, a little-known entrepreneur named Mark Zuckerberg uttered the phrase, “Move fast and break things,” to his development team. Since then, dev teams have stuck to this “move fast and break things” mantra, where fast development far outweighs dealing with a few bugs down the road. Under this mindset, finding and fixing problems is essentially the last step in the development process.

    The Problem With Breaking Things

    This way of working has served dev teams well over the years as consumers continue to demand speedier innovation. But as end user expectations around deliverability speed rise, so do expectations around service reliability. Customers now want better products faster. Not only does the “break things” way of development lead to extra work for the dev teams down the road, but it also degrades customer trust over time as issues, from a buggy user experience to major security concerns, pop up once the product is already shipped.

    Even Zuckerberg realized this years later, admitting, “What we realized over time is that it wasn’t helping us to move faster because we had to slow down to fix these bugs and it wasn’t improving our speed.” He realized this so much so that the Facebook team officially changed their mantra to “move fast with stable infra” in 2014. Sure, Zuckerberg shouldn’t be our role model after everything that has happened, but if he can realize the need for stable infrastructure, so should we.

    So, how do dev teams meet growing end user expectations while cleaning up the now hurried development process for more stable systems?

    Observability With AIOps and the Development Process

    This is where observability strengthened by AIOps (artificial intelligence for IT operations) comes into play. Observability—or simply making data readily available from a system that you want to monitor—enhanced through AIOps allows dev teams to automate their monitoring. This automation can include applying AI/ML algorithms to all data; eliminating noise; detecting anomalies; correlating relevant metric anomalies, traces, changes and log events triggered by incidents; using contextual data to surface incidents; and identifying probable root causes of those incidents. This gives the teams a more complete picture of what’s happening in their systems, where the bugs are and how to resolve issues quicker, ultimately speeding the development processes overall.

    Through observability with AIOps, dev teams can actually build systems faster by finding problems earlier, cutting out the time-consuming process of retroactively fixing mountains of problems after the product has already shipped. On top of that, finding these problems earlier ultimately leads to more reliable services—and reliable services mean happier customers. When the product actually works the first time around and there’s a system in place to find and fix evolving issues, there’s less legwork to make customers happy. It’s a win-win.

    Observability with AIOps also means freeing developer time and effort to focus more on innovation and less on operations. And who doesn’t want to work on higher impact projects more often instead of spinning their wheels making sure the work they’ve already done is actually functioning correctly?

    We Need to Stop Stalling

    It’s easy to get stuck in your ways, but that is the only reason dev teams haven’t improved their processes to streamline workflows and build better products. Simply put, we have to stop stalling on making this change because, finally, moving fast doesn’t have to mean breaking things.

    We can continue to move fast while building products that are better quality and keep customers happier if we change our mindset around the development process. As developers, it’s our responsibility to evolve with the best strategies for our team, customers, and business—and we now have a way to do so by embracing observability with AIOps.

  • Pinpoint Simplifies Managing Remote Dev Teams

    Pinpoint Simplifies Managing Remote Dev Teams

    Pinpoint today added a User Dashboard to its namesake platform for managing software projects that makes it easier for remote developers to stay focused.

    Company CEO Jeff Haynie said the User Dashboard provides developers with a personalized view of their work priorities and schedule for the day. It also provides a means to employ their Pinpoint Profile to highlight personal achievements and engage other engineers on the Pinpoint Platform.

    The Pinpoint platform is designed mainly to identify software development bottlenecks that could delay a project. Most recently, the company added machine learning algorithms and advanced analytics to surface additional insights and recommendations.

    This latest update extends the use of machine learning algorithms via a Recommended Content feed that curates content from blogs, podcasts and other media based on the observed interests of developers. Much like a built-in RSS feed, Recommended Content is an experiment to see whether the platform can save developer time by eliminating the need to scroll through less-relevant news, said Haynie.

    In the wake of the COVID-19 pandemic, he said, many organizations are struggling even more to manage distributed or remote developers. It’s also now much easier for developers to become isolated from the rest of their team. The User Dashboard provides a way to engage developers through the same platform managers employ to track projects.

    While there is no shortage of collaboration tools, Haynie noted they all tend to be tied to a specific DevOps platform. Pinpoint is designed to automate the process of collecting data from multiple tools, which the platform then analyzes to surface potential bottlenecks in the software development process. As software development projects become more complex, there is a need for a tool to visualize how hidden dependencies might upend delivery schedules, he said.

    The User Dashboard now extends that framework out to individual developers, who can view how to prioritize their specific tasks in keeping with a larger set of goals, Haynie added.

    Developers don’t typically have a lot of visibility into how their efforts ultimately impact the organization. In the absence of that information, it can become difficult to stay motivated, especially when working from home. Project leaders are now always going to be able to personally engage each developer every day, especially if members of the development team are located in different time zones.

    The User Dashboard isn’t a substitute for personal interactions, but it does provide a means for developers to quickly learn at a glance what needs to be done next in a way that serves to minimize miscommunications. It’s not all that uncommon for developers to lose valuable time by being told to do one thing when they should have been focused on a different task.

    Less clear is to what degree Pinpoint might be able to flatten management hierarchies within development teams. As a general rule, the fewer managers required the more an organization can allocate funds to hiring developers who, with the aid of the right platform, might one day manage themselves.

  • Harmonizing Real-Time on Edge Platforms

    Harmonizing Real-Time on Edge Platforms

    Edge computing platforms sit at the boundary between the real-time world and the digital enterprise. Uninterrupted, uncorrupted data from the edge is a must if analytics in the cloud drive reliable business decisions. What’s the best approach: using Linux, an RTOS (real-time operating system), a hypervisor or something else for edge platforms?  Let’s talk about harmonizing real-time on edge platforms and introduce a new foundation project in the Linux Foundation’s LF Edge family.

    Real-Time and Deterministic

    Real-time only means events are captured, tagged and processed as they unfold in the real world. That cadence can be seconds, milliseconds or microseconds depending on how many events and how often they occur and how tasks and algorithms stay in control. Three operating system characteristics determine how well real-time execution keeps pace: prioritization, interrupt response time and context switch time.

    Prioritization ensures that tasks receive resources when needed. Tasks at a lower priority should pre-empt when a higher priority task requests service. A task refusing to yield to pre-emption can throw off the prioritization scheme, causing missed deadlines.

    Interrupt response time measures the latency from the time an event requests service via a hardware interrupt to when the handler task executes. Real-time hardware platforms often place high-priority events on hardware interrupts for fastest pre-emption.

    Context switch time is softer scheduling at work. It measures the time for a change in processing control from one execution entity to another, swapping out resources including registers, cache and memory as needed.

    Deterministic means there are no surprises in behavior. The faster real-time events happen, and the harder a system works, the more likely non-determinism surfaces. One venture into virtual memory paging or a burst of networking activity can show up at an inopportune time, even though under most conditions real-time performance is adequate.

    ‘Hard’ vs. ‘Soft’ Real-Time

    That’s why most people think of real-time as “hard” with a fast, deterministic operating system. RTOS platforms optimize the kernel and only build things in around it that are necessary, providing rigorous and sometimes mathematically proven scheduling for many tasks.

    “Soft” real-time is more forgiving. On a fast processor, interrupt response time is tiny compared to the execution window. A system that isn’t deterministic can, if there is enough margin in context switch time, keep up with real-time events on a slower scale. Linux, while not deterministic, can handle some real-time needs through minimizing packages and tuning the kernel for better prioritization.

    Linux also benefits from lighter context switching. Originally, execution entities in Linux were resource-heavy processes. Now, threads can handle tasks with far less switching overhead. POSIX threads standardized the approach with portability between Linux and RTOS environments.

    How fast are threads? According to a recent synthetic thread benchmark by Eli Bendersky, switching on server-class platforms with enough memory, cache and storage can be in the range of 2 microseconds with 10,000 threads under ideal conditions. Eli pointed out his test environment has more RAM than many edge hardware platforms provide, but most edge applications won’t need that many threads, either.

    So, the line for soft real-time has moved down into new territory, making the trade-off between hard and soft a bit blurrier.

    Hypervisors and Orchestration

    If your DevOps team commits to an RTOS, you may give up some familiar functionality and have a learning curve to deal with, but you get assured hard real-time performance. If you go with Linux, you get the tools and coding practices you’re used to, but soft real-time performance can be an issue as code piles up.

    The leaders in RTOS platforms with enterprise networking noticed this, too. Recently they’ve turned to hypervisors in a bare-metal approach. A hypervisor can capture the benefits of environments working together, so teams are not forced into an either/or operating system choice. This is especially important if the edge application requires some form of certification, such as in medical, industrial or defense applications. Certified code can be compartmentalized on an RTOS, while Linux runs alongside.

    Linux providers are turning more toward orchestration layers and containers. It’s an application focus speeding up deployment, with more scalability and less hardware dependence. It also brings the edge into the enterprise faster with the same application deployment strategy anywhere. More code means more determinism risk.

    Convergence is a faint hope on this landscape with competing objectives, but a new approach offers a path for software reuse and rapid deployment.

    Harmonizing the Edge

    The Linux Foundation is active across the spectrum of IoT development, from the Zephyr open source RTOS to various embedded Linux projects. One of the newest projects in the LF Edge initiative is a foundation targeting a blend of deployment models in a consistent, open approach.

    Project EVE (short for Edge Virtualization Engine) supports containers, clusters, virtual machines and unikernels simultaneously. It’s a slim bare-metal runtime offering hardware root of trust, device resource management and software update and patch functions. EVE can host any combination of apps in virtual machines or containers, including running an RTOS with its application in a virtual machine. It can even assign CPU and GPU cores to specific applications for enhanced determinism.

    On the EVE road map is support for the ACRN hypervisor (another LF Edge project) and shrinking the EVE runtime for smaller embedded-class edge platforms. These efforts are essential where real-time requirements become harder and a hypervisor plus an RTOS makes sense. For softer real-time environments, EVE is adding support for Kubernetes K3S, Docker Compose, VPNs for public clouds and mesh networking for data flow between edge platforms.

    While the project is still young, EVE holds great promise for DevOps teams working the edge. We’d look forward to seeing some benchmarking on a real-time scale; it likely handles soft real-time needs as well as Linux today. By harmonizing a range of diverse approaches into one foundation, EVE is creating a space for real-time on edge platforms no matter which development perspective teams come from.

  • Crowdtesting: How to Ensure Quality in Disruptive Times

    Crowdtesting: How to Ensure Quality in Disruptive Times

    The practice of crowdtesting has taken on greater importance during the COVID-19 pandemic, for good reason

    Entering 2020, digital transformation projects and initiatives dominated tech spending for most companies. But, between a global pandemic and fiscal uncertainty around the world, spending must be shrinking, right?

    Think again.

    If anything, the pandemic has created a sense of urgency for many companies, accelerating digital transformation in organizations. According to June data from TEKsystems, 56% of digital experience leaders—companies with mature digital transformation strategies—have increased spending on digital transformation. Remarkably, more than one-third of digital experience laggards—those that have historically had limited digital transformation initiatives in place—also increased spending on digital transformation projects.

    The rush can be attributed to COVID-19. For businesses, it has changed the future of work. Distributed workforces are nothing new, but very few companies were prepared to deal with a fully distributed model in which all employees are working remotely. The pandemic has changed buyer behaviors, too. In lieu of malls and brick-and-mortar stores, people have turned to e-commerce sites for the bulk of their shopping. Legacy companies, such as Pepsi, for example, are building direct-to-consumer e-commerce sites in response to the evolving market dynamics.

    Digital is now the primary means of communication for businesses. Digital quality is no longer a niche issue for the application and DevOps teams; it is a strategic business imperative in the C-Suite.

    Apps Everywhere, At All Times

    Apps need to be tested by real users, on every device, network and operating system, across the globe and at all times. The typical workday used to be 9 to 5, but that’s no longer the case. With most workforces now remote, the days are longer and the diversions greater (yes, I’m looking at you, juggling Zoom calls and your daughter’s remote learning plan at school). Customers, too, have higher demands for the technology they use. There can be no downtime; downtime means customers will look for alternatives, becoming ex-customers and resulting in lost revenues.

    In today’s extremely fragmented device landscape, QA teams face increasing difficulties in keeping up with the myriad device/OS combinations they need to test on. For obvious reasons, purchasing and maintaining a nearly endless pool of devices is not an option—not only is it too expensive but it’s also time-consuming and harms the team’s productivity.

    Beyond logistics, QA teams must collect data from real-world testing to make informed decisions. No matter how many test cycles are run, QA teams can’t uncover all unexpected bugs and edge cases unless they include in-the-wild testing in their strategy.

    To test anything related to hardware in an efficient manner, leveraging a community of remote testers is the best way to obtain reliable results without burdening internal QA resources, generating disproportionate costs or missing out on important use cases.

    Crowdtesting Replaces Offshoring as the De Facto Way to Test Software

    With a market greater than $50 billion in India alone, there is no denying the offshoring model worked. But, the pandemic exposed pre-existing cracks in the model, causing many businesses and entire industries to regroup, re-evaluate and find new ways to accomplish tasks that just a few months prior would have been routine.

    When the pandemic hit, the supply chain broke. Testing and product development facilities built on product teams working collaboratively in close proximity struggled to keep up with the most basic needs of their customers. Outsourcing companies and their employees lacked the infrastructure to work remotely, negatively impacting the business continuity of their clients.

    This new reality leaves companies that are used to the offshoring model for testing and QA with one big question: what is the best way to test software and digital experiences in a post-COVID-19 world?

    While crowdtesting has been a factor in application and digital testing for more than a decade, it has taken on increased importance as internal QA teams can no longer maintain business continuity while working remotely and the offshoring model has faltered amid the pandemic.

    The reason the crowdtesting model remains a reliable answer even during COVID-19 is that it is always done remotely, via a community of vetted testers who already work in remote environments. This setup allows testing teams to maintain business continuity, while often improving test coverage across devices, operating systems, geographies, demographics and more.

    As an example, let’s look at how the Israeli government used crowdtesting to bring its tracing app to the country. The Israeli Ministry of Health developed the app using cellular GPS data to provide alerts on areas with high concentrations of COVID-19 infections. The app is designed to prevent COVID-19 spread by notifying people who were in the vicinity of verified coronavirus carriers. Similarly, healthcare provider K Health has used crowdtesting to help it launch a new COVID-19 diagnostic feature. K Health was already using crowdtesting services prior to the onset of the pandemic to ensure its mobile app functioned properly across all relevant device/OS combinations and timezones but found the scalability and reliability of the model meshed perfectly with the demands on healthcare providers in the new normal. When K Health offered free services to all Louisiana residents, crowdtesters were there to scale testing at a moment’s notice and provide 24/7 test coverage for the K Health app.

    It was urgent to get the app out quickly, but it also needed to work properly. Did push notifications go through promptly and to everyone? Would the app work across devices, and in different configurations? Since launching the app in March, the Ministry of Health has been able to leverage continuous crowdtesting to identify dozens of bugs that could have prevented Israelis from using the app or trusting its results.

    For example, the testers discovered that the app crashed when it was used in dark mode, and certain situations led to the app showing that it detected data even when data and location services were off. Since this second error was directly related to the main functionality of the app, it represented a very critical bug for the Ministry of Health to fix.

    Crowdtesting uses real devices and real people in their daily environments, which accounts for all these variables that are not seen in traditional labs and offshoring facilities. That makes crowdtesting a valuable testing approach even after the COVID-19 pandemic and resulting lockdown ends.