devopsy.kinsta.cloud

Category: Application Performance Management/Monitoring

How Does IT Management Govern EverythingOps?

The number of tools engineers use to provision software architecture in the cloud is starting to get a little out of hand. There are many competing ways to do one thing. Most often, people simply adopt a new tool to solve a DevOps problem in the moment, not always considering the longevity of the solution or how other departments are handling it. This could result in fragmentation and technical debt, making it difficult to find consistency and increase speed simultaneously across all company divisions.

I recently interviewed Jeff Kukowski, CEO, CloudBolt Software, to explore why these issues persist and how executives should approach cloud management within their organizations. According to Kukowski, many flavors of Ops now permeate large companies. Different approaches often exist per department or interdepartmental, with teams using various software stacks.

According to Kukowski, a new frame of mind will be necessary to remain agile in the new cloud order and to address this state. Doing so will require organizations to erode false dichotomies around ownership and IT governance.

Everything’s Going Ops

At this point, most large suites of digital services have adopted a complex hybrid and multi-cloud modality. And many teams have embraced their own unique form of DevOps to get a handle on the management difficulties of delivering software and maintaining reliability for microservices architectures. Different groups pulling in various directions create an ongoing battle of EverythingOps, explained Kukowski.

You can think of it as separate Ops approaches emerging around different business functions. For example, FinOps is emerging to control spending, ITOps is about delivering services, DevOps is improving release fluidity and DevSecOps aims to bring security to the forefront of the release process. Lastly, BizDevOps is about increasing observability for business outcomes.

At a high level, CIOs have committed to digital transformation to move quicker. Yet the problem now is “battles between different Ops can easily lead to broken IT governance,” said Kukowski. This tension introduces several false dichotomies, he explained. In addition to slowing agility, a lack of DevOps unity eschews reusability, contributing to waste and increased IT expenses, said Kukowski.

Solution: Shifting Governance Left

There is a belief in IT that true innovation will come if you only give engineers the keys to use anything they want. While that may be true, without better leadership with regard to the basics in this new cloud order, some things can get out of control very quickly, Kukowski warned. Instead, he argued that built-in guardrails for provisioning tools are necessary. “We have too many tools—we need better frameworks to tie this together.”

Not only would increased cloud governance help tie together disparate tooling decisions, but Kukowski argued it also can reduce the cognitive load necessary to onboard each tool. “Shifting left will increase speed—it won’t slow people down,” he said. Contrary to popular belief, he said that shifting guardrails left can have the effect of increasing speed, which may greatly outweigh the negatives of shackling developers to a single approach.

CloudBolt predicted siloed management will shift to organizational governance around tools in the coming year. But it’s not only the tooling decisions that require forethought, “it’s the leadership and cultural approach,” said Kukowski. A common area where greater leadership is required is in tagging workloads for applications, he said. “It’s not being done well anywhere.”

Or, consider containerization. Containers have become fundamental to most modern cloud technology stacks, yet, the cognitive load required to deploy, configure and run a contain remains quite high, explained Kukowski. Do you allow every developer to custom-code each container, or do you enable a self-service repeatable provisioning process? If standard code is not being reused, you’re not getting speed or governance, he explained. Furthermore, with green IT initiatives becoming a priority, companies should be looking at ways to reuse processes and reduce waste where they can.

Final Thoughts: Shift Left, Automate and Reuse

For a cloud-native company, the emphasis is constantly on speed and growth. And engineers are absolutely driving this focus and the resulting innovation. Yet, this innovation can’t come at the expense of bringing all departments onto the same level of innovation. “Innovative stuff in the cloud can’t be separated from governance, ESG and security,” said Kukowski.

A big hurdle of tomorrow’s cloud management will be identifying and uniting these islands of automation, these pockets of tools and preferences that differ between departments. It will also require a different frame of mind across divisions. “There’s a difference between solving the problem for the task and solving the problem for reuse and speed,” explained Kukowski. Delivering on reuse and speed will require less bespoke DevOps automation and better foundations for solving future problems, he said.

“Shift left, automate and reuse—people shouldn’t have to touch it. That’s the thinking that needs to be applied to this new cloud order,” said Kukowski.

February 1, 2022
Building a Reliable App Installation Experience With MSIX
Simple, safe, reliable software installs and uninstalls are always best, but getting there isn’t easy. Applications break each other—or even the operating system itself.

MSIX, Microsoft’s packaging format, is the newest replacement for the decades-old Microsoft Software Installer (MSI) and setup exe installer technologies. MSIX is gaining acceptance and wider adoption because of the benefits it delivers: security, ease of use and reliability in application installations.

MSIX provides a new, modern runtime environment intended to protect both your application(s) and end user systems. Enterprise users prefer the MSIX format because it provides the most appropriate framework to modernize applications; simultaneously reducing IT departments’ workloads when preparing application package(s) for delivery to hundreds or thousands of end users.

