devopsy.kinsta.cloud

Category: DevOps

Survey Predicts Massive Migration to the Cloud

A global survey of 1,600 enterprise IT decision-makers found more than half are working for organizations that plan to eliminate the use of data centers over the next two years.

The survey was conducted by Aryaka, a provider of a secure access service edge (SASE) platform, and found a quarter of the respondents have closed 25% to 50% of their office sites; 75% of respondents said at least a quarter of their employees will remain remote permanently post-pandemic. Just under a third (32%) expect at least half of their workforce would be permanently remote.

Despite the apparent accelerated shift to the cloud, the report found a full three-quarters of respondents (75%) are projecting at least a 10% growth in IT spending, with a quarter expecting IT budgets to grow 25% or more. Nevertheless, more than a third (36%) report they have IT cost concerns.

David Ginsburg, vice president of product and solutions for Aryaka, said the shift to the cloud in the wake of the COVID-19 pandemic is being driven mainly by digital business transformation initiatives that require applications be quickly built and managed by IT teams that are working from home themselves. With the pandemic entering the third year, a hybrid workforce that regularly shifts between home and the office is now permanent, he noted.

Consequently, with more people working from home, nearly two-thirds of respondents (64%) said they will shift toward a SASE-based approach over the course of the coming year to provide secure access to cloud applications over a software-defined wide area network (SD-WAN). Over two-thirds of those respondents said they will opt for a managed SASE offering rather than build and maintain these platforms themselves.

SASE was originally coined by Gartner to describe a cloud-delivered service that brought together networking and security offerings. Those offerings should include a firewall-as-a-service (FWaaS), secure web gateway (SWG), cloud access security broker (CASB) and zero-trust network access (ZTNA). In effect, it’s a secure software-defined wide-area network (SD-WAN). As organizations adopt SASE-based platforms and services, just under a third of respondents (61%) are recognizing that dynamic bandwidth reallocation will be a very important requirement as workers shift between the office and home.

The transition to SASE involves setting a strategy (35%), phasing out of legacy virtual private networks (32%) and consolidating cloud security with zero-trust (29%). Top desired capabilities include SWG (47%), SD-WAN (36%) and FWaaS (28%). A full 41% reported that responsibility for networking and security decisions have now been consolidated into a single team. However, only slightly more than a third (34%) said security is a major priority.

The implications of a shift to the cloud at this rate and level of scale are likely to have a profound impact on DevOps teams. While cloud infrastructure is designed to scale on demand, accessing applications across an SD-WAN can have a significant impact on application performance. The survey, however, finds only 29% of respondents are concerned about whether applications will perform properly. Nevertheless, well over two-thirds (69%) said there will be an increased focus on observability and control, while 42% noted identifying slow performance for remote and mobile users will be a key issue and 37% expected slow performance at the branch office to also be an issue. Lackluster application performance is a time sink, according to 42% of respondents.

Naturally, many IT teams will add new tools and platforms to deploy and manage cloud applications. The Aryaka survey found that only slightly more than a quarter of respondents are concerned about the newness of the technology they might employ.

The coming year is shaping up to be incredibly disruptive to the IT landscape. The challenge is making sure balance is maintained between cost, flexibility and application performance.

January 20, 2022
Harness CD Platform Now Available via Source-Available License

Harness today announced a free community edition of its continuous delivery (CD) platform is now available under a source-available license rather than a more traditional open source license.

Scott Sanchez, chief marketing officer for Harness, said the goal is to make CD as accessible to developers and DevOps teams as their current CI platform. Harness already makes an open source edition of its continuous integration (CI) platform available.

The Harness CD platform is available under a Polyform Shield license that provides free access to the platform, including the right to use, modify and distribute it but not launch a competitive offering. A source-available license is an alternative to an open source license that allows an organization to potentially create a fork of the Harness CD that could, for example, be delivered as a cloud service. That specific issue has led to scenarios where vendors that create an open source project find themselves competing for revenue against a cloud service provider that is not necessarily as committed to contributing and maintaining the primary open source project. At this juncture, it’s not clear how many other vendors that make software available under an open source license might take a similar tack.

