devopsy.kinsta.cloud

Author: Mike Vizard

SnapLogic Extends DevOps Reach via GitHub

SnapLogic has extended the reach of its SnapLogic Enterprise Integration Cloud into the realm of DevOps by making it possible to store integrations creating using Snap connectors in GitHub.

The company also announced integration with the DC/OS platform from Mesosphere along with a new service catalog and several updates to the Iris artificial intelligence (AI) software it uses make recommendations concerning the construction of integration pipelines. At the same time, SnapLogic has enhanced both its monitoring tools for application programming interfaces (APIs) and search tools for discovering broken integration pipelines.

Craig Stewart, vice president of product management for SnapLogic, said support for GitHub makes it easier for developers at all skill levels to share preconfigured integrations via GitHub alongside all the other code they already share via the widely employed repository. That capability also makes it easier for DevOps teams to include preconfigured Snap connectors within a continuous integration/continuous development (CI/CD) pipeline, he noted, adding those integrations now can be more easily discovered within a Patterns Catalog to help developers discover and reuse integration patterns.

Support for Mesosphere, Stewart said, is being provided by customer request. That effort will then be extended to include support for Kubernetes, which SnapLogic expects will become the de facto standard for container orchestration engine.

Finally, SnapLogic updated its Iris AI software to provide an additional option for users to build their integration workflows starting with the last Snap of the integration pipeline. Previously, the Iris recommendation engine started with the first Snap connector. Now, when a user first places the last Snap on the canvas, the Integration Assistant will display suggested previous Snaps until the pipeline is complete. Users also have the option to start with the first and last Snaps of the pipeline and the Integration Assistant will work from the outside-in to recommend Snaps to build out the entire pipeline.

SnapLogic is making investments designed to facilitate self-service capabilities that promote reuse of integrations, Stewart said. A recent survey of 500 IT decision-makers conducted by Vanson Bourne on behalf of SnapLogic finds on average organizations expect to generate a 547 percent return on their data investments, increasing revenue by an average $5.2 million by using data more effectively. But the survey also finds that on average organizations are using only half (51 percent) the data they collect or generate, and data drives less than half (48 percent) of the decisions being made. Organizations will spend $1.7 million on an average to operationalize data over the next five years to rectify that problem, according to the survey results, which is more than double what they currently spend.

Much of that effort will be driven by so-called citizen integrators that reside within various lines of business outside the traditional IT department. In many cases those citizen integrators will be leveraging prebuilt integration patterns created by developer working within the internal IT department. The challenge now is finding a way to make sure all those integration patterns can be slipstreamed into a larger set of DevOps processes that are increasingly spanning the entire enterprise.

— Mike Vizard

August 17, 2018
Netifi Rises to Microservices Integration Challenge

Netifi this week launched an integration platform based on the open source RSocket communications protocol to replace HTTP ad REST application programming interfaces (APIs) as the mechanism for connecting microservices. RSocket was originally created by Netflix and is now being strengthened via contributions from Netifi, Facebook and Pivotal Software for use within enterprise IT organizations.

Fresh off raising $2 million in seed funding, Netifi is also committing to support a community edition of RSocket later this year.

Company CEO Robert Roeser said the Netifi platform is designed to make it easier to build microservices and interconnect them. Most of those microservices are being built using Docker containers, but Roeser said that, as part of a polyglot approach to integration, Netifi is leveraging RSocket to connect microservices built using a variety of runtimes as well as provide access to legacy monolithic applications. The Netifi platform can be deployed on-premises, in a public cloud or in a hybrid fashion.

Roeser said RSocket was born of necessity at Netflix because the number of microservices that needed to be interconnected at scale was simply too complex a task using HTTP and REST APIs. Soon after, Facebook also started employing RSocket and now Netifi and Pivotal are making contributions designed to make Rocket more accessible for traditional enterprise developers. In the case of Netifi, that means providing mechanisms to both discover and advertise microservices and provide a layer of abstraction that shields developers from the underlying complexity of the network underlay, he said.

As applications based on microservices become more widely distributed, enterprise organizations tend to become more intimidated by the challenges associated with managing them at scale. Traditional enterprise IT organizations don’t have access to a small army of software engineers to solve the problem. As a result, many of them retreat to building monolithic applications in which all the services that need to be accessed are baked into the application itself. They typically sacrifice scale and flexibility in favor of a construct that is both familiar and easier for them to navigate, Roeser said.

