- Home
- >
- DevOps News
- >
- How SAP Views The Role of Open Source within the Enterprise – InApps Technology 2022
How SAP Views The Role of Open Source within the Enterprise – InApps Technology is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn How SAP Views The Role of Open Source within the Enterprise – InApps Technology in today’s post !
Read more about How SAP Views The Role of Open Source within the Enterprise – InApps Technology at Wikipedia
You can find content about How SAP Views The Role of Open Source within the Enterprise – InApps Technology from the Wikipedia website
IT pioneer SAP remains one of the world’s largest proprietary software companies, while the multinational enterprise resource planning (ERP) powerhouse’s evolution has become very cloud- and open source centric. Over the last decade, for example, SAP has spent over $75 billion supplementing its existing portfolio, as well as building on its burgeoning cloud business. The Cloud Foundry, of course, will continue to serve as a cornerstone of SAP’s cloud offering, both for its internal operations and development as well as for its Who’s Who list of Fortune 500 customers worldwide. As long-time supporter and proponent of open source and Kubernetes, SAP ranked among the top-10 committers to the Kubernetes Project’s Community Sizing and Health Assessment Dashboard in 2019.
For a window into SAP’s commitment to the cloud and open source, we spoke with Irfan Khan, president of SAP Platform and Technologies.
How would you describe SAP’s cloud offering and how does it factor into your mission as a software provider at this time?
And that expansion into the native cloud world would have taken SAP, of course, quite a considerable amount of time to build out each of these native cloud properties, cloud software as a service capability if it was left to its own devices. Historically, SAP probably would have done that — being the first to market and leading in the market — but the reason that the premium was paid was that we either acquired the number one or the number-two player in those particular segments.
So, these companies have been acquired and how I would describe SAP’s cloud offerings is that they are the whole host of, if you want to call the broad cloud lines of business solutions, software as a service (SaaS) solution, that SAP has brought in to supplement it’s very substantial back-office.
What is SAP’s open source philosophy and has it changed during the past few years?
On the open source side — because I think from an SAP perspective — we’re totally embracing open source as a value add on top of providing robust enterprise great solutions. We’re not into the process of looking at these as science projects, where a lot of the open source, in my opinion, which is [the status] of a lot of the open source. If you take a look at a large number of our customers, for instance they all set up Hadoop clusters. Many of them did. And they were giving their Hadoop clusters some airtime to say, “well, this is going to be our data lake foundation and we’re going to start bringing a lot of data in and we’re going to start an experiment.”
But the robustness of the foundations of open source supporting their aspirations have been really questioned. Particularly when you get the breakdown of the two biggest vendors, Cloudera and Hortonworks Sandbox, which determined that the market really wasn’t ripe enough for either of them individually.
Those same two open source Hadoop distribution providers were also the two most significant proponents of driving not just the business model, but the foundation of open source Hadoop to market. And at the beginning of this year they realized that the market just wasn’t big enough for both of them to be able to operate with independence. So hence they converged, right? So these two businesses coming together is almost like SAP and Oracle deciding to partner and then converge because we don’t think the market is big enough.
If we suddenly throw some open source into the mix, it cannot become the lowest common denominator of failure. It must support certain levels of SAP grade support that our customers are expecting.
I think the way that the SAP evolution around open source has happened is that there was a level of denial first that SAP probably could do everything itself. So, that was maybe the first era of development at SAP during the eighties and nineties. So, there was a definite era where SAP’s philosophy was to take any widget or any particular framework like a SQL database, and SAP should develop its own. That would have been the mentality of the company many years ago.
But now it’s, “okay, well yeah, let’s take a look and see what’s out there.” But as long as it supports the foundation of SAP grade, meaning our customers have a certain level of expectation of SAP, it cannot be without all of the enterprise-grade capabilities that you’d expect from SAP. If we suddenly throw some open source into the mix, it cannot become the lowest common denominator of failure. It must support certain levels of SAP grade support that our customers are expecting.
In the 2010 era, when SAP brought Hana to market in fact, I think that was a turning point.
So in the early stages of Hana coming to market, SUSE Linux was the only distribution that Hana supported. And then if you fast forward about maybe six to seven years into Hana’s journey, 2016 is when they started supporting Red Hat. And at that point in time, I think in 2010, SAP realized Hana needed to run on an essentially commoditized piece of infrastructure, but it also needed a robust runtime environment and operating systems. So, we adopted SUSE.
How does Eclipse represent another example of SAP’s support of a successful open source project?
SAP is a huge contributor and a big adopter of Eclipse and has been one of the open source projects that we really embraced as a management framework to be able to manage the different services that you may have. Let’s assume you developed your own messaging bus, and with the framework Eclipse provides, you can then drop in the plugins and then everything systematically comes together.
As one of the first supporters of Cloud Foundry, how does Cloud Foundry help you help SAP and your customer with cloud native and Kubernetes deployments? During the 2014-2015 timeframe, SAP was heavily investing in cloud platforms as a set of services and as a PaaS, which needed to have an environment to run within DevOps. That’s where SAP’s NEO stack was really developed for.
When SAP elected to really embrace all the hyperscalers, meaning Microsoft, Amazon and Google, the currency of migration was Cloud Foundry. Ultimately, each of the infrastructure providers has embraced Cloud Foundry and open stack and that was the open source foundation that was used for portability. With any service provider, including SaaS or infrastructure as a service provider, infrastructure capabilities are really only possible when there is commonality of the infrastructure that is provided, and that what Cloud Foundry offers and why it was fully adopted by SAP as well.
The way that we look at Cloud Foundry is our ability to run in Cloud Foundry is provided through SAP’s cloud platform. So a cloud platform is a PaaS, which has a lot of capabilities around integration, extensions around the on-premise environment customers may have.
Cloud Foundry is like windows for us. It’s like the operating system that we need to run on in order to be able to provide the services. So I would, in my mind, I would kind of conceptualize Cloud Foundry as being a super operating system foundation that gives you all of the services to be able to run an application on. And in this particular case, it’s a cloud platform for us; SAP’s cloud platform is our platform as a service.
Needless to say, the big-three Google, Microsoft and Amazon cloud providers have had a profound influence in the adoption of open source and cloud native adoption, as well as on the state of IT in general. How would you describe this context and what is SAP’s role in it?
If I look at the investments the three big American Google, Microsoft and Amazon hyperscalers are making, in some ways it’s reminiscent of the Cold War era and the nuclear arms war that’s going on between the U.S. and Russia. It was about how many nuclear warheads they had. Well, in the case of the infrastructure providers, it’s about how much computer storage they have and in what parts of the world can they cover.
So, why would SAP spend that kind of investment in driving that level of computing and store capability? And similarly, if you look at Google and Microsoft and Amazon, they’re all competing with themselves on how much investment they make to create the best compute and storage options their customers will be attracted to. So, on that level, we absolutely need to cooperate with the infrastructure providers to take advantage of their infrastructure support. Because if we didn’t, what’s the alternative? The alternative is the Oracle model, which I think is completely flawed. In fact I think it’s lunacy to assume that you’re going to somehow displace the big three hyperscalers with your own infrastructure offering, which by definition is being driven by you spinning up more compute and store, competing on that level of scale.
The reality is that we’re going much more towards commoditized infrastructure and commoditized services. Where customers will see value and where they probably will continue to pay for it is on the analytic side. Which is why coming full circle to some of the announcements SAP has recently made about SAP Data Warehouse Cloud, SAP HANA Cloud Services and SAP Analytics Cloud, they are all about analytics and data management converging on the infrastructure of the hyperscalers. So the scale factor is there and the cost association is there to be able to exploit what they provide.
Cloud Foundry, Red Hat and SAP are sponsors of InApps Technology.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.