While most organizations that embraced DevOps have been able to successfully implement a set of CI best practices, the number of organizations that have implemented CD is not nearly as high. One reason for that is automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”

However, as the number of digital business transformation initiatives continues to steadily increase, the need to regularly update application experiences is going to require more organizations to implement a set of CD best practices. A source-available license should help increase the number of DevOps teams that can access and experiment with a CD platform, noted Sanchez. The challenge, of course, is that many of those applications are now based on microservices with components widely distributed across an IT environment.

Historically, CI and CD have been synonymous when viewed within the context of a CI/CD platform. It’s not clear to what degree DevOps teams will look to better leverage the CI/CD platforms they already have in place rather than deploying a dedicated CD platform for IT operations teams and letting developers choose whatever CI platform they prefer. In general, a recent survey conducted by the Continuous Delivery Foundation found that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree.

Regardless of approach, the coming year is shaping up to be one where many more organizations take DevOps initiatives to the next level. Arguably, as more organizations realize how dependent they are on software to differentiate themselves from rivals, the ability to deliver new application experiences has become critical. At the core of those efforts is a set of DevOps best practices that will ultimately determine just how competitive those organizations will be.

January 19, 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
White House Meeting Puts Spotlight on OSS Sustainability

A recent meeting between IT industry leaders and White House officials highlighted open source software sustainability concerns as high-profile breaches and zero-day attacks have many organizations reviewing their software supply chains.

The White House published a statement describing, among other things, how participants had a “substantive and constructive” discussion on how to make a difference in the security of open source software while continuing to effectively engage and support the open source community.

Meeting participants included Deputy National Security Advisor for Cyber and Emerging Technology Anne Neuberger, National Cyber Director Chris Inglis, and officials from the Office of the National Cyber Director, Office of Science and Technology Policy, the Department of Defense, the Department of Commerce, the Department of Energy, the Department of Homeland Security, the Cybersecurity and Infrastructure Security Agency (CISA), the National Institute of Standards and Technology and the National Science Foundation. Akamai, Amazon, Apache Software Foundation, Apple, Cloudflare, Facebook/Meta, GitHub, Google, IBM, the Linux Foundation, the Open Source Security Foundation, Microsoft, Oracle, Red Hat and VMware all sent representatives.

The White House reported that the discussion focused on preventing security defects and vulnerabilities in code and open source packages, improving the process for finding defects and fixing them and shortening the response time for distributing and implementing fixes.

There were few specific recommendations, but the White House is clearly bringing more pressure to bear after the disclosure of the zero-day Log4j vulnerability in Java applications wreaked havoc in enterprise IT environments and government agencies. That vulnerability made it clear just how dependent organizations are on open source software projects and brought to attention the fact that many are created and maintained by just a handful of volunteer maintainers and contributors. The individuals that created those projects don’t always have a lot of cybersecurity expertise. In fact, many of them would argue that the onus for securing open source software is on the organizations that use what amounts to free software. It’s not the responsibility of the contributors and maintainers of open source software to drop everything and create a patch on-demand to address a zero-day vulnerability.

The federal government, however, has made it clear via executive order that it expects IT vendors and large enterprises that depend on open source software to do more to secure it. In the meantime, IT teams will need to evaluate their dependence on open source software; especially if, from a security perspective, that software isn’t sustainable simply because there are not enough contributors with the necessary expertise.

Naturally, this is a complex issue. In many cases, organizations are relying on open source components without even realizing it. Those components have been embedded within an application by an independent software vendor (ISV) that typically doesn’t disclose how that application was constructed. When a zero-day vulnerability is disclosed, cybersecurity teams can spend weeks looking for all the ways the instances of an application they either built themselves or licensed are impacted.

“There’s no way to really know,” said Mitch Ashley, principal for Techstrong Research, an arm of Techstrong Group, the parent company that publishes devopsy.kinsta.cloud. “A vulnerability can be anywhere.”

