devopsy.kinsta.cloud

Author: Mike Vizard

Infosys Launches Open Source DevOps Project

Infosys has decided to make its DevOps platform—which consists of more than 2,000 prebuilt scripts and more than 150 pipelines spanning 70-plus tools involving more than 25 different classes of technologies—available as an open source project available via GitHub.

Ravi Kumar, president and deputy COO for Infosys, said the global systems integrator has spent the last several years turning each element of its DevOps platform into a set of microservices based on containers that can now be deployed almost anywhere. That decision made it more practical for Infosys to then offer the up the entire DevOps framework it relies on to drive thousands of projects employing more than 200,000 developers as a single open source project, he said. That framework relies on an instance of the open source Jenkins continuous integration/continuous deployment (CI/CD) framework at its core.

Each element of the Infosys DevOps platform can be consumed via a set of templates hat Infosys has developed. The goal is to reduce the amount of time any organization needs to spend developing that framework and processes required to accelerate any digital business transformation project, Kumar noted.

To accelerate the development process, Infosys enables organizations to automate the promotion of any module without having to create any additional scripts. In addition, Infosys makes extensive use of encryption to make sure DevOps workflows are secure.

Most recently, during the DevOps Industry Awards 2018 event, Infosys won awards for Best Overall DevOps Project in the finance, retail and communications, in addition to best automation project and most successful cultural transformation initiative.

Kumar noted that DevOps is now integral to any digital business transformation initiative. Each organization today is required to significantly increase the rate at which applications are developed and updated to create a modern digital experience for customers, employees and business partners, he said.

The single biggest hindrance when it comes to making the transition to DevOps within most organizations is a lack of tools and processes. Most organizations quickly become aware there is a chicken-and-egg relationship between tools and DevOps processes. Without the right set of DevOps tools, it becomes difficult to set up a DevOps process. But the tools in of themselves have no value without a set of well-defined processes in place. To enable organizations to address that issue in a holistic manner, Infosys developed the IT Process Enabler repository alongside a DevOps maturity framework.

Most of the adoption of DevOps within most organizations has been driven by the bottom up by individual development teams resulting in adoption of DevOps that has been uneven at best. But as those individual DevOps initiatives become increasingly successful, there is now a lot of interest at the senior most levels of organizations in finding a way to drive DevOps processes across the entire organization. That requires a level of change process management that tends to proves too elusive for many organizations to achieve on their own.

— Mike Vizard

November 6, 2018
How IBM’s $34B Bid for Red Hat Will Spur DevOps Adoption

IBM’s proposed acquisition of Red Hat for $34 billion will have an immediate impact in raising awareness for a programmatic approach to managing hybrid clouds based on best DevOps practices.

A recent survey published by International Data Corp. (IDC) finds most organizations (64 percent) have already embraced multiple clouds to varying degrees. Only 7 percent of respondents said they have built a truly hybrid cloud. Another 24 percent, however, said they have achieved a high degree of interoperability across multiple clouds. IBM made it clear this week that its primary motivation for acquiring Red Hat was to tap into a trillion-dollar opportunity that will manifest itself as hybrid cloud computing continues to evolve. In fact, IBM is betting that Kubernetes clusters will play a key role in advancing the state of hybrid cloud computing.

But for hybrid cloud computing to take hold, it’s also clear the level of mastery over DevOps within enterprise IT organizations will need to improve substantially. In fact, hybrid cloud computing might not even be the ultimate destination, said CloudBees CEO Sacha Labourey. Enterprise IT is increasingly being defined by programmatic services rather than platforms, he noted, and those services need to be weaved together to drive modern applications. But where each of those services resides is becoming less relevant as organizations become more DevOps proficient, Labourey said, noting the rise of hybrid cloud computing will drive more organizations to embrace DevOps to bring order to the services being consumed.

“Within a hybrid cloud DevOps will be required,” said Labourey.

While platforms are still relevant, they increasingly are being hidden behind services that expose an application programming interface (API), added Chip Childers, CTO of the Cloud Foundry Foundation, which oversees the development of the open source Cloud Foundry platform-as-a-service (PaaS) environment. A developer consuming a service might have little to no idea what platform that service runs on.

“IT teams are building on the abstractions that have gone before,” Childers said.

The ability of one organization to differentiate itself will come down to the maturity of the DevOps processes they rely on to most efficient consume a service, he added.

