devopsy.kinsta.cloud

Category: Blogs

Higher Mobile App Stability Begets Higher User Ratings

In the competitive mobile market, application stability is imperative. Downtime leads to poor user experiences, which stunts growth and revenue. Apps that have poor stability suffer the consequences. In fact, new studies show that just a 1% lower stability ranking can lead to nearly a one-star drop in App Store ratings.

Bugsnag recently released its 2021 Application Stability Index (ASI) report, Characteristics of Leading Mobile Apps. The study took 260 top-performing mobile apps across industries and reviewed each’s stability and end-user satisfaction. The study found that apps with solid stability tend to rank much higher in the App Store and maintain increased user engagement. The report also demonstrated that developers are pivoting to weekly releases to quickly address bugs, progressing from the bi-weekly standard for software updates.

Below, I’ll review the specific details of the ASI and the report and consider how stability varies throughout industries. Hopefully, the results here will help other software teams benchmark their app’s performance and release cadence against top-performers within their sector.

Stability = User Satisfaction

When measuring uptime and availability, five nines, or 99.999% uptime, is the golden target for most teams. This report measured stability as the percentage of apps sessions that were crash-free. The median across market-leading apps was 99.80%.

What’s interesting is that apps with more nines in their stability score achieve markedly higher App Store ratings. Apps that scored less than 99.00% had a median rating of 4.15, whereas apps with 99.99% to 100% measured uptime had a median rating of 4.70. The distribution of ratings was extremely wide for low-performing apps, compared to higher average scores for higher stability.

What do these results say? Users expect uninterrupted sessions. Frequently occurring stability issues can damage the consumer’s opinion of an app, leading to dissatisfaction and harsh reviews. The more stable an app is, the better chance it has to drive consumer success.

Stability by Industry

The study also exposed stability differences between industries. B2B SaaS apps ranked relatively high, at 99.85%. This is likely because B2B software must meet service-level agreements (SLAs). Such services have fewer (yet more high-paying) customers to support, the report speculated. Mobile apps directly tied to the exchange of money, such as e-commerce (99.86%), travel and hospitality (99.90%) and financial and banking (99.85%) also ranked consistently high in stability.

Coming in second were mobile apps in the business-to-consumer (B2C) (99.82%), consumer goods (99.80%) and health and wellness (99.78%) categories. Though these areas require decent availability to remain viable, they may not need such stringent SLAs. In such scenarios, non-stop availability isn’t as directly tied to end revenue.

Lastly, apps with the worst stability were found in the mobile games (99.71%) and media and entertainment (99.65%) categories. Mobile gaming had the worst ratings of all industries; mean stability equated to over a full day of outage per year. Increased downtime in both categories is perhaps due to more problems with frequent media updates. These areas also tend to have a lower average revenue per user (ARPU), which may affect how teams value ongoing support.

Deployment Frequencies

According to the report, highly stable mobile apps tend to release at least once per week, replacing the bi-weekly norm for updates. Nearly all industries are pushing at least four releases per month, aside from consumer goods and travel and hospitality, at 2.5 and 4 respectively. E-commerce takes the cake with a mean of seven releases per month.

Nowadays, progressive delivery is made possible due to increased emphasis on CI/CD. Therefore, rapid deployment frequencies are the norm. Releasing new versions more quickly can help appease users with new features. It’s also helpful to quickly patch bugs and decrease mean time to recovery (MTTR) for major incidents.

Users Love Stable Apps

Throughout the pandemic, digital reliance soared—84% of consumers said applications were a lifeline to normality, found a recent AppDynamics report. In this climate, mobile applications are critical to delivering valuable interactions.

Yet, user expectations have evolved. Now, it’s readily apparent that stability directly impacts consumer confidence. The ASI findings behoove engineers to edge closer to the five-nines goal. The more nines you have, the better off you are.

“The results of our second ASI report highlight the need for better proactive error monitoring and stability management to help engineering teams build healthier apps that deliver superior customer experiences,” said James Smith, SVP of the Bugsnag Product Group at SmartBear.

It’s good to reiterate that this study examined a handful of leading apps from each industry. So, these scores shouldn’t be construed as inclusive of the entire app marketplace, only as benchmarks for the top mobile app performers.

July 23, 2021
CloudTruth Acquires Tuono to Advance Configuration Management