It’s not abundantly clear how critical an issue the sustainability of open source software security is just yet. Relative to the amount of open source software currently employed, the number of security issues that have been encountered is comparatively small, noted Ashley.

“The innovation benefits enabled by open source software far outweigh the risks,” he said.

It may be a while before the open source community comes to terms with rising software supply chain concerns. However, it’s clear that many more members of the IT community are about to be held accountable for it.

January 18, 2022
GrammaTech Adds SBOM Analysis Capability to CodeSentry

GrammaTech today updated its CodeSentry code inspection platform to include the ability to create a software bill of materials (SBOM) by analyzing application binaries.

Walter Capitani, director of technical product management for GrammaTech, said version 3.0 of CodeSentry leverages the algorithms the company uses for binary software composition analysis to enable organizations to better address software supply chain concerns in the wake of a series of high-profile vulnerabilities.

The tool can be applied to both commercial software and open source components via integration with Risk Based Security’s VulnDB database, created to track security issues.

There is more focus than ever on creating SBOMs in the wake of the Biden administration’s recent executive order that will require federal agencies to only use software that comes with an SBOM. However, most organizations are not provided with access to the source code used within the applications they employ. GrammaTech enables organizations to address that issue by analyzing the binary code within an application to generate an SBOM.

That report not only identifies all the components in an application, it also lists all known vulnerabilities associated with the version of the components being employed, said Capitani. CodeSentry will also list other common software products and the versions that may be impacted by the same vulnerabilities, along with versions of the software that have remediated the issue or versions of a component that have not been impacted by those vulnerabilities.

Almost all software applications include third-party and open source components that create blind spots within software supply chains. In fact, that issue is what makes remediating zero-day application vulnerabilities so challenging; especially when they are discovered in, for example, a log management tool like Log4j that is widely used in Java applications.

GrammaTech is making a case for a binary software composition analysis (SCA) tool that enables DevOps teams to address vulnerability issues prior to an application being deployed in a production environment. At the same time, however, security and compliance teams can now use the same tool to determine the level of risk an organization might be incurring once an application is deployed in production. That latter capability is especially critical because zero-day vulnerabilities are often not discovered until long after an application is deployed in a production environment, noted Capitani.

Regardless of approach, the need to better secure software supply chains is now a major IT issue that should ultimately encourage more organizations to adopt DevSecOps best practices to better secure applications. The challenge, of course, is not just espousing the need for those practices but also providing developers with tools they will actually use to implement those practices. The success or failure of those efforts comes down to not just the efficacy of the tool but also how well it fits within the overall developer experience. After all, the greatest tool in the world will still languish if it’s too difficult for the average developer to employ.

January 18, 2022
How Are API Management and Service Mesh Different?
The use of APIs and microservices is increasing—a recent study from F5 estimated that the industry is approaching 200 million total APIs. As organizations expand their use of APIs and microservices, they inevitably require some form of service management architecture. There are primarily two major design options for implementing this: An API management system or a service mesh.

The key distinction between API management and service mesh can be framed using the four cardinal directions. API management is typically adopted for REST services that face external developers—referred to as north-south traffic. On the other hand, service mesh is more commonly used by internal suites of microservices to help control lateral, or east-west, communication. There are more nuances between each, as we’ll cover below, but this is essentially how they’re adopted in practice.

However, this binary is becoming blurred as collections of enterprise digital applications expand and access to cross-company business domains begins to look and feel more like consuming a third-party SaaS. Furthermore, some suggest that with the right controls, service mesh can cater to external users in the same way API management does. What’s more, service mesh and API management are complementary—they can coexist within the same organization and even be deployed in the same projects.

I recently chatted with Mark Cheshire, director of product at Red Hat, about the emergence of both API management and service mesh. According to Cheshire, both approaches accomplished similar goals but evolved very differently. Below, we’ll revisit why these two paradigms emerged and compare and contrast them. In a separate article, we’ll consider when it’s best to integrate them both.

What is API Management?

