devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

Survey Shows Correlation Between Open Source, DevOps Skills Demand

A survey published this week by the Linux Foundation suggested enterprise IT organizations now prefer to hire IT professionals that have both open source software and DevOps experience.

Conducted in collaboration with edX, a leading global online learning platform from 2U, Inc., the survey polled 1,672 open source professionals and 559 respondents with responsibility for hiring open source professionals. The results revealed there is also a high correlation between demand for that expertise and familiarity with DevOps.

In terms of skills most sought, 69% of employers said they are looking for IT professionals that have cloud and container technology expertise followed by Linux (61%) and DevOps/GitOps/DevSecOps expertise (57%). Another 40% are looking for individuals with cybersecurity skills.

More than three-quarters of the IT professionals (76%) surveyed currently work with Linux (76%), while 60% have worked with cloud/container technologies and 53% have DevOps/GitOps/DevSecOps experience. Well over three-quarters (79%) said it was either very important (44%) or extremely important (35%) to be familiar with DevOps.

Clyde Seepersad, senior vice president and general manager for training and certifications at the Linux Foundation, said with all things being equal in terms of salary and benefits, more IT professionals preferred to work for organizations that are clearly viewed as open source software leaders. Organizations that want to recruit the best talent should make an effort to be seen as significant contributors to open source software projects to attract the best IT talent.

Roughly half the respondents currently work for IT vendors, but the rest represented some type of end-user organization that typically consumes open source software. That distribution showed that demand for open source software expertise has now moved well beyond IT vendors that build commercial applications and IT platforms, he noted.

Overall, the survey found 93% of employers struggling to find enough skilled talent, with nearly half of respondents (46%) planning to hire additional IT professionals with open source software expertise in the next six months. A full 86% said hiring IT professionals with open source software expertise was a priority. Well over two-thirds of employers (69%) said they are more likely to hire an open source professional with a certification. A total of 90% of employers said they will pay for employees to obtain certifications, with 58% reporting that open source IT professionals typically have higher salaries.

A total of 81% of the open source software professionals surveyed also said they planned to add certifications this year. Nearly three-quarters of them (73%) also noted it would be easy for them to find a new job. About a third of those respondents either left or changed jobs in the last year, the survey revealed. Two-thirds of open source software professionals said a higher salary would deter them from leaving a job.

More than three-quarters of IT professionals (77%) also noted they would benefit from additional cybersecurity training.

However, only 43% of employers identified training as a means to close their current skills gaps. Another 41% said they hired consultants to fill these gaps. Only 16% of those respondents said they were willing to delay projects because of a skills gap.

It’s clear that IT vendors and enterprise IT organizations are, in many ways, competing for the same talent. The challenge enterprise organizations face is making sure they have a high enough profile to be perceived as a place where IT professionals can make a meaningful open source software contribution.

June 23, 2022
The Age of Software Supply Chain Disruption
The software supply chain is swiftly becoming a widespread attack vector, and securing it is now in the spotlight. Software supply chain attacks have become a given in 2022, reports Darktrace.

SolarWinds, Kaseya and GitLab are just a few examples of organizations that have been vulnerable to attack in recent years. We’ve also witnessed an increasing number of exploits, like Log4j and Log4Shell that have the potential to affect billions of devices. What these instances have in common is they leverage vulnerabilities in open source software and third-party dependencies commonly used in the software delivery process — meaning one corrupt package could have broad encompassing impacts on the tech industry at large.

I recently chatted with Doug Dooley, COO, Data Theorem, about the consequences of today’s intricate software supply chains. “The software supply chain problem is bad, but it’s only going to get worse in the next five years,” he said. According to Dooley, application security requires a continuous context of how the app functions at runtime in a software ecosystem—otherwise, it will continue to miss gaping holes in the big picture.

Understanding Software Supply Chain Disruption

