devopsy.kinsta.cloud

Tag: application development

Low-Code Meets DevOps: A Smart Way to Manage Modern App Delivery Demands
In a fast-moving and often fiercely competitive marketplace, companies need to embrace technology to stay relevant and drive growth. To this end, the business community is increasingly placing a high priority on digital transformation. In fact, more than 80% of organizations believe that digital transformation is crucial to business success.

Digitally driven processes can power increased business speed and agility, as well as enhance competitive differentiation. Many organizations are now focusing on tools and methodologies that allow them to optimize more processes through accelerated internal application development efforts. Their goal is to be able to create, test and deploy the volume (and variety) of applications required to elevate performance and unlock more opportunities.

In response to these growing needs for rapid app delivery, DevOps practices are evolving and becoming more critical to the success and agility of a business. According to a study conducted by Verified Market Research, the global DevOps market was valued at $3.62 billion in 2018 and is projected to reach USD 20.01 billion by 2026. Today, many businesses are combining DevOps approaches with low-code or no-code app development platforms, because these solutions provide them with the tools to build applications faster and more efficiently. This strategy helps to alleviate the immense pressures placed on developers today, by streamlining their workloads and responsibilities, while simultaneously enabling them to reduce their development cycle times.

The Business Benefits of Fast, Agile Application Development

Due to combining the roles, practices and culture of software developers and ITOps teams, DevOps allows a business to deploy apps more rapidly and with a higher degree of consistency. This is essential in organizations where there’s more pressure than ever before to deliver applications at the speed of internal and external demand.

Often, the goal of adopting DevOps within a company is to reduce the tedious manual tasks that monopolize developers’ time and lead to app delivery backlogs. Solutions that help lighten and streamline the workload of DevOps–through automation and low-code development environments–are becoming more critical as a growing number of demands are being put on this still somewhat evolving, yet increasingly prioritized, team role and culture.

Outlined below are a few examples of how low-code app development platforms can enhance the growing role of DevOps and improve the bottom line. This approach helps to:
- Broaden the app development space to non-technical professionals: As mentioned before, low-code platforms enable a wider pool of less-technical users to work on and improve the speed at which applications can be built. Instead of the traditional app development team being solely responsible for a growing number of application requests, business users are now able to support digital transformation efforts by building and modifying their own processes, without writing complex lines of code.
This approach makes the process of development more accessible to non-technical professionals. As a result, businesses can liberate their developers from routine coding work and redeploy these highly skilled individuals to more strategic projects that are critical to core business processes.
- Facilitate faster application building: In addition to making application builds more accessible and less complex, the low-code environment also speeds up the entire development and deployment process. With this approach, companies can reduce development timelines from weeks or months to hours or days. Accelerating this cycle is crucial in any business that aims to outpace competitors.
- Streamline consistent application deployment: Low-code platforms can integrate into toolchains (or a set of programming tools) that can automate the deployment of applications across various business environments. This ensures that apps created by non-developers can be deployed in the same manner as traditional, developer-based applications. This consistency provides a lower cost of ownership because it allows a low-code platform to more easily integrate into the business processes and workflows the organization already has in place. This minimizes the risk of disruption and irregularities.
As businesses embrace innovation and elevate performance across the enterprise through agile, accelerated app delivery, the role and function of DevOps will continue to grow in influence and priority. Businesses that strategically leverage low-code solutions in combination with modern DevOps practices are likely to position themselves for growth, competitive differentiation and sustainable business success.

— Holly Anderson
October 14, 2019
Pulumi Deepens Cloud Ties to DevOps

Pulumi has made available a framework for automating the management of multiple cloud computing platforms using familiar programming languages such as JavaScript, TypeScript, Python and Go.

Company CEO Joe Duffy said Pulumi 1.0 provides a framework that enables developers to automate the deployment of applications on public clouds in a way that eliminates having to learn another programming tool or manually employ YAML files that are often at the root of misconfiguration issues. Pulumi also provides access to a software development kit (SDK) through which scripts or code developed for Terraform, CloudFormation, Azure Resource Manager, Kubernetes or Helm can be imported into the Pulumi framework.