CloudTruth, a provider of a unified configuration management platform, today revealed it has acquired Tuono, a provider of a cloud secrets management platform, as part of an effort to make it simpler to secure infrastructure provisioned using code. Terms of the deal were not disclosed.

Greg Arnette, CloudTruth CEO, said misconfigurations are rife across cloud computing environments. IT organizations now need a self-documenting approach to managing configurations as the number of cloud services that organizations can employ continue to multiply. The CloudTruth platform will automatically keep track of all configuration changes made to an IT environment, Arnette said.

The rise of Kubernetes and microservices is making things even more challenging, introducing a range of additional opportunities to misconfigure cloud platforms and applications.

Fresh from raising $5.25 million in seed funding, Arnette said one of the least-appreciated aspects of the configuration challenge is how dependent organizations are on tribal knowledge that gets shared unevenly across DevOps teams. The lack of a centralized repository for managing configurations makes it challenging to onboard new members to those DevOps teams, he added, resulting in more opportunities for mistakes to be made.

Tuono adds a cloud-native secrets management platform that can be deployed across multiple cloud services. The goal is to provide a configuration management platform that functions as a metadata wrapper compatible with configuration tools such as Terraform or CloudFormation from Amazon Web Services (AWS). That approach reduces the cognitive load on DevOps teams that would otherwise have to remember how and why each service is configured the way it is, said Arnette.

Arnette added that an additional goal is to enable DevOps teams to put guardrails in place that reduce the opportunities for misconfiguration errors to be made while continuing to enable developers to build and deploy applications quickly. Each organization will need to decide where to strike a balance between those competing agendas, noted Arnette.

The challenge organizations are wrestling with today is just how vulnerable software supply chains are—as a series of cybersecurity attacks have made all too apparent. Organizations are adopting DevSecOps best practices to better secure those supply chains. However, the rate at which DevOps teams can come up to speed on security isn’t fast enough to secure applications that are about to be deployed. At the same time, there are potentially hundreds of applications deployed in cloud platforms with varying degrees of misconfigurations. Cybersecurity teams are now being asked to review how well those applications are configured as part of an effort to address the security of the entire software supply chain.

It’s not clear if a backlash against DevOps, in general, is in the making as cybersecurity teams review application development and deployment practices. There undoubtedly will have to be adjustments made to those processes, even as most organizations realize just how dependent they are on software. The issue is that deploying more insecure applications faster is, at the end of the day, counterproductive.

July 22, 2021
Programmability is Key to Agile Transformation

Enterprise agility has rapidly become one of the most crucial variables for a business’s long-term resiliency. With the COVID-19 pandemic, never-ending disruptions to the global supply chain and nearly every industry’s typical processes flipped upside down, there has never been a more important time to prioritize agility than now.

While the rewards of agility are high, organizations are struggling to implement key technologies and adhere to the methodologies that can get them there. In fact, the 14th Annual State of Agile Report notes that 59% of organizations are following agile principles, but only 4% of these organizations are getting the full benefit. But the ability to adapt quickly, seize new opportunities, and reduce costs is critical for survival in the ever-evolving and hypercompetitive digital age.

Agility is about adapting quickly to changes and increasing productivity. Importantly, agile methodologies are not agile themselves and therefore will not magically transform enterprises into agile organizations. Instead, the focus needs to be on practicing the correct principles to become truly agile. With this in mind, let’s look at how two of these critical principles—programmability and observability—can increase productivity and allow for innovation across the business.

Programmability

Programmability describes the capability of hardware and software to change and accept a new set of instructions that alter its behavior. Let’s look at each of these two forms.

One way programmability is used is to connect analog devices with software, for example, software-supported network routers. More recently, programmability has been extended to use networking to control the hardware involved and bridge with software systems. The rising popularity of infrastructure-as-a-service (IaaS) has increased the demand for programmability and brought concepts, such as infrastructure-as-code (IaC), into the realm of reality.

The other use of programmability is to extend existing software capabilities. The two most widely known examples of this are application programming interfaces (APIs) and software development kits (SDKs). Using both approaches, a developer can extend the default capabilities of an existing program. The rebirth of APIs as business APIs has significantly extended the introduction of programmability into application software systems. The approach is particularly popular with application service providers since it enables end users to extend and customize the core capabilities provided by a product or service.

Connecting Agility and Programmability