As developers who build Windows desktop applications embrace the concept of running code in an MSIX container, understanding certain key concepts can streamline and strengthen their application installation experience.

Why MSIX?

Running code in an MSIX container can solve common problems encountered by developers coming from non-containerized deployments. This includes products built and delivered as a Win32, .Net Framework or Universal Windows Platform (UWP) packages—or when starting a new project from scratch.

In addition to providing clean installation and uninstall processes, MSIX enables enterprise customization in independent packages via modification packages. It also supports the ability to deploy applications through enterprise tools (e.g., Microsoft Endpoint manager) or to the cloud (Azure Virtual Desktop, MSIX app attach).

Value for Developers and IT Pros

MSIX improves upon the more restrictive model of UWP while still running in a container. It allows developers to code in their preferred way (e.g., unmanaged code using Windows Forms, calling the Win32APIs or managed code using XAML and .NET framework versions of the APIs).

Some tactics must be changed to run inside the MSIX container, however. In addition to minimizing work, it facilitates building modern IT ecosystems, deploying apps and updates faster and more frequently and modernizing applications into the new world of containerized packages.

MSIX also supports deploying applications via enterprise tools (e.g., Microsoft Endpoint Manager) or even to the cloud.

Value for Users

By delivering a more streamlined installation experience for users, MSIX offers benefits to customer and end users, including:
- Guaranteed clean installs: This prevents time wasted on installs, uninstalls, reinstalls or issues that occur with other installed applications.
- Isolation between applications except when isolation isn’t desired.
- Greater security to protect the customer and the application.
- Improved features including automatic updates, differential updates and disk space optimization—without having to customize code or the packaging process.
- Single-instance storage; automatic block-level deduplication for any file in any installed package.
- Fewer support calls: This cuts down on annoyances, delays and expenses for all involved.
Elements of a Successful MSIX Project

MSIX projects require a different approach than what many developers are accustomed to. To provide customers with the best package file(s) possible, consider the following elements as part of the project. Doing so will strengthen additional project activities, project setup, testing and debugging and supported schemas.
1. Digital signing: Secure installations of MSIX packages are provided by installing the application to the app container and enforcing the app packages with digital signatures (with a valid code signing certificate). Only trusted apps are installed, enforcing the integrity of the package and its container after deployment.
2. Package components: An MSIX package includes files that are essentially a set of ingredients—some generated directly (e.g., image files for the start menu) and some created as part of the build process (e.g., output by other vendor tooling). Ingredient files—including root and virtual file system (VFS) folders—will be passed to the MakeAppX command to generate the package.
3. An efficient MSIX build process: Custom modifications are sometimes needed for a package, such as when PSF is appropriate for handling a few unexpected scenarios; this requires repackaging extracted contents back into the MSIX package. Whether or not such modifications are required, an efficient build process is always necessary. Building an MSIX/APPX package manually is possible without any packaging tools, with documentation provided by Microsoft. Alternatively, tools such as InstallShield can automate the process.
4. MSIX bundles: .msixbundle installation ensures that only packages applicable to a device’s architecture are installed. An MSIX bundle targets different system architectures, language-specific assets, varying image-scale assets or resources applicable to specific devices.
5. Modification packages: MSIX supports the creation of modification packages intended to modify or extend existing packages. These allow customers to create customized configurations for your package or enclose a plug-in.
6. Shared package containers: When working closely with two separate packages, each with its own start menu and other entry points, a shared package container may be appropriate. This additional XML file may be installed on the end user’s computer to tell the OS that the packages should share a single container rather than be isolated from one another.
7. AppInstaller (XML) file: While MSIX and bundle files are generally directly installed into the operating system, the OS facilitates installation and management of updates automatically. Microsoft now makes this functionality available for packages delivered externally by using an AppInstaller XML file to perform the installation, telling the OS where to find the current msix file, where to look for updated AppInstaller files and the configuration of updated settings for the package.
8. MSIX core: MSIX Core is built for older Windows versions that don’t natively support MSIX. This enables installation of MSIX apps on previous versions of Windows (as long as the apps are built to work on those versions of Windows).
9. Basic AppXManifest structure: Last but not least, the most important file in an MSIX package is the AppXManifest file, an XML file that defines how the application will integrate with the OS for access by the end user, including the application model used that impacts runtime container features. Understanding the structure and element tags (package, properties, resources, dependency capabilities, applications/application element tags) of the AppXManifest early on will help ensure appropriate project setup.
While MSIX continues to evolve, so can your projects. The end results will be application packages that not only streamline work for IT departments but also reduce headaches for end users.
January 28, 2022
A Pandemic Side Effect: Rampant Technical Debt

On average, about a quarter of all IT budgets are allocated to handling technical debt each year. And this figure is set to rise, as 68% of organizations say their technical debt will increase in 2022. As digital acceleration continues to drive more IT investment across divisions, the technical burden almost seems like an inevitable outcome of delivering more software and amplifying end-user experiences.