Demand for that level of DevOps expertise is already starting to accelerate, said Tim Beerman, CTO of Ensono, a provider of managed IT services. As IT continues to transform into microservices enabled by containers and serverless computing frameworks, the complexity of the overall IT environment requires a more sophisticated approach to managing the overall environment, he said.

But, he added, “A lot of organizations simply don’t have the talent.”

Of course, IBM is betting that once it owns Red Hat, more organizations will look to IBM Services for that expertise. But as always, competition across the IT services space remains fierce. IBM is also betting that it will provide the management plane through which hybrid cloud services will be unified. But even there, competition from rivals small and large will be significant. Vendors such as Rackware are already providing frameworks for managing hybrid clouds.

While hybrid cloud computing is still relatively immature, organizations that embrace DevOps will be much further down that path than others, said Todd Matters, chief architect at Rackware.

“DevOps will absolutely be a critical part of hybrid clouds,” he said.

IT has always been about striking a balance between people, process and products. It’s too early to say whether IBM will recoup its $34 billion investment to acquire Red Hat. But the deal inevitably will lead to a greater awareness for a more comprehensive approach to DevOps capable of spanning a hybrid cloud computing environment that includes multiple platforms.

— Mike Vizard

November 2, 2018
IBM Acquires Red Hat to Create DevOps Behemoth

In a move that has massive implications for DevOps teams across the enterprise, IBM today announced it is acquiring Red Hat in a deal valued at $34 billion.

Red Hat will join IBM’s Hybrid Cloud group as a distinct independent unit. Red Hat will continue to be led by Jim Whitehurst and Red Hat’s current management team. Whitehurst will join IBM’s senior management team and report to IBM CEO Ginni Rometty. IBM intends to maintain Red Hat’s headquarters, facilities, brands and services practices.

IBM expects to close the deal, which will be financed using both cash and debt, in the latter half of 2019. IBM also said the deal will be accretive within 12 months after close, as the combined entity moves to address a total market that spans application development and deployment, IT services and security and collectively exceeds $1 trillion, or more than one-fifth of the total global IT market valued at $3.7 trillion in 2018 by Gartner.

IBM and Red Hat have had a partnership in place for 20 years, spanning everything from reselling and supporting Red Hat Enterprise Linux (RHEL) to collaboratively working on open source projects such as Kubernetes.

IBM officials said they expect Red Hat to significantly bolster IBM’s hybrid cloud business, which already generates $19 billion a year in revenues. IBM noted that about 80 percent of application workloads have yet to move to the cloud.

The move to acquire Red Hat comes on the heels of Red Hat acquiring CoreOS, which augments the company’s existing open source expertise with a container management platform built on top of Kubernetes.

Once the deal is closed, IBM said the two companies will remain committed to open source software licensing, including initiatives such as Patent Promise, GPL Cooperation Commitment, the Open Invention Network and the LOT Network.

IBM and Red Hat also plan to continue to build and enhance existing Red Hat partnerships, including those with major cloud providers Amazon Web Services, Microsoft Azure, Google Cloud, Alibaba and others that compete directly with IBM Cloud.

It’s too early to say to what degree those cloud service providers will be open to continuing to work with Red Hat as unit of IBM. In recent months Red Hat increasingly has been positioning itself head to head against VMware, which operates as a unit of Dell Technologies. IBM also has a strong relationship with VMware that could change in the years ahead. What is clear, however, is that any deal of this magnitude usually begets others in very short order.

— Mike Vizard

October 28, 2018
CloudBees Further Extends Jenkins CI/CD Reach

CloudBees announced it is expanding the scope and reach of its Jenkins open source continuous integration/continuous development (CI/CD) platform into the realms of compliance and serverless computing frameworks.

Announced at the DevOps World | Jenkins World conference in Nice, France, a new plugin for Jenkins adds support for the AWS Serverless Application Model (SAM) defined by Amazon Web Services (AWS). That model spans AWS Lambda functions, application programming interfaces and Amazon DynamoDB tables and is natively supported by AWS CloudFormation. The AWS SAM plugin supports both classic FreeStyle jobs and Jenkins Pipeline to make it possible to read and deploy serverless applications.

In effect, CloudBees is making it possible to treat AWS Lambda as a natural extension of any CI/CD pipeline. Longer term, serverless computing frameworks will play a larger role in the cloud-native instance of CloudBees as well.

In the meantime, CloudBees is also extending its CI/CD platform to address compliance issues that arise from identity management. CloudBees Core is now integrated with the LDAP-based directory Google makes available within its Cloud Identity service. This capability makes it possible to centralize user management policies by using the same Google Cloud Identity or G Suite credentials to connect to CloudBees Core.