So how are these two concepts connected? Agility requires a foundation and the right kind of environment to provide optimal results. Programmability is an enabler for creating an adequate path for agility. An organization with highly programmable components increases the ability to automate repeatable tasks. Let’s look at two scenarios: a business use case and a technical use case.

Programmability in Business

When a purchase order (PO) arrives, the customer care representative must verify the organization’s ability to fulfill the request and then create an order in the back-end customer relationship management (CRM) system. Traditionally, this process has required a good deal of manual effort: first, extract the PO data; then verify the details using other systems or spreadsheets and, finally, type the data into the CRM system.

By contrast, consider a person working in a modern environment with high programmability. The PO can be received in an electronic format, such as JavaScript object notation (JSON), extensible markup language (XML) or electronic data interchange (EDI). Then it can be validated by connecting to other systems and reference data repositories, prompting the user to verify it and feed the data into the CRM system.

Programmability in a Technical Environment

In a typical technical use case, software developers will finish writing code; quality assurance (QA) engineers have to test the release; release engineers have to verify it and the DevSecOps team has to deploy the released artifacts. Similar to the business use case, this technical workflow has traditionally required extensive, tedious, manual work.

However, the process becomes significantly more streamlined when the development organization makes the environment programmable. In this case, once developers commit the code, the automation flow will kick in, exert the committed code, run through the life cycle stages and deploy it into production.

Through automation, which is enabled and extended by programmability, organizations can streamline their repeatable tasks and provide more time and space for users to work on essential or innovative tasks.

Now, let’s look at the implementation details of the two use cases.

Programmability in the Digital Supply Chain

In the business use case, the automation of a workflow, such as PO processing, is treated as part of a modern digital supply chain initiative. The systems, messaging and data involved in such a flow are linked together using integration technologies.

Integration approaches first involved point-to-point connections and then evolved to the use of centralized enterprise service buses (ESBs). More recent, modern approaches have centered around API-centric, integration microservices and integration platform-as-a-service (iPaaS) solutions that use decentralized models and cloud-native technologies.

Now, organizations build or acquire digital platforms by combining APIs, integration and security technologies to create digital supply chain flows. Critical to the success of any digital supply chain is the ability to select systems with built-in API capabilities and enable existing systems to expose applications and services as APIs and make the entire enterprise programmable.

Programmability in a Secured Software Supply Chain

In the technical use case discussed earlier, DevSecOps automation provides the foundation for automating various aspects of the software life cycle. Here, development tools, testing tools and governance-related tools are all connected using a pipeline.

IaC and automated build servers are two popular technologies used in automating such flow, which we call a secured software supply chain. Puppet, Chef and Ansible are widely adopted IaC scripting languages while Bamboo and Jenkins are popular build servers. However, as the DevOps space has evolved with cloud-native and decentralized technologies, GitHub and GitOps are also playing a vital role in building effective pipelines.

Similar to the business use case, the components involved here need to connect to the build pipeline, and therefore the programmability of each element involved plays a significant role in automating the workflow. Furthermore, in order to build a comprehensive pipeline, the code quality, unit test, automated test, infrastructure provisioning, artifact building, dependency management and deployment tools involved have to connect using APIs and extend the required capabilities using IaC.

Observability

By analyzing both the business and technical use cases, we have a clear idea about the impact of automation and how it is enabled by programmability. However, we have missed one important element: observability. Let’s examine this here.

The environment created by automation and programmability provides a good playground for teams to be practice being more agile, experiment with new ideas and take them to production rapidly. While agility increases, the responsibility of running healthy systems that provide a continuous digital experience is vital.

Observability helps detect and predict issues using analytics, machine learning (ML) and artificial intelligence (AI). Modern cloud infrastructure provides a certain level of observability at the operational level. Meanwhile, some modern programming languages, such as BallerinaLang, have built-in support for application-level observability associated with the specific language. When working with languages that lack this functionality, developers will have to either use a third-party tracing library that is compatible with the programming model or directly insert observability instructions along with tracing and debugging instructions.

Enterprises today are on a journey towards agility as they seek to optimize their digital strategies. However, organizational agility needs to catch up with project agility—and then, with each individual’s agility—to be more effective. This is the concept of “structured agility,” which is being fueled by “two-pizza teams” or self-organized teams.

APIs are the foundation of programmability, which makes it possible to connect analog and digital systems, as well as extend software systems. Programmability increases the speed of delivery, enables an enterprise to become “composable” with high reusability and allows a flexible environment by opening it up for innovation—the core principles of agility.