Most people understand what a traditional product supply chain is—it encompasses all the components involved to bring a product to the end consumer, from raw materials to manufacturing, distribution and retail locations. But, amid the pandemic and recent international conflict, we’ve witnessed how brittle this chain is. If you shut down one of these components, all consumers feel the effect, resulting in everything from gas hikes to baby food shortages. A full 61% of organizations were hit by supply chain attacks in 2021.

In software, the supply chain can be thought of similarly—there are many components involved between a software product and the end consumer. The developer writes code, integrates third-party libraries and frameworks, puts it in source code systems, pushes it to test environments and eventually deploys it to production. And often, DevOps has the view of this whole picture.

“DevOps has become some of the most powerful people in the business,” said Dooley. “They can take a business person’s idea and turn it into reality in the form of an application.”

Third-party exposures can create huge disruptions in this above workflow. This could take the form of insecure libraries, underlying cloud vulnerabilities or API vulnerabilities, says Dooley. “Customers will embed APIs in the software stack—to them, it’s a black box.” There’s also the potential for misconfigured S3 buckets, which continually leak millions of records. More serious application security threats include remote code execution, which can invoke a detrimental loss of control.

Why Now?

So, why the sudden peak in software supply chain-related security incidents? After all, open source software, APIs and third-party vendors have been around for decades. Well, according to Dooley, there are several factors at play here.

For years, the Silicon Valley mantra has been to ‘move fast and break things.’ Take Netflix engineering, for example, which is constantly evolving services and releasing dozens of changes per day. According to Dooley, such rapid application development often means that security is following development rather than preceding it or becoming integrated into the process, à la DevSecOps. This could lead to what he calls an “ambulance chaser moment.”

The attack surface is heightened as the number of third-party suppliers and dependencies increases. The average company has 254 SaaS apps, Productiv data found. Also, on the attacker side, we’re seeing increasing levels of automation and sophistication. “You only have to be right one time when attacking,” said Dooley. “The deck is stacked in an attacker’s favor.”

Strengthening The Chain

The software supply chain issue is a complex problem that won’t be solved by any single action. However, Dooley offered several tips for companies to consider as they confront this broad problem:
- Source code analysis and vendor management. It’s important to vet partners and have a process to audit new software by scanning for common vulnerabilities and exposures (CVEs). Yet, source code analysis falls short in many areas, admitted Dooley, as it is unlikely you will be able to view the source code behind cloud API calls and production behavior doesn’t always match documentation.
- Continuous runtime security monitoring. New exploits are being found constantly. Thus, organizations require a continuous defensive posture at runtime, even if they were found to be secure in development. Continuous full-stack discovery must consider many third-party components, like SDKs, open source code, mobile apps, web services, cloud services, APIs and identity and access management, explains Dooley.
- Increased transparency with SBOMs. More widespread use of software bills of materials (SBOMs) will be critical to increasing transparency across the industry. Just as nutrition facts describe the food we eat, SBOMs spell out the internal makeup of software components. “We’re trying to get to a place where we get more transparency into the software we depend on,” Dooley said.
- Rapid vulnerability detection. Have a good handle on the attack surface. Businesses will want to collect an accurate inventory of what can be attacked.
- Build protection around the “crown jewels.” Sometimes, you must prioritize which steps to take first. Dooley reiterated that securing applications that interface with customer data is critical, as these are the “crown jewels”—leaks here could have serious consequences around regulatory penalties and brand reputation.
Caution: Heavy Lifting Required

“The moment you ship a piece of software, you’ve taken on a risk,” said Dooley. But at the same time, if you’re not creating digital interfaces, you’re missing out on massive opportunities.

Reusing code and open source packages have become necessary to maintain agility to help continuously release digital products. “Even if you build everything from scratch, you’re still reusing a lot,” said Dooley. “Without it, you’d never get to market.” While these tools enable unprecedented speed, we can’t overlook the potential vulnerabilities that may lie within the software supply chain.

With its unique window into the software deployment and automation process, the DevOps sphere will undoubtedly have a role to play in protecting this paradigm. “Let’s push for more transparency and disclosure,” said Dooley. “But don’t hang your hat on that to make your program great—if you really care about this problem, you’ll have to do some heavy lifting in the real world.”
June 23, 2022
Survey Uncovers Depth of Open Source Software Insecurity