Pulumi also has extended the reach of its automation framework to provide integration with a variety of continuous integration/continuous deployment (CI/CD) platforms including Azure DevOps, AWS Code Services, CircleCI, Codefresh, GitHub, GitLab, Google Cloud Build, Jenkins and Travis. Pulumi also can be embedded with integrated development environments (IDEs) to provide statement completion, interactive documentation and rich error-checking.

Duffy noted Pulumi also now can be extended to further adoption of best DevSecOps practices. A Pulumi Key Management Service is integrated with the key management tools from Amazon Web Services, Microsoft Azure, Google and HashiCorp. Pulumi also provides role-based access controls and integration with identity management tools spanning GitHub, GitLab, Atlassian, Active Directory, Okta and Google G Suite, among others.

Pulumi comes in three flavors: A free Community Edition enables individuals to manage their cloud environments, a commercial Team Edition adds support for organizations and an Enterprise Edition provides additional identity options, policies and controls, as well as self-hosting capabilities.

Duffy said frameworks for automating application deployments on multiple clouds are necessary because enterprise IT organizations now routinely embrace multiple clouds. Rather than requiring IT operations teams to master programming environments, Pulumi makes it possible to shift deployment responsibilities on to the developer, he said, noting that approach should significantly increase the rate of speed at which applications can be deployed using cloud platforms such as AWS, Azure, Google Cloud Platform, Digital Ocean or others.

While a lot of progress has been made in terms of continuous integration, organizations are finding continuous delivery to be a challenge. Pulumi is betting that by directly involving more developers in the deployment process, organizations will find it easier to extend their DevOps processes in a way that doesn’t require anyone to learn new programming tools.

In the meantime, the rate at which new applications are being built is only going to accelerate. As development teams embrace a wide range of cloud-native technologies, it’s only a matter of time before the application deployment backlog increases significantly. IT leaders are going to be under a lot of pressure to solve that issue in a way that results in more applications not only being deployed on a timely basis but also deployed reliably. Having more applications running in a production environment that winds up having issues later isn’t necessarily progress. In fact, it’s likely most IT leaders would find themselves in even hotter water for exacerbating cloud security issues that already plague most organizations.

— Mike Vizard

September 5, 2019
Atomist Takes on Application Drift Management

Atomist today announced it is extending the capabilities of its software delivery automation platform to include drift management tools that make it easier to identify changes to code.

Now in beta, that capability is based on an open source project dubbed Org Visualizer, which makes it possible to clone an entire project hosted in a GitHub repository via a single click and then visually inspect it.

DevOps teams also can leverage a built-in Policy Manager to capture and track changes in code, define custom policies that automatically apply updates and automated actions and generate progress reports showing how close they are to achieving a target policy goal.

Atomist CEO Rod Johnson said the reporting tools provide a visual representation of what’s occurring within an organization’s codebase to make it easier to identify both overly complex dependencies and vulnerabilities.

The drift management tools are built on the software delivery machine (SDM) concept that lies at the heart of the company’s core platform, Johnson said. The Atomist platform is based on a domain model for software delivery constructed around an application programming interface (API) server and GraphQL, an open source data query and manipulation language. That approach eliminates the need to master, for example, complex YAML files to deliver software. The addition of the visualization tools not only make it easier to see what’s going on in the development environments, but they also make it easier to identify areas where technical debt in the form of bugs and vulnerabilities is building within an application development project, he noted.

The sooner those issues are addressed, the more probable it becomes that DevOps teams will deploy reliable, secure code, rather than needing to update it or roll back the entire application, Johnson added.

Although the Atomist platform is capable of working in any application environment, there’s a high correlation between organizations that have embraced microservices-based on containers and organizations looking to automate software delivery using the Atomist platform, Johnson said. Organizations that embrace microservices based on containers typically have a frequent need to update codebases in production environments, he noted, adding many organizations don’t know the impact that microservices updates have on the rest of the production environment.