Christina Noren, chief product officer for CloudBees, noted governance and compliance are becoming much bigger issues within best DevOps practices as more responsibility for security continues to shift left toward developers.

The CloudBees community continues to grow, even as the number of CI/CD rivals continues to expand. At the conference, CloudBees executives revealed the Jenkins community has grown 24 percent in the period Sept. 30, 2017, to September 30, 2018, reaching 192,623 active installations. That number only applies to installations that permit usage information to be transmitted to the Jenkins project, so this number is not representative of the total Jenkins user population. All told, it’s estimated there may be anywhere from 15 million to 23 million developers globally relying on Jenkins. CloudBees also noted the combined number of defined Jenkins Pipeline and other jobs increased during this same annual period, from 10,509,706 million to 20,664,054 million, with Jenkins Pipeline jobs demonstrating growth of 309 percent from last year.

Noren said one of the primary reasons for that continued success is that unlike other CI/CD platforms that provide a highly opinionated framework accessible only as a cloud framework, the Jenkins environment makes it possible to deploy a more flexible framework on-premises or in a public cloud.

Of course, there are still millions of developers that have yet to be exposed to any type of CI/CD framework. But as DevOps practices continue to become the primary method through which application development and deployment is increased, it’s now only a matter of time before most developers are working within the context of a CI/CD platform.

In fact, it’s arguable that those organizations that don’t soon embrace CI/CD platforms will be overwhelmed by rivals capable of updating applications at rates that are increasingly being measured in days and hours versus weeks and months.

— Mike Vizard

October 25, 2018
SAP Embeds Integration Services in PaaS Environment

SAP, at its SAP Tech-Ed Europe 2018 conference, expanded the scope of the integration services it provides within SAP Cloud Platform, the platform-as-a-service (PaaS) environment it provides for building custom applications based on the open source Cloud Foundry project.

Dan Lahl, global vice president of product marketing for SAP Cloud Platform, said SAP is now adding a Content Advisor service that makes use of machine learning algorithms and other forms of artificial intelligence (AI) to recommend what integrations should be created next based on those that have been previously deployed on the platform.

In addition, SAP announced the general availability of SAP Cloud Integration Automation Service, which provides deeper integration with a standard set of metadata SAP is in the process of defining for all its packaged application software, and SAP Cloud Platform Open Connectors, a set of application programming interfaces (APIs) based on code SAP has licensed from Cloud Elements.

SAP also revealed that it will start making an on-premises edition of SAP Cloud Platform available via partners including IBM and Atos beginning in 2019. Lahl said that decision was driven by customers that for either regulatory or intellectual property concerns did not want to deploy custom code on any cloud service. Those efforts become more feasible once SAP finishes porting its distribution of Cloud Foundry to run on top of Kubernetes, which presents a more efficient approach to deploying an application development platform using a cloud-native platform that can run anywhere. While SAP remains committed to Cloud Foundry, the cost and effort of standing up instances of a Cloud Foundry PaaS in its original form are considerable.

Finally, a new SAP Business Partner service on SAP Cloud Platform, planned for general availability in November, will provide access to a set of master data services that simplify access to and orchestration of enterprise business applications. The master data services can be shared and reused for any LOB-specific intelligent business processes to ensures a consistent and comprehensive view of customers, sales and products. In effect, SAP is now providing compliance as a service, said Lahl.

The integration additions to the SAP Cloud Platform should improve performance and help drive down costs, he said, because collectively they eliminate the need to rely on an external integration service when building and deploying applications on SAP Cloud Platform.

SAP has put considerable effort into building out SAP Cloud Platform as part of a strategy that provides a layer of isolation between SAP applications running on the HANA database and custom applications running on Cloud Foundry. That approach enables SAP to deliver a quarterly cadence of updates to both its packaged applications and HANA running on a cloud service without having to worry about the impact those updates might have on custom applications. One of the reasons why so many SAP customers are several releases behind on SAP packaged applications is because they have all been customized extensively in on-premises IT environments.

As part of that effort, SAP is now also making available a series of best practices for implementing DevOps processes across its platforms. It may be a while before organizations that have standardized on SAP platforms master those processes. But modernization of those platforms is now more a matter of when rather than if.

— Mike Vizard

October 24, 2018
Electric Cloud Extends Continuous Delivery Platform