The challenge Netifi and other supporters of RSocket will face is the considerable amount of inertia surrounding REST APIs and HTTP. Several generations of developers now consider REST APIs to be the default mechanism for connecting various applications together. The issue many of them will need to wrestle with is the extent to which the rise of microservices breaks that integration construct. A shift away from REST APIs also could have significant implications regarding how services are exposed externally, how pipelines are constructed within DevOps environments and other factors.

It remains to be seen whether integration platforms based on RSocket or some other approach ultimately makes microservices more accessible to enterprise IT organizations. But significant resources now are being poured in to solve the problem, many of which leverage contributions of companies, such as Netflix and Facebook, that already rely on thousands of microservices to deliver a broad range of cloud-native applications.

— Mike Vizard

August 17, 2018
OverOps Brings Machine Learning to DevOps

OverOps has launched a namesake platform employing machine learning algorithms to capture data from an IT environment that identify potential issues before a DevOps team decides to promote an application into production.

Company CTO Tal Weiss said the OverOps Platform is unique in that, rather than relying on log data, it combines static and dynamic analysis of code as it executes to detect issue. That data then can be accessed either via dashboards or shared with other tools via an open application programming interface (API). The dashboards included with the OverOps Platform are based on open source project Grafana software.

That approach makes it possible to advance usage of artificial intelligence (AI) within IT operations without necessarily requiring that every tool in a DevOps pipeline be upgraded to include support for machine learning algorithms, Weiss said.

OverOps also includes in the platform access to an AWS Lambda-based framework or separate on-premises serverless computing framework to enable DevOps teams to also create their own custom functions and workflows.

Weiss said OverOps is designed to capture machine data about every error and exception at the moment they occur, including details such as the value of all variables across the execution stack, the frequency and failure rate of each error, the classification of new and reintroduced errors and the associated release numbers for each event. Log data is, by comparison, relatively shallow in that it is challenging to determine precise root cause analysis when trying to troubleshoot an issue, he said, noting the OverOps Platform offers visibility into the uncaught and swallowed exceptions that would otherwise be unavailable in log files.

DevOps teams spend an inordinate amount of time analyzing log files in the hopes of discovering an anomaly. But as IT environments continue to scale out, the practicality of analyzing millions, possibly even billions, of log files becomes impractical. OverOps is making the case for employing machine learning algorithms to analyze events before the log file is even created, which eliminates the need to find some way to store log files before they can be analyzed.

There’s naturally a lot of trepidation when it comes to anything to do with machine learning algorithms and other form of AI to manage IT. But as the complexity of IT environments continues to increase, it’s clear DevOps teams will need to rely more on AI to mange IT at levels of scale that were once considered unimaginable. For example, while microservices based on containers may accelerate the rate at which applications can be developed and updated, they also can introduce a phenomenal amount of operational complexity. Most DevOps professionals would rather automate as much as possible the manual labor associated with operations, especially if that leads to more certainty about the quality of the software being promoted into a production environment.

Of course, while making use of machine learning algorithms to analyze code represents a step forward in terms of automation, it’s still a very long way from eliminating the need for DevOps teams altogether.

— Mike Vizard

August 16, 2018
Siemens Acquires Mendix to Advance Low-Code Platform Adoption

Siemens this week moved to substantially accelerate its transition into becoming a software company by acquiring Mendix, a provider of low-code application development tools, for $730 million in cash.

Mendix CEO Derek Roos said Mendix will operate as a business unit of Siemens, which has poured more than $10 billion over the last decade to software development as part of an ongoing digital transformation to a multibillion-dollar conglomerate.

Siemens over the last year determined that Mendix was now a strategic component of that initiative, Roos said, as more applications are shifted to and developed in the cloud. Many Siemens employees already use Mendix tools to develop custom applications with limited to no programming skills. That capability is especially critical in line of business (LOB) organizations that are starting to deploy their internet of things (IoT) applications, he noted. Mendix also recently revealed it is starting to infuse its low-code application development platform with artificial intelligence (AI) capabilities.

Roos said the $730 million investment Siemens is making to acquire Mendix is larger than all the venture capital investments made in rival companies delivering low-code platforms combined. As low-code tools have gained mainstream adoption, however, Mendix increasingly finds itself competing directly with larger rivals such as Microsoft and Salesforce, he noted.