July 22, 2021
Could Full-Stack Observability Help Lessen IT’s Burden?

The year 2020 was a landmark year for many reasons, other than the obvious. The IT world saw the first time that cloud service revenues dwarfed spending on data centers. Across the board, budgets have been increasing around cloud adoption. And in this ‘new normal,’ digital experiences are slated to remain just as crucial of a touchpoint as ever. In fact, new findings show that for 85% of users, digital applications are absolutely essential to their daily lives.

Rising digital demands mean reliance on the cloud is here to stay. But if organizations don’t right-size their cloud workloads, expenses could get out of control. Plus, maintaining world-class user experiences requires a keen insight into the overall performance of apps, systems and solutions. If teams aren’t continually monitoring application performance and business KPIs, the bottom line could suffer.

I recently met with Joe Byrne, AppDynamics Regional CTO, to discover what full-stack observability (FSO) means for today’s cloud-heavy applications. According to Byrne, DevOps and SRE teams should be maintaining a holistic view of the entire pulse of the application—including non-functional metrics (NFM) alongside traditional security and functional monitoring. Doing so could reduce time spent on root cause analysis and help ensure code is continually meeting business objectives.

What is Full-Stack Observability (FSO)?

In the classic definition, observability focuses on measuring the internal status of a system based on external outputs. Application performance monitoring (APM) typically tracks telemetry around logs, metrics and dependencies. IBM, for example, calls the observability trend “a natural evolution of APM data collection methods.”

Full-stack observability (FSO), said Byrne, takes this one step further to track business-related key performance indicators (KPIs) alongside additional, more traditional software metrics. “FSO helps understand that software is performing optimally and that it is meeting business objectives,” said Byrne. In this way, FSO takes a holistic view to determine not only if an application is functionally sound but if it’s meeting its end goals.

FSO would consider critical performance actions, such as user experience telemetry. For example, Byrne explains, an e-commerce website could find value in tracking performance levels such as login time, check out time and payment initiation. Tracking such metrics is necessary to pinpoint roadblocks and create actionable steps to remediate holes in the user journey, said Byrne. Increased visibility here could also help engineers quickly respond to issues to better optimize the user experience. In addition, aggregating information at a higher level—to view total products sold per day or total revenue per day, for instance—could inform overall progress.

How FSO Could Reduce IT Stress

“We’ve reached a point where people have moved away from brick and mortar and are going online,” said Byrne. These online spaces are more omnipresent — and valuable — than ever. The AppDynamics 2021 App Attention Index found that the average digital consumer uses 42 applications daily. Furthermore, 85% of people now say digital services are a critical part of how they get by in life.

Mounting digital reliance has resulted in rising digital complexity. Therefore, said Byrne, companies have been moving to the cloud for the ease of scalability, elasticity and the capability of cloud functions. Cloud-native abilities like serverless, Kubernetes, identity and access management (IAM) and other add-on services are helpful perks to avoid reinventing the wheel.

But of course, lifting and shifting all your current architecture to the cloud is costly; plus, it won’t necessarily eliminate application bugs. The user journey is increasingly vast, and broken touchpoints along the way could hinder performance. This is complicated by increasing third-party dependencies. Yet, more often than not, it is the application’s custom code that is having the issue, explained Byrne.

Perhaps the most significant benefit of full-stack observability is a reduction of remediation time. “If you don’t have perspective, it can take a long time to run down an issue,” said Byrne. “The cost of finding a root cause can be so expensive.” Having a quick window into network, application and infrastructure hiccups is necessary to quickly address issues and save potentially lost revenue.

Shifting Performance Monitoring Left

An Amazon study found that every 100ms of latency costs companies a 1% loss in sales. Knowing the reality of high user expectations, software companies must be especially proactive in how they scale to meet the needs of consumers. As 72% of users believe application problems are the brand’s responsibility, the onus is on companies to avoid negative brand reputation.

To spot performance hangups early on, Byrne encourages a shift-left attitude toward observability around business outcomes. To date, the shift-left mantra has focused more on code validation and security—necessary elements to rapidly deploy software updates. Now, adding performance testing could be the next iteration to further correlate each software push with end business outcomes.

“You want to see and validate as much as possible before production,” said Byrne. “Performance testing is a key piece in the overall success of an application.”

