What is our primary use case?
I have used the solution for the IT systems of a German client and for our data center. I also build sandbox servers, and then I build SAP S4HANA. So, now I am working on a POC environment, which is a PCC that is SPS 7 with HANA 2.0 SPS 05. I'm doing this tech upgrade which is a requirement of critical use for SAP S4HANA, and then multiple systems with the current patch. I'll start with SAP S4HANA installation into the POC environment and will do this backup with Commvault. Then, I will start with the database for the HANA readiness check. And I will resize my hardware with analytics browser support, and I will do this readiness check with the functionality and run the report. So I will keep a check on if the objects come, and I have to be forwarded with this functionality, how they can soon, you know, do online check, and they will do the modifications.
What is most valuable?
The documentation part on SAP S4HANA includes the technical guidance and sites where they have been given a map of transit gateway and API gateway, and you see environments over there, and if you have to check about EC2 instance sites where they have given the prerequisites before moving to AWS. So, we have to check SAP notes first before moving to SAP S4HANA. For instance, if I want to move SAP S4HANA 2022, and I want to find the conversion from EHP 7, but then I have to check for EC2, along with figuring out which is the supported environment over there for analytics, SAP S4HANA, because they have given a set of prerequisites before moving to EC2. Then we have to stick to IPs, and we have to design the solutions, and with the system going into a POC environment, with Overlay IP and configure for the SSR application part. According to that note, we have to plan for this, whether SAP is for the HANA system or if we should go with Fiori embedded solutions. Designing should be not only for SAP ECC, but you have to be thorough with the GRC component and BW of SAP since, for SAP S4HANA, we need to do a readiness check. So we have to simultaneously do two reports in one POC system. And for DRC, we have to download some add-ons, and we also have to do some maintenance, optimize the stack files, and we have to do some uploads as a standard practice. I can say that we have to check the release node first, which is the OSB part. So, SAP HANA 2.0 SPS 05 with the latest patch we can do, and it is supported on SAP HANA 8.6 and 8.7, whereas SUSE Linux Enterprise Server for SAP Applications 15 SP3 supports SAP HANA. So it depends on how we can go fast with the readiness checks, and we can deploy this solution. You have to do modifications to your POC environment first and into this, and then, again, we have to run some prerequisites check nodes related to FI, and fewer issues should come from the frontend team, and the backend will look after SAP S4HANA. So that could be with the functionality, we have to provide MM and SD to those who can do the online custom code analysis for PPE and vendor masters, and so it could be a collaboration team with a functional team that we have to be data support, then you have to fix it here. Within a week, the POC will be from my side, and it should be from the business activity, which is potentially completed within a week. All the activities from the basic side, I can complete within a week. I have done migrations that are successfully running. With the internet supply, I have it for systems like POC and marketing. But I don't have any issue until you know the way any systems will require, whether it may be Azure or maybe AWS. But I can speak for AWS because, security-wise, it's a very good feature. When it's in Azure, we have to be aware that Red Hat support is not good. So we have to go with either Windows. People might be aware of ransomware taking to Windows servers. So I will not go with that solution, but I will go with this S4HANA on Red Hat and SUSE Linux. So, the solution could be very good over there, and we can deploy it into HANA, and I know that form part is very well that we have to do some AMI integrations for that, and we can build the servers within a day. POC from my side based on my activities can be done in seven to eight days because we have to check with our transit gateway, IP, and network integration.
We can run once the POC is done since, after that, we can run the parallel without development, quality, and production. So, if our production is on the HA part, we can take downtime for that. But before that, we have to do a parallel QA because it's very easy to move it via some transportation on the sandbox. We could move it later on to development and quality and then later on to the POC, when the live production will start, after which SAP will let us do more. It all depends on which solution we are going for, and it may be public or private editions of SAP S4HANA. With the public edition, we talk to SAP's third by itself. The private edition is chosen by companies with AWS. So if we go with the SAP on BTP public cloud, it may fall under the delay side, but with AWS, it will be fine.
What needs improvement?
CPU architecture is an area where the solution currently has some issues. Improvement in CPU architecture could improve the performance side and the adherence to the parameters set by SAP. As suggested by SAP, we should do HANA mini checks on a daily or weekly basis. All the parameters related to HANA should be equal to improve performance. So, some of the parameters I can see on the SAP side are related to memory, and so we have to check on each landscape whether the parameters related to SAP are properly set or not. Regarding the right CPU from AWS and SAP recommended nodes, we have to check whether the performance is good or not because we have to give this almost on HANA since, on some side, we have to be swapping that on voice level also, and so that screening part is a requirement from OS/DB side. In short, we have to check all parameters. My solution is IOPS related to EC2. So I have just done a very good optimization. I have seen some parameters related to Linux that is from SAP side, where the problem is very fast, and CPU load is very low. So that is an OS/DB recommendation parameter from the SAP that it should be set over there on all systems. As a basic start, we have to check OS/DB recommendation settings, and everything should be kept on. Those experienced in SAP S4HANA need not worry about any part.
I think overlay IP should be linked to gateway web architecture. It should be in a proper way to the community for the security part. Apart from that, we have to follow Amazon and SAP books. There have to be some adjustments made from the finance and GRC side. So, we have to check some of the functional sides and whether these parameters are properly set in for SAP s1 in terms of logistics, MRV, and some of the code. I can recommend that SAP's 86 custom code should be a proper way to develop a very good experience going online for the custom tools. So, it would be good to improve such features and everything. Also, the system should not be at any end of support since it will impact its performance. I have faced some of the, you know, clients, where they have some end of support, comes into 7209, and they just back it up. I need to get some extended support from the SAP, and some software should be there. So before the end of maintenance, everybody has to awaken all the features of the solution. On a daily production side, we can do this maintenance activity, whether it may be outdated or not outdated, and support patches should be done properly.
For how long have I used the solution?
I have experience with SAP S4HANA on AWS. SAP S4HANA, I did my certification and two live projects, including all the features and implementation parts. Regarding SAP S4HANA, I have eight years of experience. With SAP S4HANA on AWS, I have an experience of more than two years. Considering the on-premise version, it should be more than four years.
What do I think about the stability of the solution?
With a stable environment, it should be running very nicely. We have 203 servers for our database. So we are taking the backup of applications and databases to be on the safer side if anything happens with the CPU of Amazon.
Stability-wise, the solution is ninety-nine percent available. So, whenever we do DR setups and everything, the availability is on from primary to secondary. So there is no loss of data with or without the switch. I guess it is available with other zones and DR always. Stability-wise, I rate the solution a nine out of ten.
What do I think about the scalability of the solution?
Scalability is always available in the solution. So if we go with scaling up its storage part and decide to have an eighth or twenty-four TB storage is possible with high quality and production. Nowadays, forty-eight TB is supported by AWS, and the medium will be twenty-four TB for SAP S4HANA. As a requirement, we can deploy, you know, our requirement with six GB or maybe twenty GB requirement. So we have to do calculations, and the customer can tell us how much TB they need. I recommend it for those who want to analyze data and identify if they need 24 TB storage with all the backups, servers, and everything.
The size of our clients depends on the data. The size of the data depends on ECC, GRC, and BW parts.
How are customer service and support?
Technical support is very good from SAP and AWS. They immediately provide us with support on the AWS side. I rate the support a nine out of ten.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
I have implemented Commvault on AWS. The difference between Commvault on AWS and SAP S4HANA on AWS is the difference and saving in cost. So I deployed the Commvault solution for the deduplication. If my HANA contains 6 TB of my data, with deduplication, it will need only fifty percent size to contain that data since it can compress it. So, I could say my cost is fifty percent right now on both zones for all databases. I like Commvault's features. Also, the billing part is reduced because of AWS.
How was the initial setup?
The initial setup is not complex. The initial setup is a straightforward process. For those who work on SAP S4HANA on AWS, it's simple. Otherwise, more time has to be given to development. If there is some pressure to deploy SAP S4HANA on AWS, then the person doing the deployment has to read all the books of technical documentation side, and he has to go step by step with SAP on AWS technical documentation where he is preparing the clusters or without clusters, and how the planning strategy over there, whether it's just planning to go with HSR, without HSR, or software management. So, it all would be different from the technical part or the optimization side. I did just design over here, along with the implementation part. So I know this in and out of AWS.
For a new setup, a person will have to follow the books and details given by SAP on AWS technical documentation. Considering that if certain steps are missed out, I rate the initial setup an eight or nine on a scale of one to ten, where one is difficult, and ten is easy. So, it's a very large theory part with the embedded solution, but the functional team should be given a very good exposure related to extended warehouse and other such details related to SAP. So I think if I can rate myself, I can rate SAP S4HANA's initial setup an eight to nine. It is hard to be deployed with the technical document. It's single documentation to be referred for deployment.
For HANA, I can say thirty minutes to deploy the solution. Now, consider the downloading part of the software. It should take a day. Also, a good developer can do it within a day. We have to do a testing part of hardware system efficiency for SAP. So, there's one tool available over there, and we have to download that report whether the hardware is properly working or not in relation to I/O file data logs and volumes, and then we can just do the NFS part of switching after the setup of HANA. Then, we had to do the testing part of how the backup will take time since stop and start in SAP will be very fast, but how much data load will take time, so we had to check, monitor our index servers and on an upgrade and, you know, SAP installation results, while also we to do a configuration with our paths, applications, and everything. So that should be done on SAP S4HANA.
What's my experience with pricing, setup cost, and licensing?
On a scale of one to ten, where ten is the highest price, I rate the solution's pricing an eight.
What other advice do I have?
I know the PTP part of the public cloud is for business analytics from the IT side. I'm not updated with S4HANA's new certification, but I did my old one. I have very good exposure to SAP S4HANA. I'm certified in all areas, not only in AWS as a professional architect, but I work on the Azure side. I work with multiple backup solutions, SAP side, and, especially, I have very good expertise in AIX and Red Hat Linux. I am very good at the cluster part and SAP workloads. I recently passed all the examinations, which were very hard examinations.
SAP I work on all S4HANA on AWS, ranging from 1610 to 2022. So, I am just doing this upgrade to SAP HANA 2.0 SPS 07 right now, which is coming to the market. And we are planning to resize that hardware. I am including multiple activities in S4HANA on AWS. So multiple activities should be SAP, patching, high base, and a few more related stuff. Also, I recently did very good projects related to the data center, which is normally for the ERP, including BW, HRM, and CRM, which are in a patch with the correct version. So all are in sync now, and so all servers are running very fine without any database loss.
With the solution, I know how to do the IT, MC, and business function part while also knowing how we can pull the data from SAP S4HANA on-premise to the automation side. I have completed my projects very fast, with and without conversion, along with greenfield and brownfield. With my expertise, I can deploy it very fast on servers, including AWS.
In IBM, they want SAP S4HANA on AWS. They are not happy with Zoho Cloud and Paradigm solutions for the last two years. So, now they are ready to move to AWS because of its speed and security features.
I rate the overall solution, including the overall software that is SAP S4HANA on AWS, a nine out of ten.
*Disclosure: My company does not have a business relationship with this vendor other than being a customer.