A survey from Snyk and the Linux Foundation published today found that less than half of respondents (49%) work for organizations that have security policies in place for the use or development of open source software.

The survey, which polled 550 software development professionals, was conducted by Snyk, a provider of tools for securing software, and the Linux Foundation. Just under a third (30%) of respondents without any policies in place also admitted that no one on their team is currently directly addressing open source security. A total of 41% said they didn’t have high confidence in their open source software security. Nevertheless, 59% of respondents said the open source software they deployed is somewhat or highly secure.

Matt Jarvis, director of developer relations for Snyk, said many organizations are not aware of the degree to which open source software is now being targeted by cybercriminals looking to surreptitiously insert malware into widely used software projects. Those same organizations also lacked clarity about how open source software is constructed, he added.

In many ways, the open source software community has now become a victim of its own success, noted Jarvis.

Overall, the survey found the average application development project has 49 vulnerabilities and 80 direct dependencies on open source software. Only 18% of respondents said they are confident of the controls they have in place for their transitive dependencies. A full 40% of all vulnerabilities discovered were found in transitive dependencies.

Only a third of respondents (33%) are using static application security testing (SAST) tools within a continuous integration process or software composition analysis (SCA) tools to discover those vulnerabilities, according to the survey. Overall, 44% reported they use some type of tool to analyze source code.

In terms of additional capabilities, 59% said they would like to see more intelligence added to these tools, while 52% cited a need for more clearly defined cybersecurity best practices. Nearly half (49%) also wanted increased automation and tools for conducting security audits.

The survey also found that fixing vulnerabilities in open source projects takes 19% longer than in proprietary projects.
Among organizations that do have security policies in place, 80% vested responsibility with the security team. Only 40% of organizations without such policies did the same, according to the survey.

The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. Developers today routinely reuse open source software. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure the projects and software are secure is on the organizations that decide to deploy that software.

Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities. Hopefully, following an executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead.

June 21, 2022
Supergraph: One GraphQL Schema to Rule Them All

GraphQL has been garnering much interest as a way to seamlessly interact with backend services. The query language is a boon for frontend developers, too, as it conveniently allows you to fetch the specific fields you require, thus eliminating the potential overfetching or underfetching concerns of REST APIs. And as GraphQL adoption matures within organizations, there is increasing interest (and investment) in how enterprises can use GraphQL to securely unify their growing catalog of disparate microservices and APIs.

Using GraphQL as a meta layer could help unite many disparate systems under a single unified schema. This would enable the age-old promise of composability, in which software building blocks are seamlessly pulled together to assemble applications and unique experiences for different client types. However, managing GraphQL at scale can become tricky. And when a schema gets really large, it then may require a schema of its own! This is where the concept of the supergraph comes in.

I recently met with Geoff Schmidt, Apollo GraphQL CEO, to discover what a supergraph is and how it may help platforms aggregate their backend microservices. According to Schmidt, “Developers want this composition layer for one abstract view of all their services.” Below, we’ll explore the concept of the supergraph and look at some new open source components that may help you enable GraphQL-based composability in your organization.

Microservices Enable Composability

First off, what do we mean by composability? Well, composable architecture is intrinsically linked with microservices. You can think of each microservice as a single lego piece that makes up one aspect of an application. For example, Uber uses 4,000 microservices to power its backend. These services span from maps, currency conversions, driver reviews, payments and other components. When combined, they ultimately create the convenience and the sleek user experience that is Uber.

Historically, software developers were overseeing larger monolithic applications in which a single client was interconnected to a web server, Schmidt explained. On the other hand, microservices tend to be more domain-specific and used in tandem with other microservices. They’re also typically easier to iterate on and faster to ship when compared to monolithic codebases.

The Need for Aggregation