In general, there’s been a lot of DevOps progress when it comes to automating continuous integration within the context of application development project. However, automating the delivery of software has proven to be a more elusive goal. As the rate and amount of code being developed continues to accelerate, it’s now only a matter of time before software delivery automation becomes a more pressing issue. Manual deployment processes prone to errors only serve to aggravate application development and deployment backlog at a time when business leaders are demanding IT teams become more agile.

At the very least, tools that enable DevOps teams to visualize the scope of the challenge ahead should help frame a realistic conversation about what’s truly achievable, given the current state of the codebase.

— Mike Vizard

August 28, 2019
Puppet Aims to Automate Vulnerability Remediation

Puppet today unveiled Puppet Remediate software, which makes it easier to prioritize and remediate software vulnerabilities automatically.

Matt Waxman, vice president of products for Puppet, said Puppet Remediate builds on existing automation capabilities in the Puppet platform to make it easier for DevOps teams to focus on addressing vulnerabilities. Most existing approaches to addressing vulnerabilities rely on manual processes that often result in vulnerabilities not being addressed in an especially timely manner, he said.

To accelerate that process, Puppet Remediate identifies vulnerabilities based on their potential severity and then gives DevOps teams the option to automatically remediate all known instances of that vulnerability, said Waxman. Puppet Remediate combines infrastructure data with vulnerability data gathered in real-time from Tenable, Qualys and Rapid7 to prioritize vulnerabilities.

Puppet Remediate will not automatically remediate a vulnerability without the express approval of the DevOps team. That’s critical because in many instances the patch being applied still needs to be tested and vetted by the DevOps team, noted Waxman. Once approved, Puppet Remediate includes four pre-built tasks that allow DevOps teams to address more than 80% of the typical remediation workloads—importance because once a vulnerability is discovered, it’s not uncommon to find that same mistake has been made across many other software modules that have already been built and deployed.

Deployed using Docker containers, Puppet Remediate relies on an agentless approach to vulnerability remediation that adds minimal overhead to either a Linux or Windows application environment, Waxman said. He added the goal is to make it easier for developers or cybersecurity teams to deploy Puppet Remediate on any platform.

Waxman said the primary goal is to help organizations embrace best DevSecOps processes. In the absence of automation, the amount of time allocated to addressing vulnerabilities manually within existing applications often gets short shrift as developers race to meet deadlines for new applications. The irony, of course, is that each new application only serves to increase the number of potential vulnerabilities that need to be addressed. To restore order to vulnerability remediation process, Puppet is making the case for applying a proven IT automation framework to application security management.

It may take a while for organizations to fully embrace automated application vulnerability remediation, but it would seem that, given the chronic shortage of cybersecurity professionals, adoption of these types of platforms is all but inevitable. There simply are not enough skilled cybersecurity professionals available to participate in every aspect of the application development and deployment process.

At the very least, automated vulnerability remediation tools should inform developers of the mistakes being made most often. Over time, the number of instances of those vulnerabilities being discovered should decline as developers realize they are addressing the same issue repeatedly. Once that becomes obvious, hopefully that long-awaited teachable moment that eliminates that particular vulnerability from the application environment is finally at hand.

— Mike Vizard

August 21, 2019
GitLab Survey Surfaces Major DevSecOps Challenges Ahead

A report based on a survey of 4,071 software professionals published this week by GitLab, a provider of a continuous integration and continuous deployment (CI/CD) platform, found that while appreciation of the potential value of DevSecOps best practices is high, the ability to implement those practices is uneven at best.

According to the survey, half of the respondents reported that security vulnerabilities are discovered mostly by the security team rather than developers after code is merged and in a test environment. And, when cybersecurity professionals participate in a DevSecOps process, the survey found those organizations are three times more likely to discover bugs before code is merged. In addition, a full 90% of those organizations are more likely to have tested between 91% and 100% of their code early in the development process.