Unsurprisingly, IT budgets are set to increase this year. This has been a stable trend throughout the pandemic as even companies that are not traditionally technical increased their reliance on software. Most teams quickly moved to remote working arrangements and acquired additional software tools to keep internal operations afloat. Not to mention the new complexities and array of tools emerging to support the microservices design paradigm.

Although new tech adoption is vital to enable key initiatives across a company, unbridled technical debt can also inhibit digital transformation initiatives. Software AG recently released its Situation Report 2022, a survey that analyzed the state of technical debt among IT professionals in 2021 and technology adoption forecasts for 2022. Below, I’ll review the key points from the report and consider how organizations can respond.

Increasing Reliance on Tech

The growth in this area is astounding—78% of companies say their technical debt rose in the last year. A full 38% of companies reported taking on a great deal more; at the same time, IT budgets are set to increase for most organizations in 2022. On average, this increase is expected to be 37.1% higher than 2021 spending. It’s easy to correlate increasing technical debt with these IT budget increases.

A large portion of this increased spending is related to digital transformation. This checks out; modernizing existing technology is a top priority for 19% of tech leaders. Other top priorities include exploring new technologies (17%) and decreasing technical debt (15%). Though managing technical debt is not ranked as the highest priority for IT leaders, it still ranks as a pressing concern due to its ability to hurt innovation. The report found that 69% of companies admitted it has caused their digital transformation initiatives to slow.

Perceptions of Technical Debt

So, what are the leading causes of technical debt? It turns out that most stems from recent modernization and digital transformation efforts. In fact, 39% said new digital products were a major cause. This is followed by infrastructure modernization (34%), data analysis and integration (32%) and new customer-facing services (27%).

Interestingly, not all technical debt is bad. Often, IT professionals say the benefits justify the expense. For example, 86% say that increasing product or service launches justifies taking on tech debt.

Technical debt is also a result of the remote nature of today’s hybrid work environment. During the pandemic, businesses made many concessions to enable remote work and adopted new collaboration and development tools to enable productivity. As a result, 88% reported the pandemic increased their awareness of technical debt. The majority, 83%, also said the pandemic has increased acceptance of technical debt, a sign that many of these changes are here to stay in the new normal of working life.

Responding to Technical Debt

Not all investments lead to the same degree of technical debt; some platforms are bulkier than others. Or, specific software vendor lock-in schemes can prevent lift-and-shift which can swell a technology ecosystem. So, what areas are companies investing in and which are the leading causes of technical debt?

In 2021, companies invested heavily in cloud computing (60%), integration (43%), IoT (39%) and 5G (39%). Investment strategies will change slightly in 2022, with 5G becoming the top most-invested area at 45%. Cloud computing drops to 42% and edge computing is rising to 35%. Mapping where new investments will occur can help organizations anticipate the repercussions. Of these investments, 60% of IT professionals ranked 5G as a leading cause of technical debt. Other high producers include cloud computing, IoT and blockchain.

In 2021, companies spent 24.8% of their IT budget handling technical debt. Managing it presents some significant challenges—32% say siloed data and processes are a key challenge when addressing technical debt. Limited budgets, regulations and a lack of internal alignment also get in the way. Clearly, resolving the issue requires both inter-department collaboration and a hefty budget.

Final Thoughts

Technical debt is, arguably, unavoidable as companies adopt cutting-edge technologies to remain relevant. And, taking on more technical debt is often intentional; for example, new DevOps tools are helping increase deployment fluidity and manage complex cloud-native architectures. Or, new SRE platforms bring observability and monitoring capabilities to improve application reliability. A newer programming language may be more performant, while a low-code abstraction layer complements an engineer’s workflow. In all these scenarios, the benefits often outweigh the added debt.

Yet, much of it is unintentional and is slowing innovation down. This could be shadow APIs or forgotten rotting legacy infrastructure. Sluggish code and un-optimized routing between applications can also be a drag on resources. The reason these situations sound murky is because technical debt, itself, is difficult to quantify. And, only those addressing it with adequate visibility into their stack will have a clear indication of how much debt there really is.

Though the current pandemic has indeed amplified technical debt, things will always evolve and new trends will replace the old. In the digital era, some degree of tech debt is inevitable within a large organization. The key will be effectively managing it over time to maintain a healthy, lean codebase and progressively release features that meet the demands of new customer experiences.

The Software AG Situation Report 2022 surveyed 700 IT professionals on their software usage and annual predictions at the end of 2021. For more insights, you can read the full report without an email gate or paywall here.

January 28, 2022
Site Reliability Engineering (SRE) Comes of Age in 2022

The site reliability engineer (SRE) role is still gathering steam across organizations. In January 2022, LinkedIn listed SRE as the 21st job with the highest global demand throughout the past five years. That’s pretty high for such a specific tech role. And, looking to the future, it appears the SRE practice will only continue to gain adoption as a method to support high availability, reliability and improved digital customer experiences. The SRE approach is also essential to meet service-level agreements (SLAs) and internal service-level objectives (SLOs).