As a result of the microservices age, applications typically pull in far more data from various sources. For example, a banking application might loop in a mortgage service, investment service and other data sources to display a combined net worth on a screen. This explosion in microservices has created a “polygon environment” spanning databases and APIs, increasing service complexity, said Schmidt.

Nowadays, many third-party components must be combined to render an experience. However, supporting this composability can be challenging for developers and backend API teams—not to mention that handwriting a backend-for-frontend could be burdensome. “App developers are slowed down by the need to integrate or compose these backend services,” said Schmidt. “Developers need a way to put all those pieces back together.”

What is Supergraph?

Supergraph can be thought of as a graph of graphs. The vision is to have one GraphQL schema and one ingress port to oversee many services. Creating a supergraph is becoming more accessible, too, as more open source projects emerge to enable this paradigm. For example, Apollo recently open sourced some components that can help to build and operate a supergraph. These include Federation, which helps to create a data graph across multiple services, and the Apollo Router, a tool written in Rust that decides how to route queries. Apollo has also open sourced a supergraph demo along with other resources.

A supergraph architecture is already powering Expedia, Walmart, Netflix, Paypal, the New York Times and other large environments, said Schmidt. For example, Expedia has used a supergraph to combine flights, rental cars and other microservices to create integrated experiences. Hivee, an upstart modern supermarket chain, also uses a supergraph to unite its investment into APIs.

According to Schmidt, the fundamental benefit is that less time is spent writing integration code which means faster development speed and the ability to quickly pivot your business. “It allows you to change business quickly to meet the needs of your customers.” A supergraph could also enable greater visibility into your API estate, making auditing easier.

A key benefit of the above components is that they already have a proven track record running at a commercial scale. But outside of the Apollo projects, other groups are attempting to codify a similar GraphQL schema aggregation concept, as well. For example, WunderGraph utilizes GraphQL within a “virtual graph” that acts as a common language to call various underlying APIs.

Repercussions of ‘One Graph to Rule Them All’

Schmidt said the hope is that, at the end of the day, this abstraction can contribute to “making the world a little more human-centric.” This is because GraphQL can enable less rigid apps that conform to unique user tastes. But a robust composition layer will be necessary to allow such reconfigurations.

Of course, as I’ve covered previously, there are significant security hurdles to address when supplying so much power to a single entryway. Increased GraphQL reliance will require forethought into new potential security risks, such as schema introspection and object-level authorization control.

According to Schmidt, a GraphQL composition layer presents an opportunity to enforce security controls. He defines these as contracts that create access rules for a particular set of users. By declaratively managing GraphQL security, a development team, in essence, could expose a subgraph of the supergraph for a partner to consume. The graph could even be segmented for internal teams.

A central point of ingress will require authorization rules to protect user privacy and avoid breaking the rule of least privilege. Schmidt also advocates for backend schemas to be built for app developers who understand their needs, instead of precisely mapping logic to business models.

Supergraph: A Graph of Graphs

Software is becoming more modular, which has resulted in an explosion of unique microservices and APIs. And we’re now at another tipping point in how software architecture is divided and combined, said Schmidt. He now sees GraphQL as a prime opportunity to create software architectures that call multiple backend services with a single GraphQL query.

“GraphQL is the composition layer you need to build modern applications,” said Schmidt. “We’re super excited about this. Users have shown that GraphQL is the future. Supergraph is such a powerful technology, and we’re excited to bring this to everybody.”

June 21, 2022
Open Source Coder Tool Helps Devs Build Cloud Spaces

Coder today launched an open source project that gives developers and data scientists a way to create cloud workspaces in a matter of minutes to make it easier to build applications and models faster.

Currently, Coder provides a cloud application development platform that enables developers to build applications using any editor or integrated development environment (IDE) as an alternative to their local desktop. That capability is made possible by using the open source Terraform infrastructure provisioning tool to spin up a developer workspace. That approach provides developers with access to cloud resources that scale up and down as required versus, for example, being limited to the memory and storage resources that they can access on a laptop or desktop system.