Electric Cloud is making available a software-as-a-service (SaaS) pricing option available for its ElectricFlow application release management and continuous delivery (CD) platform.

In addition, version 8.5 of ElectricFlow adds support for a Kanban-style pipeline view, object tagging for custom reporting and improved searchability and a continuous integration (CI) dashboard to track and analyze build processes, failures and successes.

The SaaS option doesn’t fundamentally change the existing Electric Cloud pricing model as much as it does provide a different location to host ElectricFlow, said Electric Cloud CTO Anders Wallgren. Pricing for ElectricFlow is still based on nodes and the number of users rather than consumption.

The CI dashboard, meanwhile, provides organizations that have one or more types of CI platforms being employed with visibility into, for example, Jenkins, Git and Bamboo pipelines using a single dashboard. Many organizations today have multiple CI pipelines in place largely because of the preferences of individual developer teams, Wallgren noted.

The Kanban-style pipeline also provides a mechanism for managing multiple application development projects based on a just-in-time process originally developed by Toyota that is employed to identify bottlenecks in car manufacturing. That same issue, of course, applies to software development, where the number of dependencies between various modules is increased exponentially. That issue is becoming even more pronounced as organizations move to build and deploy cloud-native applications based on various types of runtimes. DevOps teams now can approve and observe release progress and deployment status within ElectricFlow in near real time, Wallgren said.

Finally, tagging functionality on all objects allows release managers and product owners to create more granular, real-world reports quickly and easily. Universal data segmentation replaces code-based report creation and can be applied across any object type.

Wallgren noted that adoption of DevOps best practices generally continues to advance at uneven rates. Electric Cloud is now working closely with the DevOps Institute on an online training and certification program dubbed Electric Cloud University. The goal is to increase the number of IT teams that are exposed to modern CD processes at whatever pace they choose. Electric Cloud is making four certifications available: Build Accelerator, Test Accelerator, Administrator and Agile Master.

Wallgren said the next major frontier when it comes to continuous delivery will be applying deep- and machine-learning algorithms to tame what has become an exceedingly complex management challenge. DevOps toolchains continuously create vast amounts of data originating from numerous tools, and machine learning algorithms can harness that data to automate a range of DevOps processes in a way that is not only makes those processes more accessible, but also easier to demonstrate how an application release meets a specific compliance mandate. To achieve that goal, Electric Cloud has been embedding more algorithms into every release cycle of ElectricFlow, says Wallgren.

It may take a while longer for algorithms to minimize all the complexity associated with continuous delivery today. But as DevOps continues to evolve, it’s apparent that many of the manual tasks that have often conspired to limit adoption of DevOps will one day soon disappear.

— Mike Vizard

October 23, 2018
Chef Extends Scope of Compliance Automation

Chef has extended the reach of its InSpec compliance automation framework by adding a plug-in architecture that makes it easier for developers to programmatically generate compliance controls that can be applied to automation frameworks. The Terraform configuration management framework developed by HashiCorp is the first framework supported via the plug-in architecture. InSpec previously was integrated with the open source Ansible automation framework.

Julian Dunn, director of product marketing for Chef, said the plug-in architecture supports multiple communications protocols to extend it to multiple frameworks beyond the Chef IT automation framework.

InSpec 3.0 also makes it easier to describe new resources that can be tested in addition to a stable application programming interface (API) that enables DevOps teams to modify how tests are conducted. Improvements to a packaging mechanism for profiles will also make it easier for developers to more easily iterate on InSpec profiles with dependencies.

Finally, InSpec 3.0 adds a key value-based description interface to enable more fine-grained reporting as well as de-duplication of controls that satisfy one or more compliance regimes. This allows organizations to create their own custom metadata categories.

In general, Dunn notes that application development and deployment, thanks to the rise of DevOps, is moving at a pace that exceeds the ability of those tasked with compliance to keep pace. As a result, responsibility for compliance needs to shift left along with other aspects of cybersecurity, said Dunn.

Dunn conceded it is still early days in terms of making that shift. But as more organizations discover that the rate at which applications can be deployed is being held up by compliance audits, the more incentive there is to enable developers to programmatically insert the appropriate controls into their applications. Once those controls are in place, InSpec then generates human-readable code that serves to reduce the amount of time required to pass an audit before and after an application is deployed in a production environment, said Dunn.

Of course, passing a compliance audit doesn’t mean the application is secure. But it does at the very least provide a baseline for what’s required to make an application nominally secure. In fact, the path of least resistance to any shift toward embracing DevSecOps might be automating the processes for putting compliance controls in place.

