- SAP created a concept of an SAP HANA sidecar which was designed to get customers to implement uncompetitive or immature solutions.
- The benefit free SAP HANA sidecar is one example of this.
The SAP HANA sidecar was presented as an important step to using HANA very aggressively in 2013, and less so since then. In this article you will learn SAP’s logic behind a sidecar, and whether the logic actually holds up.
What is an SAP HANA Sidecar?
An SAP HANA sidecar is where HANA is run as an offline system. The offline nature of the SAP HANA sidecar is critical to understanding the overall concept, as the concept being that HANA is first tested offline before being brought online.
Here you can see a standard graphic that shows a HANA sidecar design.
Using the “sidecar”, the data is replicated to HANA. This is to be a precursor to actually replacing the current database, called AnyDB to reflect it being Oracle or IBM, etc.. with HANA.
Why this database is being replaced in the first place is an interesting question as Oracle, HANA and MS are constantly updating their databases and there is no evidence presented by SAP that HANA outperforms other databases even in analytics, as we cover in the article What is HANA’s Actual Performance and Articles that Exaggerate HANA’s Benefits. But SAP continues to use uses false compatibility claims to push customers to HANA. They do this even when there is no evidence for HANA outperforming the database it is replacing.
Here is a typical quotation from SAP on this topic that tries to ease companies into moving towards HANA, without providing evidence that moving to HANA makes sense.
“Customers can add new analytics capabilities immediately without disruption to their existing landscape. Any investment today will be valid for SAP Business Suite powered by SAP HANA.”
The logic often presented by SAP is that if SAP offers an item, that it naturally should move moved to.
Benefits of the SAP HANA Sidecar?
And here is another promoting the benefits of this design.
“The way the current SAP systems work is, the data is transferred from database to application layer and calculations are performed in application layer. Here you have significant latency between disk to memory transfer and then calculations in application layer. HANA database on the other hand is optimized for mass parallel processing and performs calculations in the database layer and only submits a result set to the application.” – HANA Discussion Thread
There are several important questions to ask regarding this comment.
- Is This True?: This idea of using a stored procedure for processing has been proposed for quite some time. However, the main reason that SAP promotes this concept is so they can reduce the compatibility of their applications with other database vendors, that is databases other than HANA.
- Superior Performance?: As explained in the article What is the Actual Performance of HANA?, there is no evidence that HANA outperforms other comparable databases. In fact, the evidence appears to point in the opposite direction. And these comparable databases are able to achieve this performance without stored procedures.
What is the Overhead of the SAP HANA Sidecar?
One of the greatly underemphasized points is that this replication of data between the active system and the sidecar is quite a bit of overhead. This is of course minimized by those who propose using the SAP HANA sidecar. To explain this overhead, we will review the requirements of the sidecar.
Here are a few of the requirements in order to achieve data replication for a HANA sidecar.
- “Data must be loaded from current database to HANA database using any of the existing replication scenarios (DXC, Data Services, SLT) or ABAP custom code.
- If you require real-time loading into HANA sidecar you will still need SLT or have custom code that loads to HANA via secondary database connection everytime a change is triggered
- Custom ABAP programs are needed to be able to connect to HANA database and retrieve/insert/update data
- To fully optimize the performance of HANA as sidecar, all custom ABAP code must be optimized to run SQLSCRIPT in order to fully utilize the HANA calculation (refer to part_2 blog for more details)
- HANA only runs on SUSE LINUX SP11 so if your current hardware/os does not include SUSE LINUX you will need get hardware specifically for HANA” – HANA Discussion Thread
The Project Duration of HANA as a Sidecar
A typical HANA implementation will take between 1 year and 1.5 years to finally migrate. This means that the customer has to run the sidecar this period of time and absorb the cost of doing so. This is a longer duration than is pitching by SAP account executives, and it is one reason why HANA’s TCO is so high.
SAP sidecars can be viewed as a sales strategy to push immature applications into prospects and customers by taking the solution “off-line.” The idea being presented by SAP is that the sidecar allows the customer to incorporate “innovation” into companies. However, the overall presentation is a problem. One major reason is that the buyer beings investing from when they buy the sidecar software, and this can easily lead to “sunk cost” decision making where the customer continues to invest in a solution. That is the sidecar can very easily become “project quicksand.” And this is of course the objective of those that present sidecars.
We cover HANA’s TCO in the first and only independent TCO analysis of HANA.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.