Obviously, that’s better than discovering them after they’ve been deployed in a production environment. On the downside, however, nearly half of security professionals participating in the GitLab survey (49%) said they struggle to get developers to make remediation of vulnerabilities a priority. That challenge may reflect the overall maturity of the DevSecOps practices in place. For example, only 25% of developers participating in the survey rated their security practices as being good. That compares to only 20% of security professionals who rated their processes as good. Only 14% of respondents said they are relying on application security tools to test more than 91% of their code. A full 44% are using these types of tools to test less than a third of their code.

Priyanka Sharma, director of technology evangelism for GitLab, said the survey makes it clear that DevSecOps is now officially a thing in the enterprise. However, only 44% of the survey respondents said that security vulnerabilities are a performance metric for developers in their organizations. As such, it’s clear there is still a long way to go before anything approaching DevSecOps nirvana is likely to be achieved. In fact, Sharma noted building and deploying more secure applications may require organizations to slow down the rate at which applications are being built, at least initially.

The GitLab survey makes it clear most organizations are still struggling with mastering DevOps. Only 28% of developers said they feel good about their organization’s level of DevOps sophistication, while less than half (45%) said they have been able to implement continuous code deployment at least somewhere in their organization. That level of adoption suggests there still is plenty of opportunity to refine DevOps processes that are not fully ingrained. In fact, it appears most organizations are still trying to master agile development methodologies—more than half of the respondents said they employ Scrum (54%) as their application development methodology, followed by Kanban at 37% and DevOps at 36%.

Ultimately, most organizations will have no choice when it comes to embracing DevSecOps. There simply are not enough cybersecurity professionals available to secure every application on their own. That means developers will need to assume more responsibility for cybersecurity, regardless of whether they like it. DevSecOps processes will be required to validate whether developers have implemented all the security patches and controls required. Anything less than that going forward will be deemed as nothing short of reckless—which, as any lawyer will gladly share, means much higher penalties for everyone involved.

— Mike Vizard

July 17, 2019
HashiCorp Tools Bridge DevOps, Legacy IT Environments

At its HashiConf EU 2019 conference this week, HashiCorp extended the reach of its Terraform Enterprise tools for automating the management of IT infrastructure beyond the realm of DevOps into legacy IT environments.

Via integration with the Service Catalog from ServiceNow, IT administrators working with a traditional ITIL-based framework now can invoke Terraform Enterprise to provision IT services. HashiCorp CTO Armon Dadgar said rather than requiring organizations to hire an infrastructure engineer to automate the provisioning of IT infrastructure, IT administrators now can do the job.

At the same time this week, HashiCorp announced that policy sets may now be configured using the source policies available in multiple version control systems (VCSs), including GitHub, GitLab and Bitbucket. The goal is to make it simpler to enforce policies that would limit, for example, the number of virtual machines a developer might be allowed to spin up within the context of a set of GitOps processes, said Dadgar.

Finally, HashiCorp also announced that HashiCorp Consul service mesh networking software has been enhanced to include Layer 7 application traffic management capabilities alongside integration with the HashiCorp Nomad application and cluster scheduler software.

In general, Dadgar said HashiCorp is moving toward enabling its portfolio of offerings to span multiple types and classes of IT environments. HashiCorp Consul, for example, can be run across both legacy IT environments as well as Kubernetes. Most organizations will need to support both legacy monolithic and microservices applications using a combination of DevOps and legacy ITIL processes, noted Dagar. Rather than having to master new tools for each environment, HashiCorp is making a case for a common set of tooling that can be applied across multiple IT classes of processes.

While some organizations have fully transitioned to DevOps, many more organizations are still struggling to make the transition. Reasons for not making that transition faster range from simple inertia to a lack of skills. Rather than having to take an all-or-nothing approach to modernizing IT processes, Dadgar said HashiCorp is enabling each IT department to embrace IT automation wherever they happen to be on that journey, including being able to embrace new platforms as they become available.