I recently met with Kurt Anderson, SRE architect, and Emily Arnott, content writer from Blameless to get their take on the top trends and predictions for the SRE practice in 2022. According to the Blameless team, 2022 will likely see increased adoption of the SRE role throughout companies and across internal departments.

Just as manufacturing sets high standards for its quality assurance, digital applications now require the same high reliability to meet inflated user expectations. To address these new realities, SREs have their work cut out for them—they must confront how to unify disparate DevOps tools and must drill farther down to unearth specific user experience qualms—all without adding to alert fatigue.

Increasing SRE Adoption

As mentioned above, the SRE role has seen tremendous growth in recent years and doesn’t show signs of slowing. SRE as a practice was first popularized by Google in 2015. Today, they define it simply as “what happens when you ask a software engineer to solve an operational problem.” This equates to maintaining high levels of reliability for digital services by creating errors budgets, designing SLAs/SLOs and optimizing process automation over time.

To Arnott, we’re still seeing SRE adoption take off at an exponential rate as more and more companies embrace Google’s SRE doctrine. “During the pandemic, more and more companies were forced to adopt a digital strategy. Reliability has to be fundamental to that strategy.” Arnott foresees SRE becoming a fruitful role at startups, which may initially have been intimidated by the prospect.

“The practice of SRE is a scale issue,” Anderson explained. It can be difficult for time-pressed companies to enact an SRE program when their attention is already so divided. However, as new requirements force warp-speed innovation, we’re seeing greater DevOps adoption. And the SRE role, consequentially, is becoming more of an imperative.

More Unification of Multi-Tool Condition

Most DevOps professionals would agree—we live in a multi-tool world. For example, multi-cluster management concerns are bringing a plethora of new tools to the fold. And computing environments are just as diverse, often combining multiple clouds and composed of hybrid estates that house various clusters of microservices. Even within the same organizations, different teams may opt for differing DevOps tooling. Anderson believes that SREs can bring “more unification to a fractured DevOps adoption across a single company.”

As companies adopt more software, there’s inevitably some degree of tool sprawl, Anderson said. For example, there may be competing methods to monitor the use of digital services. The platform team may be using Datadog, an app team may be using New Relic and another team may be using Prometheus. These tools don’t speak the same language and generate different logs, creating silos.

For Arnott, the future involves accepting the innate complexity of the microservices era and using an agnostic layer that can receive data from anywhere to identify meaningful incidents.

Observability Gets a Bigger UX Emphasis

The SRE role is definitely a trend that has been growing and will continue to grow in importance, Anderson said. And as more organizations turn digital, it’s becoming necessary; with this shift comes enormous pressure to exceed user experience expectations. “Competition and people’s expectations are so high right now,” said Arnott. “If you are unreliable, it’s unacceptable these days.”

Whereas DevOps focuses more on getting applications into production, SRE takes a more UX-focused approach. Take Netflix, for example, which has invested heavily in a core SRE team that ensures robust and reliable user-facing services. “A key underpinning to keeping our customers happy and streaming is a strong focus on reliability,” according to the Netflix Technology Blog.

To cater to this new paradigm, teams will require a deeper understanding of observability based on particular cohorts of users, said Arnott. SREs require precise user experience contexts, such as an uptick of lags or increased error responses. But they also must discover the contributing factors behind these bugs. “SLOs and error budgets are like taking your temperature—they tell you if something is wrong. They don’t tell you why you have a fever.”

SRE Takes Cues From Manufacturing

As reliability becomes more and more central to a company’s brand presence, it’s only natural that something that important would be elevated into the executive suite, Anderson explained. As a reference example, he pointed to the fact that manufacturing industries often appoint a chief reliability officer. In traditional manufacturing, product lines undergo a statistical process control with rigorous testing to ensure quality. Analogous positions exist across industries, such as chief quality officers in financial services.

The takeaway is that as reliability becomes more of defining competitive metric, tech companies may require a similarly high-level C-suite position to align on that idea and to direct teams to implement SRE practices. Of course, the necessity for such a title will entirely depend on organizational size and makeup.

Greater Reliance on SLOs to Avoid Broken SLAs

A service-level agreement (SLA) is typically a formal contract built around the reliability of a digital service with an external partner, which, if breached, may result in financial penalties or other forms of restitution. This agreement could exist between a software provider and an end user but is more strictly enforced in a B2B context.

On the other hand, a service-level objective (SLO) is more of an internal target. SLOs are often set at a lower threshold than SLAs. For example, perhaps an SLA ensures a user login fails no more than 10 out of one million attempts, but the SLO is set at two out of one million.

Setting internal SLOs helps keep engineers abreast of modest customer experience issues before they become a major incident that results in fines. “Some companies treat SLOs as just another alert; they should be representative of user experience,” said Anderson. It makes sense that as SRE initiatives begin to mature, companies will slowly start to adopt even more competitive goals to deliver superior user experiences and avoid unsatisfied partners.