The Siemens decision to acquire Mendix comes at a time when archrival GE is throttling back on digital process transformation efforts. Roos said GE’s decision is unique to structural issues within GE versus being a decision that reflects loss of faith in digital process transformation driven by custom application development. Software is now the fastest growing segment of the Siemens conglomerate, he said.

A recent survey conducted by Mendix in collaboration with ASUG, an end user association for organizations that have deployed software from SAP, finds 64 percent of respondents are experiencing increased demand for custom applications within their organizations. The primary problem is that same survey finds the average custom application development backlog is 24 months. Primary issues cited by survey respondents include high development costs (50 percent), difficulty integrating with existing systems (47 percent) and lack of skilled development resources (45 percent).

Of course, as Siemens becomes a larger software force, some organizations will start will take into consideration how much they may compete with the company before selecting an application development platform. Mendix is betting that as application development expands well beyond internal IT organizations, its status as an independent business unit of Siemens will provide enough distance between Mendix and Siemens business units that a Mendix customer might compete against.

In the meantime, organizations that are embracing low-code platforms are simultaneously increasing their investments in DevOps processes. As the number of applications being developed using low-code tools increases, there is a corresponding increase in application release management that requires them to modernize those processes. As Mendix plays the role in enabling applications that can be deployed from the cloud to the network edge, it’s now only a matter of time before the Mendix low-code platform becomes a more significant element of a larger set of DevOps processes driving digital process transformation projects as unprecedented levels of scale.

— Mike Vizard

August 2, 2018
Accenture Aims to Infuse AI into App Testing

Accenture plans to infuse greater amounts of artificial intelligence into application development testing following its acquisition of Real Time Analytics Platform Inc., which provides tools that make use of machine learning algorithms, neural networks and natural language processing (NLP) to analyze every stage of the software development life cycle.

Kishore Durg, senior managing director and growth and strategy lead for Accenture Technology, the IT services arm of Accenture, will incorporate the AI technologies developed by Real Rime Analytics Platform into the Accenture Touchless Testing Platform, which is a suite of open source and proprietary testing tools that Accenture has infused with advanced analytics and cognitive computing technologies.

Durg said Accenture is committed to automating application testing using AI technologies to help organizations increase the productivity of application development teams. At a time when organizations are investing in a broad range of digital transformation projects, the rate at which applications can be built, tested and deployed has become a critical issue.

Most organizations on their own won’t be able to aggregate enough data to drive machine learning algorithms and neural networks to drive a meaningful AI model. Those models require access to massive amounts of data to be trained to identify potential issues within any application. Because of the size and scope of the projects Accenture works on, organizations that employ its service can benefit from all the data that Accenture can bring to bear to train AI models, Durg noted.

The quality of the data used to train those AI models is also as important as the amount of data, added Durg. Accenture has the resources required to cleanse data before it gets fed into an AI model, as well the expertise needed to eliminate any biases that might get built into any algorithm being applied to that data, he said.

As AI continues to evolve, it won’t be long before every application incorporates some form of an AI model. Each of those models not only needs to be trained, but they also need to be updated continually—and eventually replaced by more sophisticated models as more data becomes available. In effect, that requirement will create a need to extend DevOps processes to how AI models are incorporated within an application.

At the same time, it’s clear that large swaths of DevOps processes involving, for example, application testing can be increasingly automated using a variety of machine learning and network networks, also known as deep learning algorithms.

In theory, that should accelerate the rate at which applications are developed and deployed, while testing processes that are augmented by AI technologies should result in applications that are more secure, as many more vulnerabilities will be discovered long before an application gets deployed in a production environment.

In fact, the inclusion of advanced algorithms across a DevOps toolchain might accelerate adoption of DevOps processes. After all, most IT organizations today have embraced DevOps unevenly largely because of the complexity involved. AI technologies one day soon may eliminate that issue altogether.

— Mike Vizard

August 2, 2018
Compuware Adds Testing Tools to DevOps for Mainframe Portfolio

Compuware is extending its ongoing campaign to bring DevOps processes to the mainframe by acquiring XaTester, a provider of tools for creating unit tests for both batch and CICS-based programs written in COBOL, PL/I and Assembler.

In addition, Compuware announced it has formed an alliance with Parasoft, a provider of tools for testing application programming interface (API) calls between mainframe and non-mainframe systems.

Finally, Compuware revealed it has added support for automated unit testing for the IBM Management System (IMS), a hierarchical database that is used to run both transaction and batch-oriented applications.