Dadgar noted that level of extensibility is critical because most tools are still being brought into organizations from the bottom up by individual members of the IT staff, rather than being championed from the top down. In the absence of an executive mandate, Dagar said the path of least resistance is to make IT automation tools as accessible as possible to members of the IT team regardless of skill level.

There will, of course, come a day when IT leaders will try to rationalize processes around a common standard set of practices. The degree to which any IT organization has been able to achieve that goal, however, has been mixed at best. In the meantime, IT organizations will always need to keep their options as open and flexible as possible.

— Mike Vizard

July 10, 2019
State of the Software Supply Chain: Secure Coding Takes Spotlight
After almost a year of research that involved studying 36,000 open source software projects, 12,000 enterprise development teams and 3.7 million open source releases, we at Sonatype are excited to share the “2019 State of the Software Supply Chain” report.

This year, we worked with research partners Gene Kim, founder of IT Revolution, and Dr. Stephen Magill, principal scientist at Galois and CEO of Muse, to examine and empirically document objectively for the first time the attributes of exemplary development practices, especially in relation to secure coding practices. But, as in years past, we’ve also analyzed the rapidly expanding supply and continued exponential growth in demand for open source components.

Not All Open Source Projects Are Created Equal

For the past four years, we’ve studied the ins and outs of the software supply chain—what it’s comprised of; how vulnerabilities are getting in and how often; the growing regulations; and, most recently, a new trend in which adversaries are purposely attacking the supply chain with malicious components.

For our fifth anniversary of the report, we wanted to look deeper. We wanted to understand exactly how enterprise development teams—and potentially even more importantly, how OSS projects—were thinking about and addressing the software supply chain security issues. We wanted to understand and identify the very best practices so we could share them with others.

As a result of our research, we identified five common behavior patterns across 36,000 open source development teams. This includes identifying attributes of Large Exemplars and Small Exemplars who rest within the top 3%, or 1,229, OSS project development behaviors.

To arrive at this list, we examined a large number of variables, including:
- Do differences exist in how effectively OSS projects update their dependencies and fix vulnerabilities?
- Are there exemplary teams that do this better than others?
- Are components from exemplary teams more widely used than “non-exemplary” components?
- What factors correlate with exemplary components?
- What advice can be offered to producers of OSS components and the developers that consume them?
The answers were quite striking—and the resulting data even more illuminating. While the report identifies Small Exemplars and Large Exemplars, we’ve also identified three additional groups of OSS projects: Laggards, Features First and Cautious.

Exemplary Commercial DevSecOps Practices Create Superior Software

There are clear, competitive advantages for teams with exemplary DevSecOps practices.

We’ve known for years that innovation is critical, speed is king and open source is at center stage. This research further underscores these accelerating trends throughout the software supply chain. It also shows that taming the supply chain is possible. By making better supplier choices, component selection and using automation, dev teams are seeing impressive rewards. In fact, for those development teams actively managing their software supply chains, the use of known vulnerable component releases was reduced by 55%.

The report details 11 other behaviors and attributes of leading enterprise development teams, including their frequency of software releases, their use of repository managers and their reliance on a software bill of materials.

Gene and Stephen helped shed new light on exemplary development and DevOps practices that I believe will help developers around the world better understand what secure coding means and how to start addressing it.

— Derek E. Weeks
July 5, 2019
5 Tips for Launching New App Features
Are you looking to improve your organization’s mobile app? For some the process may be relatively straightforward. But ensuring you cover all steps correctly will go a long way to a successful app feature release. Here are five practical tips to successfully launch a new app feature.

Include the App Feature Release at the Start

While you’re still in the planning phase for a new feature, it’s a good idea to think about how you will release it. This is something often done within the design process.

Things you should incorporate into this decision include:
- Who will see this app feature first? (Are there internal or external beta groups?)
- How will this feature’s success be measured?
- Who will see the app feature once it’s in a steady state? (Will the feature be only for VIP customers or for everyone?)
- Is there important timing tied to this release, such as an event or special time of the calendar year?
Tools that will help you with this step include product delivery and tracking tools.