While there are hundreds of regulations requiring various levels of compliance, it turns out most of them require the same types of controls to be in place. Once organizations begin to programmatically embed those controls within their applications, the speed at which those applications are certified to comply with multiple regulations should increase. There will be less reason for developers to skip a compliance control to meet an application development deadline when that control can be integrated automatically.

None of this means that people with risk management backgrounds will be participating in DevOps processes anytime soon. But it does means that the output from DevOps teams won’t be stacked up waiting to pass a compliance review because all the applications in front of it are missing one key control or another.

— Mike Vizard

October 19, 2018
Akamai Further Extends Reach into DevOps Realm

Akamai is extending its campaign to make content delivery networks (CDNs) a natural extension of DevOps processes by adding more application programming interfaces (APIs) and other automated functions to simplify a variety of tasks.

Specifically, Akamai has added an Akamai Sandbox that makes it simpler to conduct tests within the context of the Akamai continuous integration/continuous deployment (CI/CD) framework.

In addition, the company now makes it possible to cache GraphQL responses using the Akamai application programming interface (API) gateway, which provides a more efficient mechanism for caching REST APIs using the Akamai Intelligent Edge service.

Akamai is also making it possible to run a series of what-if analyses using the mPulse metrics it exposes now all the way down to specific resource levels. That real-time and historical data can be employed within the context of A/B testing on the CDN platform. Akamai has also made available Single Point of Failure (SPOF) protection within the Ion Script Management tool, which makes use of real user performance data to identify problematic first and third-party scripts on a user’s site. SPOF can automatically defers or blocks any scripts that don’t meet standards for performance.

Finally, Akamai has added an API for securing entire web application footprints within a Bot Manager tools, in addition to support for OAuth protocols for securing API calls.

Ari Weil, vice president of product marketing at Akamai, said the CI/CD framework that Akamai provides makes it possible to push updates to multiple CDNs. Akamai obviously would prefer all those CDNs to be provided by Akamai, but it recognizes that, in many instances, organizations will be taking advantage of CDNs provided by cloud service providers alongside Akamai, he said.

Weil noted that Akamai is trying to position its CDN as the first tier on which a wide variety of applications will be deployed and secured. Rather than deploying those applications on a local web server, the Akamai CDN provides a layer of isolation between cybersecurity attacks aimed at web applications and the infrastructure the rest of the enterprise relies on, said Weil. As part of that effort, Akamai has been exposing its CI/CD platform with the CDN, which organizations can employ to apply DevOps processes to applications that are deployed and updated on the Akamai CDN.

Many of the DevOps motions these days assume the application will be deployed either on a public cloud or in an on-premises IT environment. Akamai contends that a CDN not only provides a better platform for deploying and managing distributed applications, but those applications will be inherently more secure as Akamai absorbs the brunt of a distributed denial of service (DDoS) attack, for example, and less costly as the amount of data that needs to be moved in and out of a public cloud sharply declines.

Naturally, not every developer may fully appreciate the role CDNs can play within the context of a larger set of DevOps processes. But as applications become more distributed, there may come a day when the CDN service chosen winds up being a lot more relevant than any of the platforms being connected to the web.

— Mike Vizard

October 17, 2018
IBM Survey: Rise of Multi-Cloud Computing to Force DevOps Issue

A survey of 1,106 business and technology executives published this week by the IBM Institute for Business Value finds 85 percent of companies are already operating in multi-cloud environments, with 98 percent forecasting they will be using multiple hybrid clouds within three years. But the survey finds that only 39 percent of the respondents have implemented some level of DevOps processes to help streamline the management of multiple cloud computing platforms.

Blaine Dolph, vice president of Global Business Services for IBM, said it’s clear that DevOps will play a critical role in enabling IT organizations to centralize the management of multiple clouds. But the IBM survey suggests that the management of multiple clouds within organizations is not nearly as efficient as it should be.

Only 41 percent of survey respondents said they currently have a multi-cloud management strategy in place, and just 38 percent have the procedures and tools in place to operate a multi-cloud environment. Only 30 percent of enterprises have a multi-cloud orchestrator or other multi-cloud management platform to choreograph workloads, while fewer than 40 percent of organizations have cloud configuration management tools that provide information about resource configuration and relationships between resources, the survey found.