Those latest editions come on the heels of an update to the Topaz for Total Test platform that, among other things, make it easier to extract data from mainframe applications.

Compuware CEO Chris O’Malley said all these new capabilities will expand the reach and scope of Topaz for Total Test platform that makes it possible to apply DevOps practices to both new and legacy applications being developed and deployed on IBM mainframe platforms.

Despite being more than five decades old, O’Malley noted that mainframes are still widely employed to process both transaction and batch-oriented applications at a level of scale other platforms still can’t match. The challenge now is to integrate the wealth of applications running on IBM mainframes within the context of a modern application development process, he said. That requires putting new application development and deployment tools in place that are optimized for DevOps versus traditional waterfall approaches still widely used in mainframe environments.

CICS and IMS applications are at the heart of some of the fastest transaction processing applications running in the enterprise. Rather than rewrite those applications, O’Malley said organizations that have invested in mainframes want to be able to expose those applications as a service using APIs. Testing those integrations requires mainframe teams to adopt frameworks that enable them to become more agile, he noted—for example, organizations integrating applications need to be able to easily engage in A/B testing to be able optimize performance.

As the lines between mainframes and distributed computing systems continues to blur, most organizations are working toward having one team support both platforms. As part of that effort organizations are introducing DevOps practices that have proven themselves on distributed computing platforms to mainframes. That approach helps mitigate a mainframe skills shortage that is occurring as more IT professionals with mainframe skills leave the workforce.

It may take a little extra effort to get IT staffs managing mainframes to part ways with legacy approaches to building and deploying applications that have clearly stood the test of time. But as more organizations embrace digital process transformation the rate of change in mainframe environments clearly need to accelerate, O’Malley said.

In fact, IT professionals with mainframe skills that are also literate when it comes to DevOps just might find themselves among the most sought-after people in enterprise IT. After all, the number of IT professionals that can play both side of the mainframe and distributed systems ball are very few indeed.

— Mike Vizard

July 25, 2018
HPE Brings Storage Deeper into DevOps Realm

Hewlett-Packard Enterprise (HPE) today moved to bring storage further into the realm of DevOps by integrating its 3PAR storage systems with VMware vRealize Orchestration software, open source Kubernetes container orchestration software and the Red Hat OpenShift platform-as-a-service (PaaS) environment built on top of Kubernetes. HPE 3PAR storage systems already support Docker containers and the DC/OS private cloud platform from Mesosphere.

In addition, HPE is making available pre-built blueprints for Chef, Puppet and Ansible automation frameworks, as well as software development kits written in Ruby and Python that can be used to create custom integrations.

Finally, HPE announced that HPE InfoSight, a cloud-based service that employs machine learning algorithms to predict when a drive might be about to fail or when application performance might be adversely impacted by I/O contention. HPE gained the core technology for that service when it acquired Nimble Storage last year.

Vish Mulchand, senior director of product management and marketing for HPE Storage, said machine learning algorithms and other forms of artificial intelligence (AI) will soon be playing a much larger DevOps role. Research indicates that more than half of all support issues involve storage systems, and AI technologies will be able to identify most of those issues long before they impact applications, he says.

Mulchand notes HPE has been adding integrations with various DevOps and container technologies to make it easier to scale applications as needed. The goal, he says, is to make storage management a more natural extension of any set of DevOps processes.

In general, providers of storage systems have been investing heavily in automation frameworks designed to make it easier for storage administrators to manage ever increasing amounts of data. The next challenge facing IT organizations is to be able to provision storage resources in a way that doesn’t hamper the rate at which those applications might be deployed.

It’s not clear to what degree storage administrators will be subsumed into DevOps teams. In most cases, storage administrators are looking to make available a pre-determined set of storage resources available to developers on a self-service basis. The amount of those resources is determined by the characteristics of the application, which storage administrators can gain earlier access into by participating in the DevOps process.

Going forward, Mulchand says HPE expects competition between storage vendors increasingly will be defined by the quality of experience they provide IT organizations rather than the performance of the storage systems. Every storage vendor has embraced Flash storage systems that can address the performance requirements of just about any type of application workload, he says, so making it easier to access those storage resources and make sure they are constantly available is the next major opportunity.