This could involve testing the load time for a specific endpoint—if a key action doesn’t meet a certain threshold, then it would not be promoted. Incorporating performance monitoring within a CI/CD process is a burgeoning practice also referred to as BizDevSecOps.

There’s No Going Back

The new normal is upon us, and it’s hard to imagine going back to any semblance of a world where there’s a decreased reliance on technology. From airline bookings to banking and grocery orders—software applications are now intrinsic to nearly every facet of modern life. To compete in such an economy, finely-tuned modular customer experiences that continually optimize business outcomes will truly set companies apart from the rest.

In short, to maintain high software standards, it’s essential to break down operational silos and work together as a team—the DevOps creed. End-to-end ecosystem visibility could help enable that, ensuring, in Byrne’s words, that “applications perform in a way that meets the needs of the business.”

July 22, 2021
Meetings and Beatings

July 22, 2021
How ESM Enables Digital Transformation

The pandemic has forced organizations of all sizes to overcome colossal challenges and embrace flux. We’ve all heard stories about businesses having to adopt a new communication tool and train staff overnight, but that’s just the tip of the iceberg.

Many companies are in the middle of fundamental transformation, enabling enterprises to create more business value quickly. Still, digital shifts can also highlight stumbling blocks—such as inefficient management of people, tools and processes.

As modern business needs grow increasingly complex and require teams to do more with less, C-suite executives have learned that real value lies in customizable systems built for scalability, automation and collaboration. In the same way, companies have embraced DevOps to break down silos between development and operations teams, modern businesses are adopting enterprise service management (ESM) principles to create shared responsibility and opportunity across departments.

This approach has helped businesses view their digital transformation plans in a new light. Forward-thinking leaders are using ESM to enable a DevOps mindset, to centralize knowledge and ensure efficient digital service delivery within their organizations over the last twelve months.

The Business Benefits of ESM

ESM includes the tools and processes that enable an organization to manage the entire life cycle of IT (or other business units’) services. At an organizational level, it can be considered analogous to service-oriented architecture rather than an application architecture level.

Within larger organizations, multiple teams are often doing similar things to support different parts of the business. Keeping track of requests, prioritizing them and ensuring the right resources are available can be challenging. With ESM, companies can consolidate their resources and provide a consistent way for the organization to consume them. Akin to microservices, employees can easily access shared company services through a uniform interface, streamlining resources management.

The approach encourages enterprise leaders to see everything the company does as an integral service to the entire business. So, rather than an accounting team merely existing to process purchase orders and take care of payroll, it becomes a service provider. For example, they might create a portal that provides templated service requests for everyday tasks, such as raising a purchase order or understanding if a payment has been received, and a mechanism for capturing ad-hoc work that isn’t otherwise defined.

The real benefit of this approach is work management. A ticket is raised, and the department dealing with it can have a rotation of people, with whoever is least busy picking up the service request, assessing and resolving it or assigning it to someone else. That’s one reason it’s hardly a surprise that 87% of companies surveyed in 2019 said that they had already incorporated ESM in some way.

Practices, Not Processes, to Optimize Digitization

However, with businesses forced to undergo historic digital transformations over the last year, ESM has become even more valuable for organizations. The pandemic has shifted work management to a 100% digital initiative as teams were distributed remotely. A well-executed ESM strategy has enabled enterprises to take their digital-first workflows to a higher level, driving more value from employees and enabling organizations to scale service delivery and create unrivaled customer experiences.

ESM requires businesses to understand that there is no one-size-fits-all approach to service delivery and encourages them to replace their process-orientated mindset with an approach that focuses on value delivered through practices. These practices, which are built on user interaction and feedback, support agile organizations by helping them accelerate change and make services more available and reliable for customers.

Furthermore, these practices put users’ pain points and needs front and center to ensure continuous improvement. Through frequent evaluation, enterprises can address the things that matter the most to staff and customers. While this might seem like a basic practice for any company’s digital transformation plans, the truth is in many cases, we’ve found the practice to be widely neglected. A recent report from Eagle Hill Consulting found that one-third of U.S. employees say their company’s technology either doesn’t help or makes it more challenging to serve internal and external customers.

Digitization driven by these ESM principles can enable businesses to improve operational efficiency, reduce cost and risk, and plan strategically to support their evolving needs. All of these are, of course, what every organization had in mind as goals when the COVID-19 pandemic forced them to rethink how they do business.

ESM Automation and Cross-Departmental Visibility