Ketan Gangatirkar, vice president of engineering for Coder, said that while individual cloud service providers offer ways of achieving that goal, those offerings lock organizations into a specific cloud service. The Coder approach allows developers to use their preferred tool across multiple cloud services, he added.

Most developers are already building applications that run on multiple cloud platforms. As such, they require access to a set of tools that eliminate the overhead created when developers need to deploy and master a diverse range of tools to build those applications, said Gangatirkar.

In contrast, with the Coder tool, developers can open a web browser, choose a workspace template and then start coding, he noted. That capability eliminates all the manual, error-prone processes typically required to get a developer workspace set up, said Gangatirkar.

That approach also provides organizations with a more secure means of building applications compared to the time and effort that would otherwise be required to secure every local system used by a development team, he added.

In general, there’s a lot more focus on developer productivity as organizations increase the number of applications they are simultaneously building and deploying. Hiring and retaining developers remains a major challenge as competition for talent intensifies in the race to accelerate digital transformation efforts. All things considered, many developers will prefer to work for organizations that allow them to use the tools they already know and prefer. That approach also makes it easier to onboard developers to a development project, noted Gangatirkar.

It’s not clear how many application development initiatives are never begun simply because it takes too much time and effort to spin up a development environment whenever inspiration strikes. However, it’s clear that developers are wasting a lot of time maintaining multiple local development environments. Much of that time could be better spent writing actual application code.

One way or another, open source tools—such as the one provided by Coder—should remove a lot of the friction that exists in application development today. The only issue that remains is whether those tools will be adopted by developers themselves versus the DevOps teams dedicated to serving them.

June 20, 2022
Cloud Giants Shun Wind Power? | LaMDA not Sentient? | MS IE RIP?

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Warren Buffett asks too much for wind energy, it’s “completely ridiculous” to say Google’s chatbot LaMDA is sentient, and Microsoft finally kills Internet Explorer. (more…)

June 16, 2022
Grafana Labs Adds Visual Tools to Simplify Prometheus Queries

At its GrafanaCONline event, Grafana Labs today announced an update to the open source Grafana dashboard. The update adds visual query tools to make it easier for IT professionals of any skill level to launch queries against the Prometheus monitoring platform or the company’s Grafana Loki log aggregations framework.

In addition, Grafana said the open source edition of Grafana OnCall, a scheduling and paging application, is now also available as open source software that can be used in on-premises IT environments. Previously, Grafana OnCall was only available as part of the managed Grafana Cloud service.

Archana Kesavan, director of product marketing for Grafana Labs, said version 9.0 of the core Grafana platform makes Prometheus monitoring more accessible. Prometheus is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). It is most widely used in Kubernetes environments, but can also be used with monolithic applications. The latest version of Grafana adds support for an exemplars overlay for traces and Prometheus sparse histograms.

Other capabilities added with this release include a dashboard preview and title search capability, support for envelope encryption by default, an expanded navigation bar and a revamped heatmap panel that renders more quickly than its predecessor.
‘

Finally, the alert system that Grafana Labs first introduced as an option is now a default setting.

Kesavan said in addition to making it easier to launch queries, the Grafana Labs approach also limits the ability of a poorly constructed query to impact clusters running Prometheus.

In general, the adoption of Prometheus has risen alongside Kubernetes. At least initially, DevOps teams that adopt Kubernetes often employ Prometheus to monitor the platform. Less clear is the degree to which IT teams will continue to rely on Prometheus once cloud-native applications are deployed in a production environment. Many IT teams already have a monitoring platform they employ that they choose to extend to Kubernetes environments. Conversely, however, some organizations are opting to replace legacy tools with the Prometheus monitoring platform to monitor both Kubernetes environments and legacy monolithic applications.

At the very least, Prometheus has established a de facto standard for collecting monitoring data from Kubernetes environments that can be queried by a wide variety of tools.

One way or another there will soon be fleets of Kubernetes clusters deployed across the extended enterprise that will need to be monitored. DevOps teams will naturally need to decide for themselves how best to monitor those clusters and, ultimately, observe them in a way that enables queries to be launched and issues surfaced before they become a major problem.