As more automation gets introduced into IT environments, there’s no doubt the role of the average storage administrator will change. Rather than manually provisioning resources, storage administrators will be able to develop policies for classes of applications that are automatically implemented whenever storage systems need to be provisioned. As storage administrators learn the characteristics of those application in a production environment, those policies will be further fine-tuned. The good news is that storage itself no longer needs to be seen as a bottleneck from either a performance or DevOps perspective.

— Mike Vizard

July 24, 2018
CloudBees Expands Visibility into DevOps Processes

CloudBees has moved to bring some order to the potential DevOps chaos via an update to CloudBees DevOptics, a monitoring tool for tracking stages of the software delivery process in real time.

The update to the software-as-a-service (SaaS) application adds capabilities that identify everything from potential bottlenecks to periods of inactivity that might be better allocated to maintenance activities.

Michael Baldani, product marketing manager for CloudBees, said CloudBees DevOptics makes it possible to create benchmarks that track DevOps performance across the entire software delivery life cycle, including deployment frequencies, lead time to committing code into production environment, mean time to recover from failures and change failure rates. The “2017 State of DevOps Report” identifies these four most important metrics for a DevOps team to track.

Armed with those insights, a DevOps team is capable of drilling down into a specific issue to make more informed decisions concerning how best to optimize processes, said Baldani, noting that longer term, CloudBees DevOptics also sets the stage for eventually applying machine learning algorithms to processes.

The rate at which organizations have been making the transition to DevOps has been uneven at best. Much of that issue can be traced back to a lack of visibility into how specific processes are being employed, Baldani said. The analytics capabilities provided via CloudBees DevOptics should help organizations accelerate the transition to DevOps by enabling organizations to more easily identify areas where they need to optimize DevOps best practices, he said.

Traditional enterprise IT organizations are still wedded to legacy approaches to software development largely because of inertia. CloudBees DevOptics provides an analytics application that, in addition to helping optimize DevOps processes, provides access to dashboards through which a DevOps process can be shown conclusively to be more efficient than, for example, an existing waterfall approach.

Most organizations are embracing DevOps from the bottom up as individual teams launch various application development projects. As those teams start to deliver applications faster, it’s usually not too long before senior managers want to replicate that success across the rest of the organization. CloudBees DevOptics provides a mechanism through which the best practices implemented by various teams can be captured to facilitate sharing them with other teams. The biggest challenge facing most organizations today is not so much being convinced they can benefit from DevOps, but rather how precisely to go about it.

It may take a while longer for DevOps processes to become the most widely used approach to developing software in the enterprise. But as more organizations continue to appreciate how dependent they are on software to manage increasingly digital processes, the need to accelerate the rate at which software is being developed becomes more apparent. CloudBees is betting that access to real-time analytics will be a major factor in any decision to standardize on a continuous integration/continuous deployment (CI/CD) platform by providing visibility into how software development ultimately impacts the business. After all, it’s now only a matter of time before some new or existing rival leverages software to create a competitive edge. In fact, it’s already been proven time and again that the rate at which organizations can create and deliver quality applications is critical to the overall customer experience.

— Mike Vizard

July 24, 2018
Survey Finds DevOps Playing Key Role in Cloud Migration

A survey of 450 C-level and VP/director-level technology leaders in the United States, UK and Canada conducted by 451 Research on behalf of Skytap, a cloud service provider, found that lifting and shifting existing applications into the cloud is giving way to either refactoring and rewriting those applications to take advantage of cloud-native technologies.

According to the survey results, 67 percent of respondents plan to migrate or modernize at least half of their on-premises applications in the next 12 to 24 months. The survey found 28 percent of respondents plan to refactor applications using a mix of cloud-native and traditional technologies, while another 20 percent plan to adopt some form of a platform-as-a-service (PaaS) environment. That compares to 20 percent who plan to lift and shift existing applications into the cloud with no changes to the underlying code. Another 20 percent said they will replace existing applications with software-as-a-service (SaaS) applications.

Jay Lyman, an industry analyst for 451 Research, said the survey makes it clear that, when it comes to lifting and shifting applications into the public cloud, too many organizations are still engaged in “wishful thinking.” Most applications migrating to the cloud will need to reworked to one degree or another, Lyman said.

The survey found that only 20 percent of respondents plan to move 75 percent or more of their applications to a cloud platform in the next 12 to 24 months. Just less than half (47 percent) said they would migrate somewhere between 50 percent to 75 percent of their applications.