At a high level, ESM sets out to bring all internal services into one place where every employee can easily find what they’re looking for in an instant. Accessing everything in one place also opens the door to leveraging automation. The option for automation means that some previously manual tasks – like providing access to systems – can be automated, speeding up wait times for staff or external customers and ensuring scarce resources, like your best people, are used more efficiently.

Moreover, common, consistent and shared platforms for all with a single access method gives individual departments enhanced visibility and control throughout the entire organization. Historical silos hampered individual business units’ visibility and understanding of the functions their business provides or how they’re processed. A unified portal where all departments can access resources and receive requests, in the same way, solves that.

Of course, this isn’t to take away from the inevitable learning curve that comes with digital transformations, especially at the size, scope and scale currently being undertaken. But the turnaround time from disconnected, slow, siloed teams to visible, open, speedy services far outweighs the effort required. In fact, recent research from Digital.ai uncovered just how badly visibility problems and poor internal alignment plagued businesses, with 56% admitting they’re worried that they’ll fail to achieve any return on investment from their stagnant digital transformation initiatives.

On the other hand, industries like finance, which have upscaled self-service and automation significantly in recent years, have built entirely new business models with collaborative technologies, accelerated innovation cycles, and have learned to make better, faster decisions.

These companies all embraced technology to empower their employees to help customers get the most from their service. In doing so, they are better able to deliver the best business value, which is core to a DevOps mindset and is achievable with successful ESM strategies.

July 21, 2021
Swinging the Pendulum of IT Back to QA

I was reading Nuria Manuel’s excellent article about quality assurance (QA), and it got me thinking about the wide variety of ‘pendulums’ that impact IT. I call them pendulums because they follow the rule of “every action has an equal and opposite reaction,” and they work on fundamental truths of IT. For example, the one that has probably been going on the longest is centralization/decentralization of IT and its assets. No sooner is everything consolidated and cost savings realized than adaptability concerns and needs of individual business units start the process of decentralization. Then, once decentralization is realized, everyone is painfully aware of the chaos that fifteen miniature IT departments, each going their own way, can cause … and centralization begins again.

Quality assurance is another such pendulum. Much like soldiers in peacetime, most people don’t recognize the value of QA efforts when things are going well. And when they’re not going well, then it is considered a QA failure—assuming there is a true QA function. Otherwise, it becomes the impetus to launch a formalized QA function … until things are going well and budgets are tight. The problem with QA is that for years, timelines, budgets and Agile management styles have all conspired to swing that pendulum away from a formal QA function. Oh, companies pay the price, but they quite often don’t see it as a cry for a valid QA function, and just treat this particular issue as a one-off that they should make sure doesn’t happen again. Unfortunately, issues in production have become both commonplace and accepted because of this. The only issues in production that seem to actually generate angst are ones that keep users from accessing the product. Anything short of that and workarounds or delayed fixes are seen as okay.

But the apps you are rush-building today will still be around in 10 years—or, at least, some of them will. Some of them won’t for a variety of reasons–including quality issues. Those that are around in 10 years are going to have to be maintained. QA now can save you over the years, so why all the resistance to it? QA might delay the release of new app. It is understandable that delays are to be avoided if possible, but so are bugs, so maybe constraining how long QA can delay the release and building that number right into the schedule would be a decent compromise.

That way, QA is looking at the most important/used parts of the app, but not getting buried in the weeds (where there might be bugs, but the ROI for addressing them probably isn’t there). The app will be delivered on time because QA’s time was built into the schedule. This does require that we not allow the traditional and abhorrent practice of shortening the QA window to make up for developers not meeting deadlines. Let us be very clear about this: when developers are rushed because they missed deadlines, that is precisely the time that you want QA to look very closely at their code before release. The last thing you should do is less testing in this scenario. The absolute last thing.

This is completely doable in your environment. The only really difficult part is holding the line on QA. Business owners are going to want to meet their original timeline, but cutting any phase of testing to get there is just a bad idea, so the struggle will be to hold the line. And figure out why devs missed the deadline in the first place so that the issue can be avoided for the next project.

You all are rocking it. Make sure all that sweet code-and-deploy work is not undermined by quality issues! Go ahead, implement a QA policy and make it an actual policy. Keep rocking it, get accolades from the rest of us. Maybe even from your employer. Maybe. But definitely from us. Because you’re killing it, month after month.

July 21, 2021
Puppet Survey Suggests DevOps Adoption is Stagnant