API management is most often associated with north-south traffic. By exposing your API to the outside world, you enable other developers to connect it to their systems and leverage your data and functionality like building blocks.

API management arose in response to the rise of web APIs. API management is a broad concept encompassing many functions required to expose an API endpoint to the outside world. This can include authentication, authorization, request routing, documentation, rate limiting, monitoring, logging, monetization and life cycle management. A key goal is to make integration easier for the developer consumer. Architecturally, API management follows a gateway pattern. Consumers issue requests to the gateway which then performs routing to the underlying services.

For APIs, the big catalyst was the emergence of Web 2.0, Cheshire explained. Numerous startups began consuming RESTful APIs to connect their web properties and partner ecosystems. Companies also found REST APIs to be a much more straightforward integration approach than SOAP and SOA. They also saw the ease-of-use benefits and adopted API-first designs within their internal infrastructure.

As of 2021, over 70% of APIs are built for internal use. So, do all these services need API management? It depends. “If you communicate externally, you need API management,” explained Cheshire. But, it’s a grey area for services within an enterprise, he says, though inter-domain traffic often could benefit from API management.

A diagram of API management capabilities, from 3scale

Strengths
- Can enable north-south traffic
- Protects the boundary of an application
- Designed to ease external developer consumption
- Potential for monetization, subscription plans
- Typically plug-and-play; easier to support
- Many solutions on the market
- Developer experience and docs
- Analytics and reporting
Weaknesses
- May be heavier than service mesh
- Fewer open source options; vendor lock-in
- Analysis paralysis in comparing solutions
What is Service Mesh?

Service mesh is most often associated with controlling east-west communication between internal services. Service meshes like Linkerd, Istio and Kuma make it easier to reimplement similar logic—such as networking, observability, traffic management, security policies and routing—across many microservices from a single control plane.

Service mesh was born to address slightly different challenges than API management. “The transition from monolithic to microservices is all about east-west traffic,” Cheshire said. Companies found it slower to innovate monolithic applications and thus broke them up into microservices that communicate via APIs. But these microservices all needed similar operational capabilities, which would be cumbersome to repeat over and over for each service.

“For one monolithic app blown into microservices, you may not even need a service mesh,” said Cheshire. “However, when you have hundreds or thousands, that’s when applying service mesh becomes critical.”

Istio service mesh architecture

Architecturally, service mesh is typically divided into a data plane and a control plane. The service mesh deploys a sidecar proxy that sits alongside each individual service. Istio, for example, utilizes the Envoy proxy. Other meshes like Linkerd use their own proxy.

Strengths
- Fits the microservices architecture paradigm well
- Good for traffic routing; improving resiliency
- NIST-recommended architecture for achieving zero-trust
- Many open source options
- Fits large microservices deployments
Weaknesses
- Requires a more hands-on approach
- Potentially more maintenance to support
- Unnecessary for a single service
- Requires filter chain add-ons for north-south abilities
Comparing API Management and Service Mesh

API management is predominantly aligned with externalizing APIs to partners. When you do so, maintaining the contract with a consumer is more important to meet SLAs. Thus, API management commonly delivers life cycle management abilities, such as versioning. API management is necessary even if you are exposing a single API, as this service needs to be adequately documented and secured. That being said, these tenants can also be relevant to developers reusing software within an organization—there’s something to be said for adopting a product mindset when dealing with internal APIs.

On the other hand, service mesh is more aligned with controlling internal networks. Microservices are rarely deployed alone; typically, multiple microservices make up an application. And, many more might exist throughout an organization for unique purposes. Service mesh thus helps maintain consistency throughout large networks of decoupled microservices. Service mesh is also a rapidly growing field, experiencing an explosion of new development and production use. A Cloud Native Computing Foundation (CNCF) report found that service mesh use rose in production by 50% in 2020 alone.

To put the comparison another way, William Morgan, CEO, Buoyant described how API management is more about business logic, whereas service mesh handles intra-cluster operations:

“API gateways typically handle ingress concerns, not intra-cluster concerns, and often deal with a certain amount of business logic, e.g. ‘User X is only allowed to make 30 requests a day’. By contrast, a service mesh like Linkerd is focused on operational concerns (e.g. instrument these calls and report their success rate; secure this communication between these pods) and purposefully avoids the mixing of business and operational logic; and focuses on communication between the services on the cluster.”

Though service mesh and API management achieve slightly different aims, both layers make it easier to reuse web-based services. And, they certainly can be used in conjunction. For example, you could build API-first microservices with service mesh and simultaneously use API management to expose certain domains. In another article, we’ll consider when it’s best to integrate the two technologies.
January 18, 2022
Enabling Cloud Adoption in the Government
In 2022, federal agencies are estimated to spend $7.8 billion on cloud computing. While this spending on cloud computing is necessary, it’s imperative that the government uses its allotted funding appropriately to leverage the cloud’s full potential and avoid common pitfalls.

Avoiding Common Cloud Adoption Pitfalls

I’ve frequently witnessed government agencies get locked into a cloud reseller that doesn’t give them the full capabilities offered by AWS, Google Cloud or Microsoft Azure. Most people outside of the federal market don’t realize that the government does not buy cloud directly from the cloud providers—apart from some very large contracts like the upcoming JEDI replacement contract vehicle, JWCC. They buy through a network of reseller partners that offer volume discounts and try to bundle managed services to help with cloud management.

This approach gives the reseller, not the customer, the power to hold the keys to their kingdom—and can make it difficult for the customer to easily switch between cloud providers in the event of poor performance, lack of access or billing transparency. The federal government would benefit from keeping a small, but purposeful, cloud project management office (PMO) in-house. Thus ensuring that root access is available to all the accounts, subscriptions and projects to provide freedom to the agency to more easily change partners as their cloud maturity evolves.

I’ve also seen government customers unfocused on the holistic end-user experience of actually using the cloud. The result is fragmented collections of different systems, processes and steps that cause engineers to be frustrated and inefficient. Customers must transform the end-to-end cloud provisioning process so that self–service is paramount and existing technology investments are seamlessly and transparently integrated to the end-user. When done correctly, innovation will be the byproduct, because focus can go towards developing the next generation of mission systems and tools—rather than trying to determine how to get a cloud account to begin a project.

Three Steps Government Agencies Can Take to Get Value from Cloud Infrastructure

Challenges exist, but there are proven steps the government can take to get the most value from their cloud infrastructure.

Define purpose: First and foremost, understand the purpose the cloud infrastructure intends to serve. Are you looking to reengineer cloud architecture, become more cost-efficient, or transform the innovation potential within your organization by introducing new services that can take you farther, faster? Understanding this purpose and your goals will go a long way towards success.

Quantify ROI: To get the best return on your investment, understand what resources are already available and which are necessary for your operations. To fully take advantage of the cloud, it is important to make sure basic costs are under control, such as ensuring AWS EC2 or Azure VM instances are not overprovisioned or underutilized. It’s equally important to make sure you take advantage of reserved capacity reservations for your predictable workloads; these can save you 30% or more. Last but not least, keep a focus on fully leveraging technology solutions to help bring all the pieces together in an integrated user-friendly experience across cloud providers.

Consider the outsourcing approach: Bringing in cloud resellers and contractors can provide guidance to your organization and help you make better choices. Just like building or renovating a house, agencies need general contractor-type companies that can help to manage and orchestrate the process of migrating to the cloud and all of its moving pieces. These contractors can also help to locate the various specialists required to get the job done for each unique situation. Long term, having a small, efficient cloud PMO is something every agency should strive to have in-house; however, given the demand for cloud engineering talent, the near-term focus should be to ensure flexibility into engagements with partners, so that they don’t hold back the potential of the organization.
As digital transformation and cloud migration continue, it’s important for the government to stay on pace with its adoption. As of now, most agencies are still relying on manual steps to validate controls and get Authorizations to Operate (ATOs) approved. Making the simple swaps to more automated processes, learning how to leverage cloud resources to their full ability, and outsourcing operations to contractors can make acceleration easy. There has never been a greater need for cloud enablement. The time to scale up is now.
January 14, 2022
Low-Code SaaS Solutions Need Security at Their Core
Faster integrations. Accelerated software delivery. Elevated user experiences. These are only three of the benefits organizations gain by incorporating low-code platforms, apps and solutions into software development and business process management.