Build Awareness

Awareness around a release is important for both internal and external groups. Within your organization, do teams have the support they need to be successful? Think about what your sales, marketing, customer success or any other team will need in terms of understanding the app feature being released, and how to answer any questions they might face. Externally, awareness should be tied back to how you will measure success.

Tools that will help you accomplish this include go-to-market plans, centralized information repositories and any other tools that will help your teams (and customers) stay connected, informed and collaborative.

Measure the Release of the App Feature

After the release has happened, how will you know if it was successful? Because you already thought about success metrics in the planning stage, you should be ready to measure whether the feature was successful or not.

Tools that will help with this include those that surface sales and ops metrics. Also, it’s important to consider these together—look at performance and monitoring metrics, support requests by volume and qualitative feedback from customers and prospects.

Celebrate and Recognize

Take time to celebrate your wins. Shipping software is like exercising a muscle: The more frequently you do it, the easier it is to execute. If you ship less frequently, the process begins to atrophy and the action becomes more difficult. Celebration (even for small wins) motivates to continue practicing the act of shipping and results in more stable services and products.

Reflect and Iterate

Software is never done, and neither is a process for software delivery. After the release has occurred and you’ve paused to enjoy the moment, now it’s time to reflect on what went well and what didn’t. Reflect on both process and product. Tie process back to culture—consider the tools that you use for the process, what enabled you to do more and what was a hindrance. Use this feedback and apply what you learned from measuring success in the planning phase for the next release. Learn how you can adjust and improve upon what you shipped.

— Adam Zimman
June 10, 2019
Citizen Developers Drive Productivity and Innovation

It was once written that “software is eating the world,” “APIs are eating the world” and “APIs are eating software.” In 2019, a more accurate statement might be, “APIs (or application programming interfaces) fuel the software that’s still eating the world.”

In today’s world, there is an ever-constant demand for software, enterprise applications and mobile applications, and most company IT departments can’t keep up. Enter the citizen developer. Citizen developers are helping organizations close the demand gap and innovate more quickly. But who are they and what role do they fill within an organization? And how do they contribute to overall technology innovation within a company?

Citizen Developers and the Need for Speed

The ongoing need to develop software quickly and efficiently has given rise to a new type of developer. A citizen developer is a non-professional developer who builds new business applications using existing tools, development and runtime environments sanctioned by corporate IT. They also can access various online tutorials to learn and master their application-building skills.

Today’s software development environment, powered by APIs, is ripe for the citizen developer. APIs, mobile application development kits and the cloud have created a no-code/low-code, building block-like approach to building software. Less code and a more simplistic software development path allow citizen developers to create much-needed apps quickly. This building-block approach cuts development time, translating to faster time-to-value.

Speed is critical not only in the creation of new apps, but also in the end user experience of these apps. With the building-block model, citizen developers use best-of-breed technologies for each block—making the resulting UX optimal (and fast) for an internal user or customer end user. Internal users are able to use fast, effective search within employee directories, company intranets and project management solutions, for example.

For end users, this need for speed addresses their ever-growing expectations. When someone searches for hotel deals in Phoenix, for example, they expect accurate, personalized and fast results. Even a one- or two-second delay can translate to lost opportunity and revenue.

The Workplace

In the digital workplace, citizen developers serve a key purpose. For starters, they know firsthand about the challenges employees face at work; they also know which applications or tools are critical to getting the job done. These non-IT developers (perhaps in a business or marketing role) help create apps for timesheet entry, productivity tracking, project workflow reporting and more. In one study, 76% of businesses stated that at least some of their apps were developed outside of their IT department—and 20% even stated that most of their applications were created outside of IT.

Citizen developers often use low-code tools or visual tools with some degree of coding required. Low-code allows developers to design and develop software applications with minimal hand-coding, while low-code platforms enable users to build applications with modern user interfaces, integrations and data quickly without writing thousands of lines of complex code. Also, citizen developers may work alongside software developers and database experts to develop apps with custom coding to meet specific enterprise or company needs.