Puppet today published an annual State of DevOps report that suggests overall adoption of DevOps practices has stagnated.

The survey of 2,650 IT, development and information security professionals finds 83% are implementing DevOps practices, to a degree. However, only 18% of respondents are working for organizations that have highly evolved, automated DevOps processes in place. More than three-quarters of respondents (78%) are somewhere along the path toward achieving that goal.

A full 90% of highly evolved DevOps teams have automated most repetitive tasks compared to only 67% of mid-level organizations, the survey found. In addition, 91% of highly evolved teams report a clear understanding of their responsibilities.

Not surprisingly, the biggest hurdles identified are more cultural than technical. The most common culture blockers at mid-level organizations include a culture that discourages risk (21%), unclear responsibilities (20%), deprioritizing fast flow optimization (18%) and insufficient feedback loops (17%). In contrast, less than 2% of highly evolved organizations report resistance to DevOps from the executive level, the Puppet report found.

Nigel Kersten, a field CTO at Puppet, said during an online panel that, after more than a decade of DevOps advocacy, people continue to be the biggest limiting factor when it comes to adoption. Specifically, from a compensation perspective, many IT operations personnel tend to feel undervalued compared to developers, noted Kersten.

Another challenge enterprises encounter is trying to balance the need to create a standardized IT environment that can be managed and secured consistently and the desire of DevOps teams to embrace new tools as they see fit. Senior IT executives often tend to make platform decisions based on cost criteria that don’t always account for the need to enable agile development methodologies. Most of those platforms are designed to be managed by an IT administrator using a graphical tool rather than via a command line interface (CLI) and application programming interfaces (APIs) that appeal to DevOps teams.

As a result, individual pockets of DevOps teams that select and maintain a platform of their choosing are emerging within enterprise IT organizations. Those teams often view their chosen platform as a better alternative for advancing developer productivity. Finding and retaining site reliability engineers (SREs), for example, to manage those DevOps platforms is a major challenge for most enterprise IT organizations. Most IT administrators lack the programming skills needed to become an SRE, and it’s not clear how many IT administers are inclined to acquire those skills.

Conversely, it’s not clear how many programmers want to programmatically manage IT infrastructure at the expense of time they would otherwise devote to writing code. Organizations that can only hire a limited number of developers may not want to shift responsibility for managing IT operations to the proverbial left simply because they need more code to be written faster. Finding and retaining developers, in many cases, is just as much a challenge as hiring and retaining SREs.

Advances in automation and artificial intelligence (AI) should make it easier for organizations to embrace DevOps best practices in the months and years ahead. However, it should be apparent to all that adoption of those best practices across an entire enterprise still requires a significant amount of time and effort, and will for many years to come.

July 20, 2021
Cycloid Brings Open DevOps Framework to the US and UK

Cycloid, a Paris, France-based provider of an open framework for implementing DevOps best practices, today announced it is expanding its operations into the U.S. and United Kingdom.

Benjamin Brial, founder of Cycloid, said the Cycloid framework provides a lightweight approach to striking a balance between enabling developers to employ the tools they prefer and the need for centralized governance. The framework allows roles and policies to be pre-defined to ensure governance while service catalogs are used to deploy software using a set of drag-and-drop visual interfaces. There are also a set of management tools and features that provide additional visibility, automation, monitoring and financial controls to DevOps workflows.

In effect, the portal that Cycloid provides to manage those workflows also serves to make DevOps more accessible to a wider range of IT professionals, added Brial.

Many organizations that embrace DevOps wind up building their own custom portal to achieve that same functionality. Rather than devoting resources to building and maintaining such a portal, Brial said Cycloid maintains and updates a portal platform that can be employed across any combination of tools that developers prefer. Other DevOps frameworks are often rejected because they require developers to adopt a specific set of tools, noted Brial. Without support from developers, it becomes nearly impossible to adopt DevOps best practices at scale, he added.

After more than a decade of advocacy, adoption of DevOps within most organizations remains spotty. A significant factor in the lack of adoption is cultural issues involving skillsets. Many IT administrators lack the programming skills required to programmatically manage DevOps workflows. Cycloid is trying to establish a middle ground that enables IT operations teams to manage and govern DevOps workflows without having to acquire programming skills. The goal is to make it simpler for developers and IT operations teams to collaborate, said Brial.