In the meantime, DevOps teams might want to consider consolidating many of the monitoring tools they use today as part of an effort to streamline operations. Rather than having to correlate events across a dozen tools to determine the root cause of an issue, the goal should be to have enough tools to ensure verification without spending hours sorting through conflicting reports.

June 14, 2022
CDEvents Aims To Standardize CI/CD Interoperability
Companies are under mounting pressure to continuously release new applications and features. And as software development life cycles become more iterative, continuous integration and continuous delivery (CI/CD) has become a necessary ingredient to enable more rapid deployments.

Many development teams now embrace DevOps, but fully automating a CI/CD pipeline from source code to production deployment is no easy task. For one, the number of tools in use continues to balloon, meaning CI/CD poses an ongoing maintenance hurdle. Furthermore, CI/CD tools often adopt varying formats to describe their events. A CI/CD pipeline, a form of event-driven architecture, may require a lot of special “glue” to patch events together if the output from each tool is not in a standardized format.

Interestingly, CDEvents, an emerging open source standard from the Continous Delivery Foundation (CDF), is working to standardize the root semantics of how CI/CD tools describe the payloads of their events with more granularity than CloudEvents. The project aims to establish schemas for how common CI/CD events are described, easing integration and providing more actionable data surrounding the CI/CD pipeline.

I recently met with Andrea Frittoli, open source developer advocate at IBM, to understand why the CDEvents project exists, how it works and what they’re hoping to achieve. According to Frittoli, who is also co-creator of the CDEvents project and a member of the CDF Technical Oversight Committee, CDEvents has the potential to bring much-needed interoperability to the sprawling CI/CD tooling ecosystem. Below, we’ll investigate where the project is and consider where it’s heading.

The Problem With CI/CD

At its core, the problem CDEvents is trying to solve is a lack of interoperability in the CI/CD field, explained Frittoli. As it stands today, DevOps engineers must routinely make point-to-point integrations between CI/CD tools. “No single tool will take you entirely from managing source code to production,” he said. A single development team could be using up to 15 unique components in one pipeline, and tooling preferences can vary dramatically across teams, he adds, further complicating CI/CD interoperability.

Although CloudEvents has made inroads as a specification to describe event data, nothing has yet existed specifically for describing CI/CD events. According to Frittoli, CloudEvents falls short here, as it’s agnostic about what is inserted into the payload.

Understanding CDEvents

CDEvents is “a common specification for Continuous Delivery events.” Frittoli describes it as a shared dictionary or shared semantics for common events. These events could be a change in source code, running a test, or a code execution or deploy. CDEvents uses JSON object schemas to describe the event types and can work alongside CloudEvents as an attribute. “CDEvents is a standard format for the payload as well, not only for the envelope,” said Frittoli.

As Frittoli explains, the CDF special interest group is still drafting the CDEvent specification’s exact semantics and common names. Currently, CDEvent organizes these objects into four main buckets: Core events, source code version control, CD events and CI events.

While the group is still finalizing the format of events as they work toward the initial release, the example below is an approximation of what the final format will look like:
```
"meta": {
  "version" : "draft",
  "event_id" : "A234-1234-1234",
  "source" : "/staging/tekton/",
  "type" : "dev.cdevents.taskrun.started",
  "timestamp" : "2018-04-05T17:31:00Z"
},
"subject": {
  "id": "/namespace/taskrun-123",
  "type": "taskrun",
  "content": {
    "URL": ...
    "pipelinerun": ...
  }
},
"extensions": [{
  "name": ,
  "content": ...}
],
"links": [{
...
}]
```
Benefits of CI/CD Event Standardization

So, why is it necessary to define the format of CI/CD event data? What benefits does this bring to developers and the business as a whole? Well, Frittoli sees two potential primary use cases. First off, CDEvents could reduce the effort spent writing and maintaining glue code between common DevOps tools like Spinnaker, Argo or Flux. “This will allow a smoother integration between all the parts,” said Frittoli. Alleviating this could help scale CI/CD initiatives and increase overall agility.