All told, the IBM survey is only able to identify 20 percent of respondents as “multi-cloud maestros” capable of employing multiple clouds to smoothly and routinely deliver one or more business functions. The survey found almost two-thirds of multi- cloud maestros report they employ cloud management platforms.

The survey also found that multi-cloud maestros are advanced in terms of adoption of microservices and containers. A full 61 percent of multi-cloud maestros predicted that within three years at least 80 percent of new applications will be developed using containers. Currently, 50 percent of multi-cloud maestros are using Docker containers and 63 percent are using containers as a service (CaaS). By 2021, 65 percent expect to use container orchestration. More than half (56 percent) of the multi-cloud maestros are already microservices and 59 percent plan to use serverless cloud services in their cloud environments, according to the survey results.

Dolph said IT organizations in general would be well-advised to focus on more than just “lifting and shifting” applications into the cloud. They may need to leverage Docker containers to move an application into the cloud. But once there, an effort should be made to modernize that application by turning large swaths of it into a set of microservices that ultimately are easier to maintain and consume by developers building complementary applications, he said.

The IBM survey makes it apparent that multiple clouds are the new IT normal. Almost half of respondents said they are establishing a multi-cloud architecture to develop new and enhanced products and services. A total of 62 percent of respondents require multiple clouds to create innovative business models, while 52 percent said they need them to produce new revenue streams. Sixty-six percent need them to enhance margin and 46 percent said they need a multi-cloud environment to support agile business processes.

From a DevOps perspective, more than half (51 percent) of respondents use multiple clouds to cultivate a flexible, modular infrastructure that quickly absorbs and leverages technological advances.

Obviously, one of the great paradoxes of multi-cloud computing is that in the pursuit of becoming more agile, many organizations are making their IT environments more complex by employing multiple platforms. The challenge they will face next is maturing their DevOps processes to the point where some order is finally brought to that multi-cloud computing chaos.

— Mike Vizard

October 17, 2018
Adobe Looks to Drive DevOps Adoption via the Cloud

Adobe has been building out a managed service that includes continuous integration/continuous development capabilities on the Adobe cloud service. Now Adobe is extending the DevOps processes enabled by its CI/CD platform to make them more customizable in addition to expanding the scope of the application development tools it provides to include support for single page application (SPA) JavaScript frameworks.

Haresh Kumar, director of strategy and product marketing for mobile and connected experiences at Adobe, said DevOps processes are now an integral part of how Adobe enables customers to build a custom application experience using low-code tools it provides in Adobe Cloud. In the case of Adobe, that DevOps framework is made available via Cloud Manager, a feature of Experience Manager Managed Services that enables the streamlining of code development across staging and production environments in addition to providing code inspection, security validation and performance testing capabilities. Developers can now customize their CI/CD pipeline within Cloud Manager against specific key performance indicators (KPIs) they define.

Meanwhile, Kumar said the SPA Editor that Adobe provides is unique because front-end developers can preview a SPA to view JavaScript code and edit content including images, video and text. With this new capability, SPA content can be more easily edited and managed within the context of a business process, he said. The SPA Editor provided within Adobe Experience Manager currently supports the React and Angular frameworks, with plans to extend its reach to other frameworks underway.

While most IT professionals tend to think of DevOps processes only applying to large-scale applications, Kumar said it turns out that as organizations rely more on cloud services, vendors such as Adobe are exposing customers who want to create applications to a variety of best practices related to DevOps embedded within the cloud service. Many of the developers creating those applications may not recognize they are participating in a DevOps process, but Kumar noted that as more custom applications get developed on the Adobe platform, the number of web developers and content authors being exposed to DevOps process is starting to increase exponentially. It’s even probable many of those developers will be first exposed to DevOps processes within the context of a cloud service long before they encounter them within the context of their internal IT environments.

Kumar said a DevOps process managed by Adobe is enabling many organizations to smooth out what otherwise often can be a choppy digital business transformation. Building a new generation of customer experience applications requires access to modern tools that can transcend organizational silos spanning data that resides in sales, marketing and financial applications. Last month, Adobe announced it is acquiring Marketo, a marketing automation platform to facilitate that transition. Once that deal is closed, the DevOps framework Adobe has developed in the cloud will be extended to include the Marketo platform.

It’s hard to say to what degree Adobe will be able to drive adoption of DevOps processes across the Adobe Cloud platform. What might be even more interesting to see is how many of the organizations that rely on Adobe Cloud to develop applications will even realize they made the transition to DevOps.

— Mike Vizard

October 15, 2018