It’s not clear to what degree such an approach might increase adoption of DevOps best practices within enterprise IT organizations. However, it’s already apparent that the cost of hiring and retaining, for example, a small army of site reliability engineers (SREs) to manage IT environments at scale is often cost-prohibitive for many organizations.

There’s no shortage of DevOps frameworks, but most organizations generally wind up crafting their own as part of an effort to tailor a DevOps workflow to meet their specific requirements. However, if there is a readily available framework that is highly customizable, Cycloid is betting more organizations would rather buy than build and maintain the entire framework themselves. Otherwise, DevOps teams would spend half their time performing the same repetitive manual tasks over and over, said Brial.

One way or another, DevOps as a methodology for building and deploying applications needs to become more accessible. Proponents of DevOps have made a case for the methodology for the better part of a decade, with mixed success. The challenge continues to be finding a way to scale DevOps processes across the entire enterprise versus allowing each individual development team to define application development and deployment processes that, today, vary widely in terms of efficiency.

July 20, 2021
3 Reasons Your Digital Transformation Stalled

The more a company modernizes, the more value it gets from the cloud, but not all digital transformation efforts are created—and executed—equally. According to Gartner, “87% of senior business leaders say digitalization is a company priority, yet only 40% of organizations have brought digital initiatives to scale … [and] without a shared vision across the organization, digital transformation efforts will continue to stall.”

CIOs and other senior technology leaders are constantly looking for the best way to lead and scale modernization efforts that positively impact the business and generate the most value from the cloud. Here are three factors to consider to make sure digital transformation efforts don’t start to slow or stall out entirely.

The Price of Ignoring Technical Debt

Any CIO should be able to say how much of their development efforts are invested in innovation and how much is going into maintenance. A harder number to take into account is how much their innovation development effort is slowed down by technical debt.

A good way to gauge this for CIOs—if you can say that your development organization dedicates more than 50% of its effort to innovation and that your development velocity is exactly where it was a couple of years back, then technical debt is not dragging you down. However, chances are that’s not the case.

Why is that? A major reason is that the vast majority of business applications and business logic still reside on-premises in legacy applications and infrastructure with a once-solid software architecture that is now showing signs of wear.

The technical debt these applications accumulated takes a toll. It is a ‘tax’ that many CIOs know they need to pay; know what is required, but choose to ignore until it’s too late.

Many organizations delay modernization because they believe that it reduces the capacity for effort that can be spent on innovation, assuming that legacy maintenance can just carry on as usual. With the potential for a lengthy and risky modernization project, delaying innovation for that length of time is not even an option. The only way to stop ignoring technical debt is to find a way to reduce the risk of modernization and accelerate the modernization project so you can go back to doing what you love about tech: innovating.

Managing App Modernization as a Tactical Project

It’s amazing that application modernization is so often viewed as a tactical project—time- and materials-based, cost-focused—versus a strategic imperative driven by business goals. This approach also explains why many projects fail to meet expectations, are half-finished or abandoned or never even get started in the first place.

The business logic and processes embedded in your legacy application estate are your core intellectual property and competitive advantage, and they need to be treated as such. These applications, and the business processes they encapsulate, require a strategy that continually modernizes them, starting now and continuing into the future. A one-and-done approach is a recipe for disaster and disappointment.

So be strategic, make sure your modernization plan is aimed at reducing technical debt, restoring velocity and focusing on innovation. Once you get there, make sure you continuously manage your technical debt and keep your velocity high.

Reliance on Lift and Shift for Cloud Migrations

Cloud migration projects are most often critical parts of digital transformation initiatives, and yet, many outside advisors or quick-win focused insiders will push for the “easiest” approach.

A rational plan to transform and modernize your applications for the cloud requires a critical assessment of your application estate to determine which applications should be refactored, lifted and shifted (rehosted or platformed), rewritten or just retired. Skipping this critical step and categorizing the majority of your apps into the “lift and shift” category is a common mistake that too many enterprises later regret. A lift and shift strategy may be fine for a subset of your applications, but for the most important ones it will result in a transfer of your technical debt to the cloud, increase your maintenance costs and take another bite out of your organization’s ability to innovate.

Digital transformations are getting bogged down by technical debt, tactical decisions and modernization shortcuts. Organizations need to directly address these issues and reduce the significant drag they are incurring on modern transformation initiatives. By attacking them head-on, enterprises can accelerate their cloud migrations, application modernizations and business agility goals.

July 20, 2021