Another positive side effect is collecting more detailed information about workloads and their performances. If all these components generate similarly-formatted events, Frittoli explained, then you can begin to create a true end-to-end visualization of the entire CI/CD pipeline. Then, you can start to measure things such as deployment frequency, failure rate, time to change and other metrics.

If events begin to use a common language, you could do many interesting things with that data, says Frittoli. Event data could help ascertain the root cause of incidents and aid debugging. One could even foresee some AIOps potential to further automate operations and increase observability around CI/CD.

Final Thoughts and Ways to Participate

CDEvents emerged at a time when iterative software development has become commonplace. A slew of helpful CI/CD tools is at our disposal to enable niche operations. Yet, the space still requires a standard way to operate between them. CDEvents is an exciting prospect, yet the project is still in its early stages. It has yet to reach a full release or any production use and proofs-of-concept are still being developed.

Of course, encouraging a vendor-neutral specification requires the tooling community to get on board. “It’s vital for the different tools to implement CDEvents for it to be successful,” said Frittoli. He encourages the tooling community to join the working group to collaborate in building proofs-of-concept. The SIG plans to continue working on finalizing the first version of the specification. In the meantime, the group has produced a proof-of-concept using Tekton and keptn and the project has its future sights set on Knative and Jenkins.

The CDEvents project is in incubating mode and maintained by the Events Special Interest Group (SIG) at the CDF. For more information, you can peruse the CDEvents documentation here or become involved with the community here. The Events SIG also holds biweekly meetings and a CDEvents Community Summit will be part of the upcoming CDcon.
June 14, 2022
AppSmith Adds Git Support to Low-Code App Dev Framework

AppSmith has added support for Git repositories to an open source framework for building custom applications using a low-code platform based on the JavaScript programming language.

Rishabh Kaul, head of marketing for AppSmith, said the Git support will make it simpler for developers to manage version control as they iteratively build applications using a set of graphical widgets provided by AppSmith.

AppSmith is used primarily by developers to build internal applications that automate a specific task or workflow. Support for Git makes it possible for multiple developers to more easily collaborate as they add work to a Git branch and make requests within the context of a continuous integration/continuous delivery (CI/CD) pipeline.

That also makes it simpler to test applications and roll back to a previous version in the event something should go wrong, said Kaul.

The Community Edition of AppSmith will make it possible to connect to unlimited public repositories and up to three private ones before requiring developers to upgrade.

In recent years, use of low-code tools has increased dramatically as organizations embrace tools that enable them to build applications faster. Not every application requires developers to employ tools for working with procedural code. There are typically hundreds of use cases where an organization could build and deploy an application that would eliminate the need for an internal team to license yet another packaged application.

In general, AppSmith and other open source tool and framework providers are betting that, as the economy continues to shrink, the adoption of these tools will increase as organizations continue to become more sensitive to costs. That approach will allow them to continue to provide applications tailored to automate specific tasks.

The challenge, of course, is that as the number of applications being built and deployed steadily increases, the DevOps workflows that regularly update, secure and maintain those applications become much more challenging.

It’s not clear what percentage of applications are now being built using some type of low-code tool. However, the overall size of organizations’ application portfolio is generally much higher than it was prior to the pandemic. Many of those applications are driving digital business processes intended to make the workforce more efficient at a time when many employees continue to work from home.

Less clear, however, is how many new applications are being built by so-called citizen developers. One way or another, however, it’s becoming easier for end users that have some basic software understanding to build applications. Inevitably, those application development efforts will also need to be integrated within the context of a DevOps workflow.

Regardless of how an individual DevOps team may view low-code tools, they have permanently altered the application development landscape. The issue is no longer whether low-code tools will be used by developers but rather to what extent. In the meantime, DevOps teams would be well advised to review just how extensible their existing pipelines need to become.