Final Thought: Don’t Play The Blame Game

A big part of the SRE doctrine is the concept of blameless postmortems. Because when you’re in the middle of an incident, the worst thing to do is point fingers. “Blaming triggers a defense mechanism and when you’re in a defensive mode, you can’t respond well,” said Anderson.

Instead, it’s better to keep an open mind when performing these retrospectives—accept that what occurred happened for a reason, and seek to discover that reason to make positive improvements. “What can we change at a systemic level to become more resilient?” inquires Arnott. “What is the origin of that mistake? What information was lacking? What communication should have happened to prevent this?”

Typically, accidents don’t occur intentionally or due to incompetence but rather due to holes in the process. By not playing the blame game, companies are better positioned to fix issues as they progressively release new features. Then, hopefully, with the right SRE approach in place, teams can advance their digital services to meet the high stakes of today’s modern user experience expectations.

January 25, 2022
Embracing Security by Design in Development

The number of data breaches publicly reported in 2021 far exceeded the total for 2020, making 2021 a record year. With cyberattacks on the rise and bad actors and ransomware gangs demanding millions in ransom, cybersecurity has taken on new urgency.

In addition to more sophisticated hacking techniques, the rapid pace of tech adoption during the pandemic is another contributing factor fueling cybersecurity risks. A recent survey by Forrester shows 74% of companies attribute recent cyberattacks to vulnerabilities in technology put in place during the pandemic. As companies raced to enable remote work, develop new applications and roll out new consumer-facing digital solutions, cybercriminals saw new opportunities to identify vulnerabilities and to attack.

Cybersecurity threats can affect every business regardless of size and every individual, regardless of who they are or where they live. Even the most protected and advanced organizations are at risk: One of the world’s biggest cybersecurity companies recently fell victim to one of the largest breaches in history. It’s time for all companies to rethink their approach to boosting security in the software development process.

As a nearshore development partner for businesses around the world, we have embraced a ‘security by design’ mindset to keep our clients’ builds secure. To put security first and ensure it remains at the forefront of every engagement, we adopted a parallel build systems process to improve the integrity of the code we deliver. This also reduced the overall threat of potential attacks. How did we do this? There are three key components to developing and implementing a security-by-design mindset.

Embedded Security Expertise

It is critical that security experts become official members of every software development team. These specialists are there every step of the way from design to delivery, finding and fixing security flaws along the development journey. Instead of being brought in at the end of the process, they are deciding on new solutions and implementing protections in real-time alongside experts in design, user experience and coding. Each plays a role and works as an integrated member of the team providing advice and suggestions during Agile cycles and sprints.

Predictive Analytics

A recent survey showed that 96% of third-party applications deployed in cloud infrastructure contain known vulnerabilities. That rising risk can make it possible for bad actors to infiltrate thousands of organizations. Threat hunting tools can spot, anticipate and predict vulnerabilities in software development. Tools can automatically scan code as it is written to vet and diagnose vulnerabilities. Our team scans code while in production and reports risks and vulnerabilities and then immediately consulting with the rest of the team to work on the next secure version.

Continuous Learning

Security is changing quickly, and it’s never been more critical to ensure developers have the skills necessary to defend and protect corporate infrastructure, applications and digital solutions. With the threat landscape constantly evolving, new skills and continuous learning are required to stay ahead of the latest threats and fraud techniques. Part of our training is focused on deploying white hats, or ethical hackers, to breach our development environments and the applications we deploy. These experts then set about identifying weaknesses and helping to improve security. They also take our training to the next level and push our experts to continually learn and educate themselves on the latest threats and solutions. By upgrading their skills, security practitioners can stay ahead of cybercriminals.

Every day, enterprises face thousands of attacks on their systems, and malware continues to grow in frequency, volume and complexity. These attacks are not just coming from criminals looking to make a buck; there are growing fears of nation-state attacks escalating. These are often seen as the more dangerous threats to businesses. The best defense against cyberthreats is a strong offense anchored by a security by design mindset.

January 24, 2022
Testlio Adds Fused Testing to Automate Testing Platform

Testlio announced today it is adding fused testing capability to its application testing platform; Testlio is used by IT organizations to manage application testing teams consisting of internal employees and external contractors vetted by Testlio.

Fused testing describes the combination of automated and manual testing IT organizations use to improve overall productivity. Fused testing strikes a balance between tests that can be automated and those that still need to be performed by a human.

To achieve that goal, Testlio has partnered with Applitools, BrowserStack, Headspin, Mabl and Sauce Labs. Failure signals and session artifacts from these tools can be pushed to the Testlio platform to streamline the triage of test results. Testlio is making six device slots and 100 hours per month of automated testing processing time available at no additional cost.

Finally, Testlio has set up an automated testing center of excellence (CoE) as part of an expansion of its professional consulting services it provides to help organizations implement testing best practices.