Low-code platforms aren’t new, but demand for the technology soared in the last two years as companies were challenged to meet stakeholder demand for more digital transformation. With low-code tools, companies find they can expand digital transformation efforts through faster business application delivery. In addition, the time it takes to innovate is dramatically reduced with low-code tools.

Low-code solutions are no passing trend. In their recent report on global cloud revenue, Gartner predicted that by 2025, the use of low-code and no-code will “nearly triple,” adding that “70% of new applications developed by organizations will use low-code or no-code technologies, up from less than 25% in 2020.”

Low-code solutions give organizations the ability to produce working solutions and integrations with more speed and agility than more traditional on-premises development. Integration used to be a labor-intensive IT process requiring custom development on both sides of the integration. As more organizations adopt a “buy versus build” approach to software development, they are turning to self-service and other solutions with “out of the box” functionality to increase speed and efficiency. In addition, the vendor-developed components of low-code tools also offer a better user experience.

Rising Demand for Low-Code, Platform-based Solutions

As organizations expand their product and service offerings, the demand for low-code, platform-based solutions will increase. SaaS and PaaS solutions with a low-code focus can be effective for organizations looking for accelerated functionality. Often these tools include pre-built models and templates that businesses can quickly implement and easily duplicate for flexibility and versatility.

The ability to create seamless integrations with other applications is a must. Best-of-breed low-code platforms enable intelligent integration between multiple applications using graphical user interfaces (GUI) as well as industry-standard interfaces such as JSON and APIs within vendor-supplied environments. Intuitive visual user interfaces and drag-and-drop features allow businesses to customize the solution to meet their needs and preferences.

But along with ease of use and rapid functionality, organizations must look for low-code tools with security built-in.
Security: A Priority for Low-Code Tools

Security must be a top priority for organizations using low-code tools in any capacity, from using a low-code platform for application development or using a no-code SaaS solution for business process automation.

Anytime an organization introduces outside applications or any third-party API integration to an environment, the organization is entirely dependent on the vendor’s security implementation. This is especially true when combining various solutions to create a unified product or service. If the vendor doesn’t take security seriously, other parts of a solution could be exposed to risk because of a weakness in another area.

Problems can get in either intentionally or unintentionally, as demonstrated with the recent Apache Log4j vulnerability. The bug in this commonly used routine was found to have massive potential for cybersecurity attacks. As CNET cautioned, “The vulnerability in the widely used software could be used by cyberattackers to take over computer servers, potentially putting everything from consumer electronics to government and corporate systems at risk of a cyberattack.”

Ways to Remedy Security Risks of Low-code Tools

Organizations can’t make assumptions about the security of every tool, solution or platform they bring into their environment. They must complete their own due diligence for security in the software development pipeline or any time a 3rd party app or tool is introduced.

One critical step to addressing security is incorporating DevSecOps and shifting security left in the software development pipeline. The Log4j vulnerability put the need for DevSecOps in the spotlight. Taking a shift left approach and implementing security earlier and more often in the DevOps process can help to catch more potential vulnerabilities. It’s critical to introduce DevSecOps early in the development cycle, or organizations risk missing a bug or vulnerability. In the development cycle, security isn’t an antivirus scenario; all code must be scanned for vulnerabilities.

Organizations also need to employ due diligence when exploring options and solutions to bring into their environments. Look for solutions with security at their core. Before integrating any low-code solution, examine the vendor’s approach to security.

Some security measures to look for when considering vendors or solutions include:

Ensure they’re using the latest OAuth/2 models for both client to server security as well as server-to-server security or an equivalent standard.
All communications should utilize at least TLS 1.2 (transport layer security) and comply with industry standards for certificates and encryption keys.

All hashing should be using current accepted standards with HMAC, they should be enforcing security rules on passwords such as only storing password hashes and requiring 2FA if they interact directly with customer accounts.

Low-code platforms and tools have the ability to accelerate digital transformation efforts without having to rely on hand-coded, on-premises solutions. The potential for time savings and cost savings is significant, but it’s important for organizations to ensure they’re not compromising security when choosing solutions.
January 14, 2022
2022 Predictions: AI, Security and Cloud

It is difficult to find a single area of the technology landscape that isn’t incorporating artificial intelligence (AI) into products and services. As we move into a world where distributed computing is the norm for business operations, AI is a requirement given the increasing level of complexity in computing environments. While there are many different ways AI is penetrating computing, I think that there are a few specific areas where we will see a huge amount of growth in terms of innovation and investment.

AIOps will be at the forefront of monitoring and managing distributed computing environments.

2022 will be a busy year for AIOps vendors and product offerings. Expect that, in 2022, you will see a massive number of large enterprise software companies bringing AIOps offerings to market—either as part of distributed computing management suites or as individual tools. In addition, there will be a flurry of well-funded startups entering the space. One of the first areas where AI models are productized is in the area of AIOps. AIOps provides the ability to apply machine learning models and automation based on data about the patterns and anomalies within IT operations. AIOps is an implementation of observability and helps businesses monitor and manage their IT environment based on collecting and managing data about operational patterns that are expected and correct. It also determines when there is an action that is outside of the norm, and provides either an automatic correction or offers IT operations management the ability to correct errors before they impact business operations.

Expect a year of consolidation in advanced analytics, security and solution clouds.

We’ve already seen 2022 kick off with a flurry of acquisitions. While we haven’t seen blockbuster buys, we have seen smaller acquisitions by big vendors that need more to sell their existing customer base. One exception is Alteryx, which purchased cloud-native analytics vendor Trifacta for $400 million in cash. In contrast, IBM recently purchased Envizi, an Australian data analytics firm focused on analytics for environmental, social and governance (ESG) requirements. This is just the beginning. We expect there to be a flurry of acquisitions in the hot observability market (solutions focused on analyzing how well the internal states of a system can be inferred from knowledge of its external outputs).

As security continues to grow in importance, key emerging security vendors also will be hot commodities in the acquisition space. For example, Microsoft has acquired RiskIQ, a security software vendor focused on gathering threat intelligence about a wide range of cyberattacks across multiple public and private clouds. We also predict that many of the large cloud vendors will move aggressively to buy cloud business solutions.

Looking Forward

It is easy to get caught up in the flurry of announcements and acquisitions coming at us fast and furious. However, the reality is that businesses need to know that whatever new shiny objects are introduced, these solutions need to be able to solve real customer problems that impact revenue and growth. It may sound obvious, but I think that vendors need to pay a lot more attention to customer pain.

January 13, 2022
How AI Can Improve Software Development

Change is constant and inevitable. While some changes are welcome, others are just a necessary evil.

Continuous calls for digitalization combined with a pandemic-prompted emphasis on transforming business operations, force organizations across industries to modernize their legacy systems. The emergence of cloud computing has shrunk organizations’ on-premise IT footprints. However, with 96 of the world’s largest 100 banks, 90% of the world’s largest insurance companies, 23 of the 25 largest retailers in the U.S. and 71% of the Fortune 500 still using mainframe systems, any modernization efforts—resulting in increased risk of downtime or defects—will frequently lead to disastrous consequences.

So, while making changes can be expensive, uncertain, and lead to customer loss and/or embarrassment in the marketplace, modern business demands that systems change to continue to deliver value. The problem with mainframe modernization, however, is that today’s code search tools, linters and program analysis tools are deficient when it comes to mitigating the risks associated with maintaining and improving systems.

Modernization: A Knowledge Problem