Citizen Developers and IT: Working Together

When citizen developers work alongside IT, two things happen. First, by creating simple apps on their own, they enable IT to focus on developing more complex applications. Second, when building more complicated or customized applications, IT can use citizen developers to derive valuable insight. This data helps with testing or tweaking business app prototypes. With low-code, citizen developers with some technical skill start with a prototype and then can iterate with the IT team during the developer phase and later integration of systems, custom coding and security processes. Also, developers, who are often asked to understand more of the business side of the organization, gain this insight working with workplace citizen developers. And the results are promising: 82% of citizen developers said they witnessed a reduction in inefficient tasks while 71% reported an increase in team productivity.

In the past, IT spearheaded application development projects from beginning to end. Now, with citizen developers becoming an integral part of the workplace, IT’s role changes a bit. While no longer in full control, IT does give recommendations to the business department and selects development components and building blocks.

Just the Beginning

When it comes to search software, citizen developers have the potential to create personalized and customized experiences. While some types of front-end search are simple to create, developing a personalized and customized search experience is more complicated. This is where the current work lies and in doing so, we can build a new community of search-focused citizen developers.

This is only the beginning, as there will always be a demand for developers (both traditionally trained and citizen developers). In the coming years, we will see more citizen developers as there literally aren’t enough engineering schools to train students to meet business demand. They are helping to democratize application and software development across the board—and we can expect to see businesses and consumers continue to benefit.

— Julien Lemoine

May 29, 2019
Adobe Aims to Build Developer Ecosystem

Adobe today outlined an approach to building a developer ecosystem that revolves around open source code, application programming interfaces (APIs) and DevOps processes.

Matt Asay, head of developer ecosystem for Adobe, said in the last few years Adobe has increased its reliance on open source code to deliver offerings such as Adobe Experience Manager, a content management system that incorporates open source code for as much as 65% of its modules. In the course of that effort, the company has made reciprocal code contributions to a variety of open source projects being developed under the auspices of the Apache Software Foundation (ASF), including Apache Sling, a web development framework; Apache Oak, a content repository; Apache Felix, an implementation of a services gateway; and Apache Lucene, a text search engine.

Adobe also recently launched Adobe Experience Cloud, which relies on a variety of open source technologies to create a big data repository on top of which Adobe is encouraging developers to invoke APIs to build applications. Rather than build their own big data repositories, Adobe is making a case for relying on a multitenant big data platform it manages on behalf of customers.

Based on GitHub data, Adobe currently ranks as the 14th largest corporate open source contributor, up from No. 32 in 2017. One of the primary reasons Adobe was able to move up that list so quickly was its move to acquire Magento, an e-commerce platform based heavily on open source code. But now that the company has come to appreciate what can be accomplished by relying on open source code, organizations should expect to see Adobe accelerating the rate at which it will be making contributions to a wide variety of open source projects.

At the same time, Asay said, Adobe is making major investments in developing microservices that it plans to make it possible for developers to consume via its APIs. The Adobe Experience Cloud, for example, is a suite of software-as-a-service (SaaS) applications that employ a common data model deployed on a set of Kubernetes clusters running in the Microsoft Azure cloud.

Asay noted Adobe is trying to make it clear that it has a lot of empathy toward developers committed to open source code. Adobe is a provider of commercial software-as-a-service (SaaS) applications, but it wants to develop a developer ecosystem that consumes the data residing in those applications via its APIs. To foster the development of those applications, Adobe has already signaled it is willing to share best DevOps practices with organizations that commit to invoking those APIs.

Adobe is one of many providers of commercial software that are increasingly dependent on open source code. It will be interesting to see where the line between the desire to use open source projects to build applications and actual open source applications lies in the years ahead. But the one thing that is clear is that without DevOps processes and a well-defined set of APIs to guide them, there’s not much chance any vendor would be able to build a meaningful developer ecosystem of any size.

— Mike Vizard

May 15, 2019