Testlio CEO Steve Semelsberger said those integrations will make it simpler to augment human testers and increase the rate at which applications can be tested as many organizations are accelerating the rate at which those applications are being built and deployed.

As organizations seek to implement continuous testing within the context of a DevOps workflow it’s apparent there will need to be more reliance on automation to keep pace with application development, he added.

Through its platform, Testlio provides organizations with access to more than 10,000 freelance application testers on demand. That network of testing professionals can create, run, optimize and diagnose automated tests using Appium and Selenium frameworks written in programming languages such as Python, Java and Node.js. Only 3% of the freelance application testers that apply to join the Testlio network have been accepted, noted Semelsberger.

The degree to which organizations prefer to rely on internal employees versus contractors to test applications will naturally vary. However, it’s difficult to predict what volume of tests will need to be performed—and when they should be performed—to preserve application development timetables. Contractors provide IT organizations with a degree of testing flexibility that is becoming an absolute requirement given the current challenges of hiring and retaining professional application testers, said Semelsberger.

Application testing is, of course, difficult to apply uniformly no matter how many testers are available. In addition to providing access to experienced freelance testers, Testlio also provides a platform for managing the overall testing process. The challenge is then aligning those testing tasks with the various application development projects the organization has launched.

Regardless of the approach to testing, the need for it has never been more critical. As organizations embrace a wide range of digital business transformation initiatives, a much higher percentage of the applications are now externally facing. The tolerance for suboptimal application experiences among customers and partners is much lower than that of internal employees. As such, first impressions, like it or not, are going to determine the success and failure of most of those application initiatives.

January 19, 2022
Innovation With Software Architectural Excellence

Software architecture plays an irreplaceable role in enabling businesses to deliver value efficiently. This is evident in how digital natives have been challenging incumbents and forcing them to rapidly digitize and transform how they operate and innovate. Accordingly, achieving architectural excellence is a continuous process of efficient implementation, advanced planning, and executive leadership engagement. Furthermore, it’s essential to recognize that software architectural strategies and planning shouldn’t be limited to IT. Enabling collaboration between IT and business leaders is necessary as software architecture plays a key role in delivering value, making processes robust, and tackling the next wave of changes in value creation and delivery.

The Goal of a Good Software Architecture

A good software architecture facilitates the ongoing business processes function robustly and ensures business capabilities are competitive against threatening challenges. Beyond this, the software architecture should also become the fundamental aspect of driving the next waves of business changes—whether they are processes, models, or innovative products and features. These changes result from competitive forces increasing digitization, transformation, and ecosystem-based consolidation, making change the overarching constant in various business aspects. Accordingly, conventionally viewing a software architecture at a limited software or product level doesn’t work as well as it used to. The practice of viewing software architecture at the business and ecosystem-level gains even more emphasis as digitization and innovation make businesses and ecosystems digitally intertwined in how they interact.

The following fundamental aspects describe how to innovate with architectural excellence:

Security and Privacy

Customers are increasingly becoming wary of how their data is handled and protected—and are even reluctant to do business if an organization doesn’t have clear policies on how it protects and handles customer data. On the other hand, regulators are constantly improving their compliance requirements to protect customers. This landscape is changing at different rates across multiple countries, posing challenges and equally creating opportunities for fast adapters. All of this implies that businesses need to ethically manage customer data along with protecting against the constantly evolving threat landscape. To satisfy this need, it is necessary to revise the existing software architecture and involve senior executives in making critical decisions in this respect. Moreover, architectural planning cycles should come down to a few months—instead of years. This is key to building and implementing innovative solutions rapidly to tackle changing regulatory landscape and customer expectations.

Satisfy User Needs

Since 2008, the smartphone has been changing customers’ experiences and expectations. Digital disruptors are continually challenging incumbents and threatening their survival. In this paradigm shift, businesses should understand their customers more deeply, quickly adapt their business models and introduce new products to fulfill customer needs. It requires architectural agility that offers the flexibility to innovate business models in shorter cycles and improve them faster with customer feedback. This also means keeping a long-term view towards software architecture planning and strategy development that enables seamless innovation and eliminates process and performance bottlenecks. In this view, software architecture improvements and decisions should align with business objectives and strengthen business capabilities, not just the number of implementations or technical solutions the IT has delivered.

Empower Developers

Today, more and more businesses need developers to help them digitize and transform. Accordingly, empowering developers is essential, and software architecture is the fundamental way to help them drive innovation and build critical business capabilities. Developer empowerment is usually measured in terms of developer velocity — it defines how enabled developers are to be agile and how well their talent is utilized. To improve developer velocity, provide them with a well-defined software architecture to focus on quality and consistent development. Also, the software architecture must have scope for customization so that developers can utilize it to its full potential.

While the above describes the overarching approach, the following sections detail the fundamental aspects of achieving innovation with architectural excellence.

Scalability