June 13, 2022
Saying Goodbye to Legacy Systems
Are you still using a rotary phone, tube television or Rolodex? Probably not. But if you were, you’d still be using newer technology than what many enterprises still rely on every day to drive mission-critical applications that we use every day when shopping, banking or hundreds of other normal tasks.

At least two-thirds of large enterprises are running mainframe-based apps that date back 10 to 20 years and more than 25% of businesses feature applications that are between 20 or 30 years old. Today, businesses are often running and maintaining legacy applications built on traditional databases while simultaneously building microservices-based apps to accelerate new services and innovations. The mantra “If it ain’t broke, don’t fix it” certainly applies here; and while there are many reasons organizations continue to rely on mainframes and legacy systems, there are also many organizations that want to begin modernization initiatives but don’t know where to start.

However, the past few years saw a wave of new digital-first companies in all industries putting pressure on legacy systems-based businesses—from retail to finance to manufacturing to technology. The COVID-19 pandemic accelerated many organizations’ modernization plans and made clear that for those that wanted or needed to modernize to stay competitive, avoiding the problem just wasn’t an option. Companies found that if they weren’t proactive about modernizing, the cost of being reactive when they needed to update and evolve was exorbitant.

Accelerating IT modernization initiatives can be a major challenge: Safely modernizing those legacy apps and mainframe systems and the critical data in them can seem impossible, but it can be done. Companies like Kroger, for example, have already made that jump and there’s a lot to learn from them. Here are three things that can help any enterprise on their journey to say goodbye to mainframes and legacy systems:

You Need a Frictionless Path for Legacy Apps

Many modern solutions are only focused on greenfield applications and helping newer born-in-the-cloud companies and projects; however, the reality is most Fortune 1000 companies have a lot of existing applications they can’t afford to ignore or completely rebuild all at once. Supporting existing applications with standard interfaces like Postgres while delivering the scalability and resiliency to support modern applications is critical to providing a bridge from where companies have been to where they are trying to go. Distributed SQL databases provide a seamless path forward to modernize existing apps while supporting new and current initiatives.

Embrace Automation

It’s time to stop relying on complex code or fragile systems with bolted-on third-party tools. Being able to rely on intelligence and automation in the data layer for distribution, resiliency and availability is critical to minimizing changes and impacts on current applications. Doing so will reduce risk, offload legacy app tasks and ensure systems have the intelligence to work properly. With a distributed SQL database, you can deliver a single logical database that appears to applications like a monolithic, single-server database but with the underlying intelligence to allow it to stretch across hybrid, private and public clouds.

Finding Flexibility and Becoming Future-Proof

To avoid being tied to specific systems or architectures, it’s time to adopt a future-proof mindset. Businesses can achieve this through:
- Multi-cloud/hybrid cloud: With a distributed SQL database, you can deliver a single logical database that looks like a monolithic, single-server database but with the intelligence to stretch across hybrid, private and public clouds—providing the flexibility to be deployed wherever the application is needed or is best served.
- Any hardware: No two data centers look alike and there are a wide variety of hardware needs, from bare metal to VMs and containers. The right modern distributed database provides ultimate flexibility in where the data layer can be installed to match whatever hardware and configurations are already in use.
- Any deployment: Existing organizations have a wide variety of environments and deployment types, from single data centers to two or more private data centers to more and more hybrid environments that span on-premises and public clouds. A modern distributed database provides the freedom to support a wide range of deployment options, including synchronous replication, geo-partitioning and cross-cluster asynchronous replication.
- Open source freedom: While many databases provide some open source components, there are still a few 100% open source solutions committed to the Apache 2.0 license. Users can benefit from the full set of enterprise features and capabilities in these open source solutions as well as benefit from the security and transparency that comes with a 100%-open source solution.
It’s time to update the old adage, “If it ain’t broke, don’t fix it” to “If it ain’t fixed, it could be broke,” with regard to modernizing legacy systems. If you’re considering starting a modernization journey, save time, resources and money now to make upgrades that might later be costly, time-consuming and overwhelming for your internal teams.
June 6, 2022