With 10,000 mainframes in active use globally, the average organization annually spends anywhere from 60% to 80% of its IT budget just on maintenance. But, as experienced and proficient programmers retire or move on, many companies are realizing that the specialized domain knowledge of the industry and institution that those developers used to create and update these complex critical systems is walking out the door with them.

As the developers who originally wrote the code have long since moved on, and documentation leaves a lot to be desired, developers new to a system are unable to acquire comprehensive knowledge of the system’s functionality, at a detailed or fast enough level, to become adequately productive and proficient. That lack of speed comes with significant risk and cost to any organization.

Recognizing the full and true intent of the functionality written in code is not simple. Developers today spend roughly 75% of their time searching through source code, to identify the code representing the functionality that needs to be changed. Complicating matters further, understanding the code is not enough. To effectively and efficiently maintain and support any system, software developers must know precisely what an application actually does—and how altering code in one part of the system impacts it as a whole. But since the code representing a behavior that needs to be changed can be littered throughout the system, developers might think they’re making a simple tweak, when really they may be breaking the entire system (and not even knowing it). The risk of change resulting in unintended consequences is real.

All of that being said, how can developers improve their efficiency and effectiveness?

The Shortcomings of Today’s Tools

With code repositories growing unchecked over time to extraordinary sizes, those responsible for maintaining and preserving a system’s functionality say it’s becoming increasingly challenging to find bugs in code without machine assistance. And with debugging being an arduous, time-intensive endeavor, developers are increasingly turning to code search tools, linters, and static and dynamic analysis tools to analyze millions of lines of code, flag errors and suggest fixes.

Whether the tool excels at bug localization, code visualization or “error” detection, entirely too many tools are insufficient when it comes to actually identify the specific lines of code that require attention. Program analysis tools only illustrate code in ways that developers still have to interpret (potentially incorrectly) and draw their own conclusions. While code search tools might speed the rate at which developers can build a mental model of the code, such tools are notorious for false positives, and developers still have to undergo the mentally challenging endeavor of piecing that mental model together to identify the code, and then safely make changes. Worse yet, code completion tools—tools that less-experienced developers disproportionately rely on—can actually propose imprecise changes (one prominent tool offers incorrect code 71% of the time), and that introduces risk.

The cherry on top of this problematic sundae is that today’s tools don’t have any way to effectively validate the scope and accuracy of a proposed change. The influence of a suggested change can be tough to identify, so testing for comprehensive validation is frequently next to impossible.

Ideally, there has to be a better way to mitigate risk while making changes to legacy systems. Enter artificial intelligence. By employing a unique approach to AI, the code repository truly becomes a knowledge repository, enabling many capabilities unrealized before now.

A Developer’s AI-Enabled Accessible Knowledge Repository

By leveraging AI to automate the identification of the specific lines of code that require attention, developers can simply ask this AI-driven knowledge repository where behaviors are coming from—and quickly identify the code associated with that behavior. This puts AI squarely in the position of intelligence augmentation, which is key to leveraging its capabilities.

This novel approach of AI reinterprets what the computation represents and converts it into concepts, therefore “thinking” about the code in the same way humans do. The result is that software developers no longer have to unearth the intent of previous developers encoded in the software to find potential bugs. Even better, developers are able to overcome the inadequacies of automated testing by using AI to validate that they haven’t broken the system before they compile or check in the code. The AI will forward simulate the change and determine whether it’s isolated to the behavior under change. The result is the bounds of the change are confined to the behavior under change so that no unintended consequences arise.

While AI is not yet advanced enough to safely make changes on its own, it can serve as a knowledge repository with the added capability of directing developers precisely where to make any needed changes. With AI, programmers—even on their very first day on the job — can make any necessary fixes with confidence that they won’t break the entire system.

Unlike its code search, code navigation, code completion and program analysis tool counterparts, AI fundamentally empowers developers to safely, efficiently and effectively make any necessary changes. With AI — that is fortified by a knowledge repository that understands source code the same way a human does — developers can truly do more with less.

January 13, 2022