The software architecture should support scaling applications seamlessly on-demand to accommodate spikes in user growth and scale back to save operational costs. Accordingly, this approach requires deploying your application in the cloud while ensuring not just the underlying infrastructure but also the multiple components in your entire system scale without friction or intervention. High performance should accompany this to ensure customer satisfaction and deliver a superior experience. This means that your system should perform ideally at any scale at any time.

Portability

Can the system itself or components of it be deployed in any cloud platform—public, private or hybrid cloud? How much does it cost to move in terms of time, effort, and cost? In a world of hyperscale cloud providers and cutting-edge cloud services, a company’s IT ecosystem shouldn’t be locked into one platform or vendor but should utilize the best available services and technologies currently—that are also future-ready to improve performance and optimize overall costs.

Compliance

Businesses should develop a compliance framework that aligns people, processes and strategies with regulatory requirements to ensure compliance and avoid non-compliance risks. Also, the framework should be work-in-progress to accommodate upcoming changes from regulators across the board.

Maintainability

Similar to the source code of software components, software architecture should be easily maintainable—meaning that the software architecture shouldn’t introduce bottlenecks when modifying and improving it.

Maintainability issues could take many forms: is the software architecture outdated for the current technical and business landscape? Is it using legacy versions that are incompatible when other components and dependencies are updated? Ensuring the software architecture’s maintainability helps facilitate innovation and move at a competitive pace. If at all unsure where to start improving or redefining a software architecture, start with maintainability.

Cost

IT is often under constant scrutiny to justify its expenditure, and it is complicated to measure IT’s meaningful contribution to the business outcomes. As a result, IT constantly faces the risk of budget cuts and challenges in optimizing costs. Typically, the software architecture is let to grow organically, leading to duplication of system and efforts and inconsistent data across systems. To overcome this, control the software architecture on an ongoing basis, which, in turn, allows for more predictable cost-control.

In this fast-changing landscape of digital, businesses should maintain flexible architectures that facilitate innovation and continually improve the software architecture using agile methodologies to gain a competitive advantage in the business capabilities. This practice is much needed, especially when digital disruptors are increasingly threatening to take it all—leaving laggards behind.

January 17, 2022
CNCF Takes LitmusChaos Platform to the Incubation Level

The technical oversight committee (TOC) for the Cloud Native Computing Foundation (CNCF) announced today it is elevating the open source LitmusChaos application testing platform to the incubation level.

LitmusChaos is a chaos engineering platform donated to the CNCF by ChaosNative in 2020. Since then, it has seen adoption within production environments by more than 25 organizations, including Intuit, Lenskart, Orange, Red Hat and VMware.

ChaosNative CEO Uma Mukkara says LitmusChaos was developed to provide DevOps teams with a chaos engineering platform built using containers that makes it easier to scale up and down than existing monolithic alternatives. The platform itself, however, can be used to test both monolithic and microservices-based applications.

The platform consists of a Chaos Operator based on a software development kit (SDK); a ChaosHub for hosting and sharing experiments; Litmus Workflows that declaratively chains experiments (either in sequence or parallel) to build a chaos scenario; a centralized control plane, dubbed ChaosCenter, to design, schedule and monitor Litmus Workflows; Litmus Probes for creating chaos scenarios that automate steady-state validation and remediation actions and a Chaos Observability tool to export Prometheus metrics.

In total, there are now more than 400 contributors to the LitmusChaos project and more than 4,000 pull requests have been made. Mukkara said since the beginning of this year, Litmus operator installations have grown to more than 2,000 per day. Going forward, the goal for 2022 is to significantly increase the number of LitmusChaos integrations there are for a wider range of DevOps platforms, added Mukkara. Additional sets of experiments for Kubernetes and non-Kubernetes targets, improved observability and integration with other platforms—via the open source OpenTelemetry agent software also being advanced by the CNCF—is also planned.

In general, it’s still early days as far as the adoption of chaos engineering with DevOps workflows is concerned. However, Mukkara said that as more organizations embrace observability to better understand IT processes, the number of organizations that also use chaos engineering to test IT resiliency should also increase. In fact, as IT environments become more complex—thanks mainly to the rise of microservices-based applications—chaos engineering approaches to testing may someday be required, noted Mukkara.

In the meantime, there are still a lot of IT professionals that are uncomfortable with chaos engineering approaches to testing that deliberately break underlying services to test the resiliency of an application. The core idea, however, is that no application should have a single point of failure that could lead to it becoming unavailable. In theory, a microservices-based application won’t fail because when a service becomes unavailable calls are automatically rerouted to another service. The performance of that application will degrade, but it won’t go offline. The challenge is that building an application that achieves that level of resiliency using microservices requires a significant amount of DevOps expertise.

Regardless of how an application is constructed, the one thing that is clear is how dependent organizations are on applications to drive revenue. As such, the tolerance for application failures—or performance degradation—has never been lower.

January 11, 2022
Intel Expands Scope of OneAPI Toolkit Initiative

