I hope also. But now there is no SAP on AWS certificate also. 🤷🏼‍♂️

Thanks for your review and taking the time to leave a comment. I have to admit I'm intrigued as to whether this is the real Dominic Uliano. I wouldn't say that any of the issues were complete show stoppers and unfortunately neither does AWS consulting. Where there's a will there's a way, but I would expect that some of the issues I talk about are more than likely not discussed and mitigated. Not enough companies invest the effort to understand and operate the systems properly anymore. I'm sure you will understand this. The ABAP program buffer. You're right! That's a really good mention, but not just because of the program buffer loading. Although the gradual buffer loading from the DB will cause a performance hit in the stats, one would hope that having something like an in-memory DB would mitigate that slightly. We're digging right back into my early BASIS days now but there used to be a file for storing the last loaded programs. I believe it was stored in the work directory and would have been rotated. By restarting a particular app instance too frequently it could slowly degrade that program buffer file, as least-used programs rolled off the end of the buffer if they were not accessed between instance restarts. Running SGEN is a novel idea in a non-autoscaling world, but in this particular instance, where a company has implemented this AWS auto-scaling solution, then kicking off an SGEN run (although it would also be using that program buffer file would it not?!) after startup, is going to incur a database performance penalty. It's not as gradual as allowing a program to load into the buffer on execution. More of a big bang. Therefore, the rapidly needed capacity of the newly started App server will be consumed by SGEN, instead of serving the needs of the demanding end-users. That sounds like a tricky balance between making the newly started App server appear available for end-user dialog tasks, versus being performant when running those tasks. For the SAP system log, the old method where each instance would send its logs was deprecated some time back before Netweaver 7.3 I think. The Central System log file SLOGJ is no longer present in the later Netweaver versions. When in SM21, it's now a pull mechanism and functions mainly via the sapstartsrv (instance agent) over HTTPS. Well, SAP Lama. Quite surprising that you're mentioning that. Take a look at my profile and you'll find my blog pages on Lama. Admittedly I only have experience of the older "on-prem" version, but my experience of that product was that it could do what it needed to do, which was orchestration, but the other capabilities were let's be honest quite basic. Several times on the project we experienced breaking fixes that prevented the product working properly. Even the smallest of things like an SAP Hostagent patch could break it. It just loved to be broken. I have not seen the new cloud product, so I will be sure to take a look and see what's new. I'm going to guess it uses the Hostagent still. I'm afraid my pants would not hold up well if Lama was in place and a hostagent patch had been rolled out to an App server that was part of an auto-scale setup. Will SAP start? Will it? Ah yes, it has, pfew! If one was to implement auto-scale with Lama, I'm going to guess it would still also need to write custom code to prevent AWS from alerting that a VM has gone down. Unless the Lama alerting is used. Which brings us onto the old dilemma of SAP products for SAP systems and AWS products for the rest of the AWS hosted non-SAP stuff. In an ideal scenario, if a company was going to apply effort to create significant developments on automation of infrastructure, I would be inclined to say stick with a single common technology and get it refined by a SWAT team who can look after it. We've just discussed some deeply technical topics, it would be interesting to hear how many companies implemented auto-scale on AWS using deep technical experts, then handed that solution over to an SAP focussed BAU team that were not equipped to troubleshoot the intricacies of problems caused by such a solution. Lastly, it's not my topic, it's AWS' topic. This auto-scale on AWS solution is seen by AWS infrastructure people, by FinOps people and by top-level executives as a workable solution for saving money. In the video I talk about fitting this solution to specific candidates of systems. One of those candidate profiles would be that the auto-scale App instances being stopped and started would be PAYG. I mention that. The required analysis to determine actual cost saving would be a reasonably lengthy exercise because it would need to consider the average resource consumption, but somehow incorporate something like the predictive algorithms used in weather forecasting. It's 90% likely to rain today, because on similar days on similar times of the year with similar variables, it has rained. Would be interesting to be a part of an AWS auto-scaling project, just to see how that number is calculated, and then create a video about it :-) This was one of my first "feature length" videos and you wouldn't believe the time it took to create the graphics and edit it. It's already pretty darn technical, which is a final cop-out from me ;-) . Know your audience is all I am going to say. Look at the hits on this video.

@@TechCubicleOnSAP thanks for your reply. First, I did not mean to disrespect you or trivialize the effort that you put into this video. I completely respect your effort and actually have watched several of your other videos, which I find very informative and professionally produced. After watching this video, I became concerned about several of the topics that you laid out as a potential solution. Granted, you brought up a number of disclaimers and you also recommended using AWS professional services. I don't want to go back and forth with you in these comments but in general, I stand by my original thinking that there are some significant gaps in your presentation around using AutoScaling SAP with AWS. I was not aware that you had expertise around LaMa, but now I have an even stronger conviction that you should have highlighted the use of LaMa Cloud (perhaps a side by side with LaMa on premise) because you could have addressed another use case where Autoscaling with LaMa would be very valuable. I am referring to LaMa's autoscaling capability of adding application servers for times when additional capacity is needed (financial period close, high business transaction volume, etc). Let me close my comments here by confirming that yes, indeed, this is the real Dominic Uliano. Thanks again for your response to my comment and happy to debate this topic further with you, but not here in these comments. Sincerely, Dominic

I appreciate all feedback, no disrespect felt. I think my writing style is classified as "direct", but if you've seen other content from me, then you'll know that's the way I deliver, short (well, sometimes) and to the point. I do have to say that AWS don't just recommend themselves, they enforce it. There's no code, so customers would have to use AWS Consulting Services to get access to the code. I don't know if AWS Consulting Services are good or not. I can't say either way. Thanks for watching.

Good question! 👍 RISE only gives what the customer is paying for. So customer would need to pay for autoscaling... maybe.

Good question - if you are already using a managed outsourcing partner - or know someone who is - can you ask them what their offerings are in this space and post the reply here? Thanks.