In terms of methodologies that will be employed to achieve that goal, 54 percent of respondents said they were already relying on DevOps processes, while 46 percent said they are relying on agile methodologies. In terms of talent, 55 percent said they are looking to acquire or retain IT professionals with cloud migration expertise, followed by 52 percent who cited application modernization using cloud services. DevOps skills and multi-cloud operations expertise tied for third at 50 percent.

Just over a third (37 percent) also noted that decisions concerning where best to place a workload were being driven primarily by where an application would run best, while 26 percent said decisions were driven by identifying the best-of-breed cloud-native service. Only 19 percent said their organizations would be employing multiple public cloud service providers. In fact, Lyman noted that while hybrid cloud computing remains the dream state most IT organizations want to achieve, the reality is that most of them will be managing multiple clouds in isolation for many years to come.

More than 80 percent of survey respondents reported managing more than 100 applications, with 74 percent stating at least half of these applications are on-premises. A full 71 percent of respondents said more than half of their on-premises applications are mission-critical. A little over half of the respondents said core business applications including customer relationship management (CRM), enterprise resource planning (ERP), and data analytics were least-suited for hyperscale clouds. According to the survey, the biggest challenge associated with deploying applications in the cloud today remains security (56 percent).

The Skytap survey makes it clear IT organizations are still severely challenged when it comes to migrating applications to the cloud for want of skills. Most applications are not easily migrated, which makes reworking them for deployment in a cloud environment a high priority. In the absence of those skills, however, it’s also apparent that any migration of applications to the cloud is going to occur over an extended amount of time.

— Mike Vizard

July 11, 2018
SUSE Preps Independent DevOps Path

Once SUSE completes a separation from Micro Focus sometime next year, the goal for the again independent company will be to drive continued investments in a range of open source technologies that collectively advance DevOps.

Michael Miller, president of strategy, alliances and marketing for SUSE, said the acquisition by EQT, a private investment firm, is part of a three-to-five-year plan to invest in technologies that complement existing SUSE products and services. Core products and services are centered around a distribution of Linux, the OpenStack cloud management framework, the Cloud Foundry platform-as-a-service (PaaS) environment and Kubernetes container orchestration software, he said.

As part of that strategy, Miller said that may mean acquiring complementary open source or proprietary security and management technologies. Any proprietary technology that SUSE would acquire would be turned into an open source project later, he said.

Because it has been operating as an independent business unit, no one should expect to see any significant changes to the overall SUSE strategy beyond making additional investments in products and services or how the company will be going to market in 2019, he noted.

At the core of its strategy is a portfolio of open source PaaS and container-as-as-service (CaaS) environments that organizations of all sizes are employing to drive digital process transformation using custom applications that have now easier to deploy and maintain, Miller said.

Unlike many other investments involving private equity firms, EQT’s decision to acquire the company is being driven by a desire to invest for the long term rather than sell assets off in a piecemeal fashion, Miller noted. Micro Focus this week agreed to sell SUSE to EQT for $2.54 billion in part to help pay for the software assets it gained following a $8.8 billion merger with the software business unit of Hewlett-Packard Enterprise (HPE). The company has been part of Attachmate, which Micro Focus acquired in 2014. Earlier this year, Micro Focus CEO Chris Hsu was replaced by Stephen Murdoch, who was COO of Micro Focus.

Once the deal closes, SUSE will become an independent company for the first time since 2003, when it was acquired by Novell. Attachmate acquired Novell in 2010.

It remains to be seen whether SUSE will be spun out as public company or sold off to yet another vendor. For now, however, it may end up with more resources to combat its rivals, including Red Hat, than it would have had as a unit of Micro Focus.

In the meantime, the company—much like Red Hat—should continue to benefit from the massive amounts of research and development being poured into projects such as Kubernetes and OpenStack. At the same time, it continues to invest in Linux. The company recently released SUSE Linux Enterprise 15, SUSE Manager 3.2 and SUSE Linux Enterprise High Performance Computing 15 as part of an effort to drive a multimodal IT strategy around a common code base that includes MicroOS, which is optimized for containers and makes use of the same code base as SUSE Enterprise Linux.

While Red Hat may be the dominant provider of open source operating systems, SUSE has not given up. Meanwhile, the battle for control over open source PaaS and CaaS environments is still in its early stages. In fact, DevOps teams distributed across the enterprise most likely will determine the ultimate victor.

— Mike Vizard

July 6, 2018