Intel has made available a 2022 edition of its oneAPI toolkit through which it makes processor extensions accessible to DevOps teams.

James Reinders, chief evangelist for Intel software products, said the goal is to make it simpler for DevOps teams to expose extensions to any company’s processors in the runtimes developers use.

At its core, the oneAPI toolkit is a collection of APIs that Intel created for x86, graphics processing units (GPUs), application-specific integrated chips (ASICs), field programmable gate arrays (FPGAs) and other classes of processors.

Reinders noted that developers have never had as much ready access to so many different processor classes before. The challenge organizations face, however, is making it simpler for developers to take advantage of those capabilities in a way that doesn’t require them to write low-level code, he added.

The oneAPI 2022 toolkit adds additional capabilities including the world’s first unified compiler implementing C++, SYCL and Fortran, data-parallel Python for CPUs and GPUs, advanced accelerator performance modeling and tuning and performance acceleration for artificial intelligence (AI) and ray tracing visualization workloads. Collectively, Intel said it has made 900 new and enhanced features available via the oneAPI toolkit in the last year, including deeper Microsoft Visual Studio Code integration, support for Microsoft Visual Studio 2022 and Microsoft WSL2 for Linux development on Windows.

As IT continues to evolve it will become more routine for developers to invoke heterogeneous classes of processors within the same application, said Reinders. Those capabilities will drive an explosion of software development innovation through the rest of the decade and beyond, he added.

Intel is especially focused on making it easier for developers to invoke inference engines that take advantage of processor extensions to run AI workloads, Reinders said. Going forward, most applications will take advantage of machine learning algorithms that run inference engines optimized by Intel via extensions to its processors. As those workloads are constructed, integrating AI models within DevOps workflows will become the next major challenge, noted Reinders.

It’s too early to say how simplified access to heterogeneous processors, also known as XPUs, might change the application development landscape. The one thing that is clear is IT organizations now have more options than ever. The issue now is finding a way to invoke all those capabilities in a way that doesn’t overwhelm developers. DevOps teams will play a key role in deciding which processors and associated extensions to make available to their development teams.

In the meantime, the battle for processor dominance will only intensify in the months ahead. DevOps teams will need to decide how comfortable they are using processors manufactured by a single company like Intel or whether they want to employ a mix of processors provided by multiple vendors. Regardless of what they decide, it appears APIs will play a critical role in making it easier to benefit from advances in processor technologies.

January 7, 2022
LogDNA Survey Surfaces Observability ROI Concerns

A Harris Poll of 200 senior engineering professionals suggests it may be a while before most DevOps teams are able to achieve true observability in their IT environments.

The survey was conducted on behalf of LogDNA, a provider of an observability platform, and found nearly three-quarters of respondents (74%) are struggling to achieve their observability goals despite investing hundreds of thousands of dollars. In fact, well over a third (38%) said they are already investing $300,000 annually on observability tools.

Despite those investments, less than half of respondents are very satisfied with their ability to use log data. Key areas of frustration include the challenges of collaboration with colleagues spanning multiple teams (67%), the fact that the tools are not easy to use (66%) and the routing of security events (58%).

Nevertheless, the bulk of survey respondents said they are optimistic about observability. A full 85% of participants said they believe true observability is possible.

LogDNA CEO Tucker Callaway said the core issue that many organizations fail to recognize is that observability is really a data literacy and management challenge. Organizations are collecting logs, metrics and traces from a wide range of tools and platforms without thinking through optimal data pipeline construction. The result is an aggregation of data that has not been normalized to simplify surfacing actionable intelligence, he said. In fact, many organizations quickly discover that all they’ve really accomplished is increase their data storage costs, said Callaway.

In the absence of that data normalization, Callaway noted it becomes exceedingly difficult for cross-functional teams to query all the data being collected within a repository.

At its core, observability promised to make it easier to identify IT issues before they cause a disruption. Observability in one form or another has always been a core tenet of any DevOps best practice. Initially, DevOps teams focused on continuous monitoring as the most effective way to proactively manage application environments. However, it can still take days, sometimes weeks, to discover the root cause of an issue. Observability platforms make it possible to correlate events in a way that makes it easier for analytics tools to identify anomalous behavior that might be indicative of the root cause of an IT issue.

In contrast, traditional IT monitoring focuses on predefined metrics to identify when a specific platform or application is performing within expectations. Observability platforms combine metrics, logs and traces—a specialized form of logging—to make it easier for IT professionals to interrogate data being generated by a wide range of DevOps tools and platforms.

Of course, the assumption is that DevOps teams actually know what queries to launch to determine what the root cause of an IT issue might be. In the longer term, machine learning algorithms should make it easier to identify anomalies within IT environments. In the meantime, however, achieving observability still requires a fair amount of DevOps expertise that is not always readily available.

Eventually, observability will become much more automated than it generally is today. As that transition occurs, IT teams should find the ROI of observability is steadily improving.

January 4, 2022