openSAP

SAP on Hyperscalers – Strategy, Architecture and

Deployment
Unit 1

00:00:05 Hi, everyone, and welcome to SAP on Hyperscalers - Strategy, Architecture, and
Deployment.
00:00:13 My name is Ornulf Kittelsen, and I am part of the SAP services business. This course is an
introduction to the deployment of SAP on Hyperscalers.
00:00:26 It will cover essential questions that will help define the right strategy, start building the
correct architecture,
00:00:34 and guide you on the project deployment or conversion. In addition, we will compare
running SAP in the cloud
00:00:44 to the traditional on-premise deployments and runtimes. In this first unit, I will introduce
some key reasons
00:00:53 for why customers are choosing Hyperscalers, or multi-cloud vendors, if you'd like.
00:01:00 After that, I will focus on many of the questions customers have. And in this course, we will
primarily focus on Amazon Web Services, or AWS,
00:01:11 Microsoft Azure, and Google Cloud Platform, or GCP, even if the principles listed could
apply to other vendors as well.
00:01:25 This course will be a nutshell course over eight units that, as I mentioned, will be an
introduction to SAP on Hyperscalers.
00:01:34 The course will be open for four weeks, where we will have a moderated discussion forum
for questions and answers.
00:01:44 After the units, there will be a self-test, and at the end there will be a short 10-question test
where a 50% percent score will give you
00:01:53 an achievement or badge, and I hope you will enjoy the course. So why are so many
companies looking at Hyperscalers for their infrastructure today?
00:02:09 We have seen that there are four pillars that define this answer. First, many of you are
seeing companies and competitors innovate faster than ever before.
00:02:23 This is done frequently with tools like SAP Business Technology Platform that are running
on any of the three Hyperscalers.
00:02:33 Second, a Hyperscaler solution can give you a lot more agility. High availability or disaster
recovery is now relatively simple to set up.
00:02:44 Adding more compute power can be done very quickly, or automatically even. Activating a
new feature or solution could be quick,
00:02:54 with minimal impact on the production systems. In essence, Hyperscalers allow for a much
more flexible platform.
00:03:05 Third is automation, which allows for system provisioning via scripting, for example.
00:03:12 In essence, a script can create your new virtual machine or allowing automatic scaling when
you need more power or storage.
00:03:23 A fourth pillar is total cost of ownership. The customer sees a shorter time to adopt solutions
on Hyperscalers,
00:03:31 due to multiple predefined solutions on hand, such as the automated virtual machine
creation.
00:03:38 Customers can also benefit from a pay-as-you- go model. First, I want to outline a variety of
models that Hyperscalers provide.
00:03:53 This course is dealing with Infrastructure as a Service in depth, IaaS, and will only touch on
Platform as a Service, PaaS,
00:04:03 or Software as a Service, SaaS. Infrastructure as a Service is a computing infrastructure
00:04:10 that allows you to run virtual machines, database services, network components, security
features, and so on, in the cloud.
00:04:20 The physical data center is also part of IaaS. In essence, it allows you to install
00:04:27 SAP S/4HANA while not owning or managing the hardware. Platform as a Service takes it a
step further,
00:04:36 where the vendor will also own, control, and manage the operating system, development
tool, databases, and so on.
00:04:45 SAP Business Technology Platform is a core example of this. The SAP Business
Technology Platform
00:04:52 allows people to integrate applications, build new applications, and so on, while the SAP
business technology application
00:05:00 is running on top of all of the Hyperscalers we are discussing in this course. SAP is
responsible for the operating system and the core tools
00:05:11 on the Business Technology Platform while you as a customer are responsible for the actual
configuration,
00:05:19 or applications running on top, like an interface, or a user interface component,
00:05:25 for example. Software as a Service, however,
00:05:30 allows the vendor to fully manage infrastructure, the operating system, and middleware, as
well as the application itself.
00:05:39 An example of this could be SAP SuccessFactors, which runs on top of Microsoft Azure's
infrastructure.
00:05:46 In this case, you would be responsible for configuration of the application only. In the next
section,
00:05:56 I will go through some of the common questions that will set the stage for this course. They
will be answered in the subsequent units, however.
00:06:07 In the design or strategy phase, customers often ask, "What services will be needed on a
Hyperscaler?"
00:06:15 When we start designing our SAP S/4HANA solution, we need to incorporate building
blocks in the Hyperscaler environment.
00:06:24 We must also confirm that virtual machines and other services are certified for SAP.
00:06:33 The security we are building for must be defined. Are there specific regulatory
considerations
00:06:40 in addition to creating a strong and robust security for our solutions? We need to bring
business continuity into the design,
00:06:52 and make sure that the high availability and disaster recovery concepts are covered. Both of
these will be part of monitoring
00:07:01 in order to make sure we understand the compute power we use, how the SAP systems are
running, and more.
00:07:11 Another important design decision is for scaling resources. Are we running on bare metal for
production, for example?
00:07:19 Bare metal can be challenging to scale, or at least not automatically. And if so, should we
run virtual machines for our sandbox systems
00:07:27 so they can scale to our needs and take advantage of cost savings?
00:07:35 Another important design is the architecture that will span from your office locations to the
Hyperscaler,
00:07:43 the design of the firewalls, network, and access points, and the architectural view of SAP
solutions
00:07:51 covering the virtual machines, databases, and storage. With design and verification in place,
it is time to migrate the systems.

2
00:08:08 This section is raising questions that we should keep in mind when migrating to a
Hyperscaler.
00:08:13 We will answer all these and more in the following units. When we are working on migration
and setup of our systems,
00:08:25 we need to lay out the tools that we can use. Can we use the classic SAP tools to migrate
the solutions?
00:08:32 Do we need additional scripts? And so on. We will look at many of these tools and how they
work with Hyperscalers
00:08:39 in the architectural units of the course. What about performance, both in migration over the
wire
00:08:48 and when building out the systems as well as when we're running the systems? Where can
I find a best practice for a Hyperscaler deployment?
00:08:59 Is there such a thing? And perhaps most importantly, how can we use automation,
00:09:06 for example to have virtual machine images automatically created so that we can speed up
the project timeline?
00:09:20 When we are going into the operations phase, or runtime, if you'd like, we will have to deal
with a few different tools and ideas
00:09:28 versus what we did on-premise. We have to build out a strategy for measuring service level
agreements,
00:09:38 how much compute power we are paying for, user access, and more. We must also define
how we will manage
00:09:48 changes to the application in a Hyperscaler environment. And how to make it the most
efficient.
00:09:57 We will be notified if there is a security incident, but how do we manage these cases?
00:10:04 Who is managing these cases? And finally, as we are working out how to keep applications
up to date,
00:10:12 we need to include capacity planning and total cost of ownership based on keeping some
systems dormant,
00:10:19 as in a non-running state, to save on cost. As I mentioned in the previous slides, there are
many new questions we will encounter
00:10:33 when we migrate to a Hyperscaler. On this slide, we see the principles from cloud vendors
themselves.
00:10:44 One, design for automation. Two, be smart with state.
00:10:50 Three, favor managed services. Four, practice defense in depth.
00:10:55 Five, always be architecting. As we can see, these principles reference
00:11:02 many questions and topics that we raised on the previous slides. The reason I include these
principles is to point out that the cloud vendors
00:11:14 also see automation as a primary factor when moving to the cloud. They emphasize how we
should practice our defense.
00:11:24 They encourage us to continue architecting, and to take advantage of the infrastructure
services to run better and more efficiently.
00:11:35 All of the above will lead to more flexibility and cost effectiveness. So in essence, the
principles set forth by the cloud vendors are key building blocks
00:11:46 for how we should approach moving SAP to the Hyperscaler. This presentation concludes
the first unit of this course.
00:12:03 Thank you for watching and I hope you enjoyed it. I'm looking forward to seeing you in the
next unit.

3
Unit 2

00:00:05 Hi everyone, and welcome to unit two of SAP on Hyperscalers - Strategy, Architecture, and
Deployment.
00:00:13 My name is Yashith Manjunath, and in this unit I will go over SAP Intelligent Enterprise
strategy, the different cloud service and deployment models for SAP applications,
00:00:23 and how they are realized in today's hybrid landscape. First off, let's look at SAP's Intelligent
Enterprise strategy
00:00:31 and what it means for companies to adopt Intelligent Enterprise strategy. Intelligent
Enterprises apply advanced technologies and best practices
00:00:42 within agile, integrated business processes. This makes them resilient, successful, and
sustainable.
00:00:50 The picture shows SAP's solution portfolio for the Intelligent Enterprise, how the individual
parts belong together, starting with business processes,
00:00:59 and then the application that supports the processes and the foundation, the technology
layer.
00:01:07 Let's take a closer look from the top of the stack. The first one is Business Network.
00:01:12 The SAP Business Network will help you to digitalize cross-company business processes.

00:01:19 The network builds on current procurement, travel, and contingent workforce solutions to
help Intelligent Enterprises work together to create flexible value chains.
00:01:31 Next comes the intelligent suite. SAP offers an integrated suite
00:01:36 of applications that support your end-to-end business processes. The suite helps manage
every part of your organization, including employees,
00:01:46 customers, products, spend, finance, and IT. With the embedded analytics,
00:01:53 we provide a 360-degree view of the business. Next is the industry cloud.
00:02:00 SAP's industry cloud will help enable you to discover and deploy vertical solutions from SAP
and partners.
00:02:09 These help customers to apply leading-edge industry best practices and extend the current
business processes.
00:02:18 Next is experience management. Understanding what people want and how they feel is
critical to making the right decisions.
00:02:26 Experience management solutions give insight on the sentiments and feelings of customers,
employees, and other business stakeholders.
00:02:36 For the sustainability management, being best run means running sustainably. SAP
solutions for sustainability
00:02:45 will help customers understand and manage their impact on people and the environment.
And the Business Technology Platform
00:02:54 is the platform that provides data management and analytics, also supports application
development and integration,
00:03:02 and allows customers to use intelligent technologies such as artificial intelligence, machine
learning, and the Internet of Things to drive innovation.
00:03:16 To address the broad range of customer needs and requirements, SAP offers a full range of
cloud solutions using which customers can deploy cloud apps
00:03:25 for all lines of business on a market-leading cloud platform, using flexible, on-demand
infrastructure,
00:03:33 with proven enterprise cloud security and hosting services, and with the choice of public,
private, or hybrid cloud environment
00:03:42 to meet the customer's specific needs. In the next slides,
00:03:48 we will review the different cloud service models and related SAP offerings. SAP Software
as a Service, also called SaaS, solution portfolio

4
00:03:59 consists of offerings for every line of business and more. In the cloud ERP space, the
solutions offered are
00:04:08 SAP S/4HANA Cloud, SAP Business One, SAP Business ByDesign, and these are
designed for large, midsized, and small businesses in that order.
00:04:20 The cloud procurement solution - all categories of network and spend, such as supplier
management, strategic sourcing, procurement,
00:04:32 procurement and contingent workforce, selling and fulfillment, and travel and expense.
00:04:38 These are managed along with the world's largest business network. The analytics solutions
powered by SAP Business Technology Platform
00:04:49 allow users to provide real-time insights through machine learning, artificial intelligence,
business intelligence, and augmented analytics,
00:04:59 also to analyze past and present, while simulating future scenarios as well. As for the
customer experience solutions,
00:05:09 these can help attract and retain customers, while growing revenue, powering seamless,
personalized experiences everywhere.
00:05:19 The global supply chain management solution - an integrated portfolio that includes
00:05:26 predictive analytics, automation, and Internet of Things with industry expertise,
00:05:31 digitally connects the entire supply chain. SAP SuccessFactors Human Experience
Management Suite enables the shift
00:05:41 from transactional human capital management to end-to-end experiences, creating a more
flexible, engaged workforce and a more resilient business.
00:05:53 Finally, the financial management solutions - financial planning and analysis,
00:05:58 accounting and financial close, treasury management, accounts receivable, billing, and
revenue management,
00:06:06 cybersecurity and governance, risk and compliance help minimize the impact of economic
disruption
00:06:14 while maintaining business continuity. SAP Cloud Platform is the Platform as a Service
offering
00:06:25 to build application extensions and seamlessly integrate landscapes. The capabilities of
SAP Cloud Platform
00:06:33 are now key parts of, and the core pillars powering SAP Business Technology Platform,
also called SAP BTP.
00:06:43 The integration and extension capabilities are now available as services that run on SAP
BTP.
00:06:51 These integration and extension capabilities are now called SAP Integration Suite and SAP
Extension Suite
00:06:58 and run on SAP BTP, providing users with a cloud environment
00:07:03 to develop, manage, extend, and deliver applications. The SAP Integration Suite,
00:07:11 an integration-Platform-as-a-Service offering, enables users to implement data, application,
API, and process integration projects
00:07:23 involving any combination of cloud-resident and on-premise endpoints. The SAP Extension
Suite services can help customers build and enhance solutions,
00:07:35 optimize business processes, and create an engaging digital experience. Using the
extension suite as an extension platform means that customers
00:07:46 can keep the core clean because they do not need to change the core system code. With
the extension suite,
00:07:54 customers can easily discover, consume, and expose APIs and events from existing SAP
systems, and use these tools and services to build extensions.
00:08:11 SAP HANA Enterprise Cloud is a fully scalable, secure, and end-to-end private managed
cloud solution
00:08:18 designed to unlock the full value of SAP HANA in the cloud, establishing a clear path to
cloud readiness while driving growth through innovation,

5
00:08:29 reducing risk, and providing a close alignment to the Intelligent Enterprise. SAP HEC is
offered in the full-subscription, cloud-based software model
00:08:41 and also enables running the digital core functionality of S/4HANA in a hybrid cloud
environment, providing flexibility
00:08:50 with the customer's choice of Hyperscaler or SAP data center. It becomes important for
customers who are
00:09:02 planning to migrate and run SAP applications in public cloud Infrastructure-as-a-service
platforms
00:09:08 to make sure the platform is certified by SAP. Support for SAP software in Infrastructure-as-
a-Service environments
00:09:16 is guaranteed only when the entire infrastructure, including the compute, network, and
storage components,
00:09:25 for the operation of all closely coupled runtime components of an SAP software solution
00:09:31 should be the responsibility of a single infrastructure provider. The relevant support
requirements for an infrastructure provider
00:09:38 for using the SAP software should also be met. And the SAP product should have been
explicitly released
00:09:47 for use in the environment of the infrastructure provider, in combination with the respective
infrastructure components.
00:09:54 Here on the left-hand side, you will see the list of all Infrastructure-as-a-Service platforms
released and certified by SAP.
00:10:02 The platform-specific support requirements and the released SAP products, in combination
with the supported infrastructure and machine types,
00:10:12 are defined in relevant SAP Notes. As for SAP HANA, the information of all
00:10:20 certified hardware supporting IaaS configurations for OLAP and OLTP workloads, scale-up
and scale-out models
00:10:30 is provided and updated in the certified and supported SAP HANA hardware directory for
IaaS platforms.
00:10:41 SAP Cloud Appliance Library offers a quick and easy way to consume the latest SAP
solutions in the public cloud, such as SAP S/4HANA,
00:10:50 SAP HANA, express edition, industry solutions, model companies, and so on. This is an
online library of pre-configured, ready-to-use SAP business solutions
00:11:01 that can be instantly developed into the customers' own cloud accounts to kick start SAP
projects.
00:11:11 In today's hybrid landscape, customers run SAP solutions in on-premise, cloud,
00:11:18 and hybrid deployments, which is a combination of both on-premise and cloud. While the
cloud provides access to functionality for easy consumption,
00:11:28 customers often want to keep systems across the cloud and on premise, or across premise
environments.
00:11:34 This type of hybrid deployment model is supported by SAP, and has actually helped
customers get the best of both worlds.
00:11:45 Here we see a picture of how enterprises are consuming SAP applications and offerings
using this hybrid landscape,
00:11:52 consisting of private cloud, private hosted cloud, Infrastructure-as-a-Service cloud on
Hyperscalers,
00:12:00 Platform-as-a-service cloud, and Software-as-a-Service cloud, with everything connected
seamlessly.
00:12:07 For the remainder of the course, our focus will be on the architecture, migration, and
deployment
00:12:14 of the digital core SAP S/4HANA any-premise solution on the Infrastructure-as-a-Service
Hyperscaler platform.
00:12:24 This concludes the unit. Thank you for watching, and I hope you enjoyed it.

6
00:12:28 We will see you in the next unit.

7
Unit 3

00:00:05 Hi everyone, and welcome to unit three of SAP on Hyperscalers - Strategy, Architecture,
and Deployment.
00:00:14 In this unit, we will focus on strategic topics - what to think about, work out, and design prior
to starting the project.
00:00:30 First, let's look at SAP S/4HANA and how we can convert from an ECC system. When we
decide to do a conversion over ECC to SAP S/4HANA, for example,
00:00:45 we have to consider the Data Migration Option tool, as we would need DMO with System
Move for converting to a Hyperscaler.
00:00:55 We need to evaluate our architecture setup, and make sure that storage attached to the app
servers is set up, for example.
00:01:05 SAP has seen multiple customers who are converting from an ECC system directly to a
Hyperscaler.
00:01:13 There are obviously a lot of factors here, such as the amount of data, downtime, testing,
and other elements.
00:01:22 So in a strategy discussion of the project, it is important to have an end goal in mind and
drive the decision back from that.
00:01:32 Once we know the end goal, we can start architecting for the subnets, the hubs, the spokes,
and more
00:01:39 to make it optimal for our decision. In the next unit,
00:01:44 we will also discuss a couple of different methods for how to move our systems to a
Hyperscaler.
00:01:56 As I mentioned in the first unit of this course, we will evaluate tools a little more in depth.
00:02:03 Many customers have familiarity with DMO, the Database Migration Option, and SUM, or
Software Upgrade Manager, in their on-premise systems.
00:02:16 And yes, these tools are also used for most SAP S/4HANA conversions to Hyperscalers.
00:02:24 However, there are a few additional components that could come into play. Generally, DMO
wouldn't support a data center migration,
00:02:33 but with DMO with System Move, that support has been added. So for a conversion or
migration project,
00:02:45 the recommended approach is to use DMO of SUM with system move. There are additional
tools available for specific scenarios,
00:02:57 when aggressive downtime is required, for example. These could include tools like
Downtime Optimized DMO
00:03:06 or a service-based approach of near-zero- downtime technology. Please see the Software
Logistics Toolset -
00:03:15 I will put it in our discussion forum - on our support portal for the latest updates on all the
supported tools for your specific scenario.
00:03:29 In regard to integration, I want to first show you a couple of options from SAP. I think many
of you will be familiar
00:03:38 with the on-premise solution, SAP Process Orchestration. But Hyperscaler and the
Business Technology Platform
00:03:46 being the future of our SAP Cloud Integration has become the going-forward solution. Cloud
Integration solutions
00:03:57 allow for cloud-based design, for modeling, and integration of content. It comes with a lot of
pre-built interfaces,
00:04:08 and the capabilities to build your own, and supports SAP solutions as well as third- party
solutions.
00:04:17 On the next slide, I will go through some of the pros and cons of the different integration
models.

8
00:04:29 I'd like to point out four interface technologies available to us, with differences in complexity
and features.
00:04:39 First is the SAP Cloud Platform Integration, like I mentioned in the previous slide.
00:04:45 This toolset comes delivered as a PaaS solution. It is simple to set up and it comes with
many pre-delivered interfaces,
00:04:53 and the capability to build your own custom interfaces. This is SAP's primary focus in the
long term, and the recommended solution.
00:05:03 It allows you to integrate with other SAP solutions, cloud applications, business partners,
and more.
00:05:13 Process Orchestration is the second solution that is available. If you already use PO,
00:05:19 you might want to continue with it. The solution could either run on-premise
00:05:25 or be migrated to the Hyperscaler together with your SAP S/4HANA system. Most
customers will migrate the solution.
00:05:36 The maintenance will be the same, it's just a move of your current SAP solution to a
different infrastructure.
00:05:46 Web services interfaces are often used for real- time API calls and other methods for rapidly
moving data between systems.
00:05:58 It could be done via device-to-device communication or via a server that is listening for
requests
00:06:05 to serve back Web applications and other assets. This service is supported across the
Hyperscalers,
00:06:14 as well as in SAP, and should be used in the cases
00:06:18 where you are requesting information from a Web service. The last interface option I would
like to mention
00:06:26 is the cloud vendor's own interface services. SAP tested our interface solutions on AWS, for
example,
00:06:35 to take advantage of AWS's interface service in order to create an interface for rapidly
storing data in an AWS S3 storage container.
00:06:48 However, using the cloud vendor's delivered interface service will be more challenging to
maintain,
00:06:55 since you would have to build and support it on your own. Before we start the project,
00:07:07 it is important to analyze the amount of data we are moving to the Hyperscaler. Is this a
conversion where we are moving all data over,
00:07:16 or is it a selective data move with a lot less data? It is also important to understand the
bandwidth you have.
00:07:29 And also the quality of the bandwidth. The quality will help us do the simple math
00:07:36 for establishing the time it will take to move the data over the wire. There are multiple
calculators available online for this,
00:07:46 and you should take advantage of some of those. If calculations and evaluations present a
time
00:07:53 that will be too long for our downtime window, all of the Hyperscalers provide a physical
device option.
00:08:03 The Hyperscaler provides a disk you can use to transport the data, where the data is
encrypted and secured.
00:08:11 No one will be able to see the data but you. The data is then transferred via a secure route,

00:08:19 for example anonymous trucks, to the data center you will be using. As you can see on my
slide, the 4 terabytes with a 600-megabit-per-second line
00:08:32 would take a little more than 16 hours to transfer over the wire, while 20 terabytes would
take 3 days and 9 hours.
00:08:42 So in the first case, it might be okay to use a network connection, while in the second
example, many companies would say it's too long of a downtime

9
00:08:52 and would go for a physical storage device to move the data. First, just a comment on the
picture you see.
00:09:07 I am using an example from Amazon Web Services, or AWS. However, the same solution
will be the same on all Hyperscalers
00:09:17 even though there are slight differences in naming. For example, AWS is using "S3 bucket"
for naming their storage,
00:09:26 while Microsoft Azure will be using "Azure Blob" for their respective storage name. When we
have defined how we want to move data,
00:09:39 we need to make sure we have moved far enough in the preparation by setting up the
different infrastructure components.
00:09:48 This is so that we are allowing ourselves for the data to be received in the correct manner.
00:09:55 You would copy the data directly to an S3 bucket or directly to a storage attached to HANA,
or an app server.
00:10:04 However, with this option, which is a simple way to move the data to a Hyperscaler,
00:10:10 a second step is required. We need to move the data from the S3 bucket to local storage
00:10:17 so that we can restore our database. So as part of the design and preparation,
00:10:25 finding the right strategy for how we should move the data, and convert or migrate our
systems, will save us a lot of time when we start the project.
00:10:43 Our testing strategy will be impacted when we move to Hyperscaler. In this slide, I'm
outlining at a high level the testing phases
00:10:53 we should evaluate and think about before starting out the project. They are applicable
00:11:02 both during the project as well as when we are running our systems live. I think one of the
most obvious differences for many companies
00:11:13 is the separation of ownership. In other words, a Hyperscaler will upgrade their
infrastructure at times
00:11:22 and we do not have a say on when they will do this. However, we will have to make sure we
have
00:11:28 a regression testing in place for these times. And if we are using specific services,
00:11:36 we should take advantage of solutions like the preview options - I will talk more about this
option in unit eight -
00:11:44 so that we can ensure that the update will not impact our SAP systems. When SAP is
looking at Hyperscalers and testing,
00:11:56 we think of a strategy that goes from the preparation phase to the wrap-up phase. This is
due to many factors.
00:12:04 Most likely, you will have automated solutions in place for replacing a VM that could
potentially fail.
00:12:11 Or it could be failing over to a different storage solution, if needed. Many of these options
and technologies will look different from your legacy systems.
00:12:22 On premises, we tested failover for a high- availability scenario, but with a Hyperscaler, the
agility and scaling locally
00:12:32 can require different testing considerations. Hence, we will have to consider different testing
scopes for all of these and more.
00:12:41 There could also be a need for an agile testing strategy, as Hyperscaler allows for a more
rapid test of new services,
00:12:50 and solutions that increase efficiency. In other words, making sure we are able to
00:12:55 incorporate new use cases and scenarios into our testing strategy so that testing is not the
lagging factor for releasing new functionality.
00:13:12 This wraps up this unit. Thank you for watching and I hope you enjoyed it.
00:13:16 I'll see you in the next unit.

10
Unit 4

00:00:05 Hi, everyone, and welcome to unit four of SAP on Hyperscalers - Strategy, Architecture, and
Deployment.
00:00:12 My name is Yashith Manjunath, and in this unit, I will cover the remaining part of the
strategy topics
00:00:19 for migrating SAP systems and applications to a Hyperscaler with a particular focus on the
digital core, SAP S/4HANA,
00:00:28 which is the theme that we are following throughout the course. First off, let's look at the
methodology that we can use for cloud migration.
00:00:40 Cloud migration methodology should take a holistic view of all the aspects involved in
meeting the business and technical goals of an organization.
00:00:51 There are three major phases involved in cloud migration, they are strategy and planning,
00:00:57 adoption and migration, and optimization and operations.
00:01:02 Strategy and planning is the most critical phase as major decisions are taken in this phase,
which sets the direction for the rest of the phases.
00:01:12 This phase starts with the evaluation of business needs and potential benefits of moving to
a Hyperscaler.
00:01:21 Once the benefits and the return on investment are validated, a cloud strategy is then
defined.
00:01:28 Based on the cloud strategy, a migration roadmap is then developed, which will provide
details on the phases involved,
00:01:37 such as migration approach, architecture development, cloud security, and technology
planning.
00:01:45 The strategy and planning phase is followed by the adoption and migration phase. And
based on the strategy phase, this could happen in an iterative manner.
00:01:56 As a first step, cloud setup is done based on the finalized architecture. The network,
storage, security, identity, and access management,
00:02:06 and other base-architecture-level setup will be executed. Once the base architecture is set
up,
00:02:15 resources are moved on the identified priority and dependencies to the cloud. Data
migration can happen in conjunction with the resources move
00:02:25 sometime before or even after the move. Followed by the resources move, the applications
or the workload
00:02:35 are set up in a similar way by applying priority and dependency constraints. A thorough
testing phase continues to ensure
00:02:44 the cloud architecture aspects like security, scalability, performance, stability, disaster
recovery, and data validation.
00:02:53 The optimization and operations phase focuses on the manageability aspects of the cloud
environment.
00:03:01 Understanding and adopting the cloud change management processes becomes very
important in this phase.
00:03:08 Developing the standard operating procedures, or SOPs, for cloud operations and
management happens in this phase.
00:03:16 It is advisable to do a knowledge transfer between the operation staff and create awareness
on the cloud deployment and other management aspects.
00:03:26 Cloud monitoring is another key area that is important for cloud management.
Implementation of monitoring at both infrastructure and application level
00:03:37 by leveraging both the inbuilt tools offered by the Hyperscalers, as well as other monitoring
tools like SAP Solution Manager,
00:03:45 is an important step of this phase. Now, let's take a look at how the cloud migration
methodology we saw previously

11
00:03:56 aligns with the SAP Activate methodology. Many customers are getting to the point where
their hardware is aging.
00:04:05 And while the obvious answer five years ago was to refresh the hardware, the answer today
is more likely to move to the cloud.
00:04:13 They are taking advantage of it to also move their SAP systems to SAP S/4HANA,
00:04:18 essentially running two different projects, that is cloud migration and transition to S/4HANA
parallelly.
00:04:26 This will require that the SAP Activate methodology that is used for transition to S/4HANA
00:04:32 aligns with that of the cloud migration methodology. The focus here
00:04:37 is on the workstream platform design, support, and execution and the related deliverables
00:04:43 because they go hand in hand with the cloud migration methodology. As I mentioned at the
beginning of the unit,
00:04:53 the focus here is on the digital core, SAP S/4HANA. And for customers who are still running
the SAP ERP workload in the on-premise environment,
00:05:03 there are a few options available to move to a Hyperscaler. So let's represent them in an
effort versus business benefits matrix
00:05:12 to develop a migration framework. So the first one is going to be rehost,
00:05:19 in other words, lifting applications or landscapes as is from the on-premise environment,
and shifting them to a public cloud environment.
00:05:28 With this approach, the target is the exact copy of the top three layers in the technology
stack, which is the application, database, and operating system platform.
00:05:39 And there are little to no architectural changes. This enables rapid migration with minimal
disruption,
00:05:47 but also prevents from harnessing any key business benefits of cloud migration. The second
one is replatform.
00:05:57 It is the technical migration of SAP applications. It maintains the existing applications,
00:06:03 but upgrades the underlying operating system and database by migrating to SAP HANA and
a supported operating system platform
00:06:11 in a Hyperscaler environment. So the example can be SAP ECC to SAP S/4HANA.
00:06:19 Although customers gain some benefits of HANA's real-time visibility and dramatically
increased performance,
00:06:27 like the previous option, it falls short of realizing the full benefits of a more transformative
cloud migration approach.
00:06:36 And there is also an added cost for a future SAP S/4HANA migration, which actually leads
us to the next and the recommended option,
00:06:45 transformation. In this type of migration,
00:06:49 the application layer is transformed to SAP S/4HANA, along with the operating system and
database, following one of the three transition paths,
00:06:59 that is new implementation, selective data transition, and system conversion. With this
option, customers not only gain the benefit of cloud-native features,
00:07:11 but also from digital core platform reinvented processes, real-time insights, simplification,
and Fiori user experience.
00:07:23 The benefits of transformation often outweigh the effort and costs of adopting the new
system.
00:07:37 If you're running SAP Business Suite in an on- premise environment, the transformation to
SAP S/4HANA
00:07:44 is a recommended migration approach to a Hyperscaler, and it can be achieved using one
of the three supported transition paths.
00:07:53 Customers make the choice depending on many influencing aspects, but the key expected
outcome drives these decisions.

12
00:08:03 If your focus is on fundamentally redesigning your business processes to enable the use of
modern technology,
00:08:10 as well as getting rid of outdated custom code, the new implementation approach helps
achieve that.
00:08:16 SAP S/4HANA any premise and SAP S/4HANA Cloud, extended edition are the solutions
that support this approach
00:08:23 for transition to SAP S/4HANA on a Hyperscaler. Customers who want to consolidate their
landscape
00:08:31 or to selectively transform data into an SAP S/4HANA system can choose to selective data
transition approach.
00:08:38 The consolidation of systems or landscapes with harmonized, simplified processes and
unified master data
00:08:47 will lead to a lower total cost of ownership and provides a value-based migration,
00:08:54 allowing a phased approach focusing, first SAP S/4HANA migration phase, on parts of the
businesses
00:09:01 with the highest return on investment and lower total cost of ownership. Again, SAP
S/4HANA any premise
00:09:09 and SAP S/4HANA Cloud, extended edition, both support this approach for transition to
SAP S/4HANA on a Hyperscaler.
00:09:17 You would choose the system conversion option if your main goal is to bring your current
business processes to the new platform,
00:09:25 and you want to keep your investment in custom code. SAP S/4HANA any premise is the
only target solution
00:09:33 that supports this transition option, SAP S/4HANA on a Hyperscaler.
00:09:43 When developing the migration strategy, you also want to make sure you understand the
different tools that are available and supported
00:09:50 to migrate SAP systems to Hyperscalers Customers often ask the question
00:09:56 if standard is SAP Solution Management tools like SAP Software Update Manager and SAP
Software Provisioning Manager, are supported,
00:10:04 And the general answer to that question is yes, but there might be certain limitations in
terms of the source and/or target releases
00:10:13 that are documented in the SAP Notes and SAP Product Availability Matrix. The database
migration option of the SAP Software Update Manager,
00:10:22 which is the preferred toolset for the migration of SAP systems to SAP HANA database
00:10:29 and for performing system conversions to SAP S/4HANA can be used for Hyperscaler
migrations, along with the System Move option.
00:10:39 The System Move option allows for switching primary application server host and to migrate
across data centers, or to Hyperscalers,
00:10:48 but make sure to check the SUM DMO nodes for any limitations. For instance, at the time of
recording this course,
00:10:57 SUM DMO with System Move option is not supported for the target SAP S/4HANA release
1909.
00:11:11 We have recognized that customers are using the strategies that we discussed here to roll
out Hyperscaler deployments to SAP landscapes.
00:11:19 The picture shows the horizontal and the vertical strategies for rollout. Each horizontal row
in here is an environment.
00:11:29 It's fairly common for customers to have the sandbox, development, test, and production
environments,
00:11:36 but larger companies tend to have more environments, as it suits them. Every column in the
picture represents an SAP application,
00:11:44 such as SAP S/4HANA, SAP EWM, or SAP BW/4HANA. The horizontal strategy is to
migrate SAP systems

13
00:11:54 in a specific environment to a Hyperscaler, and many customers choose to start from the
bottom of the stack,
00:12:01 with the low-risk sandbox or training environments, because it's a safe way to evaluate and
gain experience.
00:12:09 And those learnings can be applied to the environments up the stack. The vertical strategy
is where all the systems in the landscape for a particular application
00:12:19 are migrated to the Hyperscaler. Customers can choose a low-risk application first
00:12:25 to get the experience of migrating a production system, and apply the learning to other
mission-critical systems, like SAP S/4HANA.
00:12:34 When using this strategy, carefully consider the impacts to applications that are tightly
connected,
00:12:40 and create migration groups to move them over together. The vertical strategy can also be
used in parallel with the horizontal strategy,
00:12:49 like it's indicated in this picture. So this wraps up this unit.
00:12:55 Thank you for watching and I hope you enjoyed it. We will see you in the next unit.

14
Unit 5

00:00:05 Hi everyone, and welcome to unit five of SAP on Hyperscalers - Strategy, Architecture, and
Deployment.
00:00:12 My name is Yashith Manjunath, and in this unit I will go over some key architecture topics
for hosting the SAP S/4HANA system on a Hyperscaler platform.
00:00:26 Let's begin with an overview of Hyperscalers' global infrastructure. Every Hyperscaler
provider's global infrastructure
00:00:34 enables the Hyperscaler to be hosted in multiple locations worldwide and consists of
separate geographic locations around the world
00:00:43 where the data centers are clustered, called regions. Regions are isolated from other
regions,
00:00:50 and this design achieves the greatest possible tolerance and stability. Locations within a
region tend to have network latency of a submillisecond.
00:01:01 Given the many options and factors involved in making the choice for the best region, it can
be hard for customers to choose.
00:01:09 And they should consider the key parameters, such as the supported services, cost,
latency, proximity to the on-premise site,
00:01:18 security, regulatory compliance, and service level agreements. Typically, every Hyperscaler
region consists of multiple zones,
00:01:28 also called availability zones. An availability zone is one or more discrete data centers,
00:01:34 each with redundant power, networking, and connectivity in the region. And availability zone
is physically separated by a meaningful distance
00:01:44 from other availability zones. They give customers the ability to operate production
applications and databases
00:01:51 that are more highly available, fault-tolerant, and scalable than would be possible from a
single data center.
00:02:00 Typically, availability zones in a region are interconnected with low latency and high
bandwidth networking.
00:02:08 The network performance is sufficient to accomplish synchronous replication between
availability zones.
00:02:16 At the time of the preparation of this course, the number of regions and availability zones
offered by the top three Hyperscalers,
00:02:23 that is Amazon Web Services, Microsoft Azure, and Google Cloud Platform, are shown here
on the slide.
00:02:30 You may want to check out the links provided here for the latest information. Finally, it
becomes critical to choose the right region and availability zone
00:02:40 for hosting mission-critical SAP applications and systems. Elastic computing is a key driver
concept
00:02:54 for the value driver to move to a Hyperscaler. It provides the computing capacity
00:03:02 that can quickly expand or decrease compute processing, memory; and storage resources
to meet changing demands
00:03:09 without having to worry about capacity planning and engineering for peak usage. The top
three Hyperscalers, AWS, Microsoft, Azure, and Google Cloud Platform,
00:03:20 all have elastic compute services in their own proprietary technology, and use virtual
computing environments called instances or virtual machines.
00:03:32 For the compute services, Hyperscalers offer a wide range of configurations
00:03:36 of CPU, memory, storage, and networking capacity to meet the specific requirements of a
workload.
00:03:46 Similar to compute, storage capacity can be increased or decreased on a need basis as
well in the cloud.
00:03:57 Larger HANA instances are not elastic because they run on bare metal.

15
00:04:02 Bare metal is a separate contract where a customer owns it for the entirety of the contract.

00:04:09 However, application servers in front of the HANA instance could be dormant. Finally, the
most important point to keep in mind
00:04:17 when planning SAP migration to a Hyperscaler is to choose among the compute instances
that are certified and supported by SAP.
00:04:26 The support information is documented in SAP Notes shown here on the slide. Let us now
take a quick look at some reference architectures
00:04:36 that are provided by Hyperscalers for hosting SAP HANA and/or S/4HANA productive
workloads, beginning with AWS.
00:04:46 The example I have chosen here supports multi- availability zone for high availability, single-
node deployment of SAP HANA.
00:04:55 As you can see in the diagram, there are many native AWS services that are required to
deploy this architecture,
00:05:03 which is designed for greater stability and availability by placing two SAP HANA servers,
primary and secondary,
00:05:10 in separate private subnets, in two different availability zones, and by using HANA system
replications to replicate the data between them.
00:05:22 For high-availability clustering, customers can choose SUSE high-availability extension or
RedHat for SAP high-availability solutions.
00:05:34 Some of the AWS services that are used here in this architecture include Amazon
CloudWatch for monitoring,
00:05:42 Amazon S3 for storage, AWS Direct Connect for on-premise connectivity,
00:05:47 VPN connectivity through Internet and NAT gateways. VPC that spans across two
availability zones,
00:05:55 a bastion instance, and an elastic IP address. A quick note regarding the deployment.
00:06:05 AWS Quick Start, which uses AWS CloudFormation and other custom scripts, provides an
easy and automated way
00:06:14 to deploy the reference architectures like the one that is shown here, and also to configure
the components that are deployed.
00:06:26 This diagram here shows Microsoft Azure reference architecture for deploying SAP
S/4HANA in a high-availability environment
00:06:34 that supports disaster recovery as well. Although greatly simplified,
00:06:39 it consists of many key components that are needed to support a fault-tolerant, highly
available, productive workload.
00:06:46 Let's quickly review the components that make up this architecture, starting with Azure
ExpressRoute.
00:06:53 The Azure ExpressRoute provides connectivity from on-premise to Azure primary and
secondary regions.
00:07:00 Azure Virtual Network, also called VNet, is the service that securely connects Azure
resources to each other.
00:07:08 In this architecture, a VNet connects to an on- premise environment through a gateway
deployed in the hub of a hub- and-spoke topology.
00:07:17 This spoke is the VNet used for the SAP applications and the database tiers. This
architecture uses multiple virtual networks
00:07:26 that appear together using virtual network peering. This topology offers network
segmentation and isolation
00:07:35 for services deployed on Azure. As for compute, the architecture uses virtual machines
00:07:41 running Linux for the application tier and database tiers. The application tier includes the
Fiori front-end server pool,
00:07:50 SAP Web dispatcher pool, application server pool, and SAP central services cluster.

16
00:07:56 For high availability of central services on Azure running in Linux virtual machines, a highly
available network fileshare is required,
00:08:05 such as Azure Network NetApp Files or a clustered NFS server. The database tier runs
SAP HANA and uses two or more Linux virtual machines in a cluster
00:08:18 to achieve high availability in a scale-up deployment. HANA system replication is used to
replicate contents
00:08:26 between primary and secondary HANA systems. Linux clustering is used to detect system
failures
00:08:33 and facilitate automated failover. A storage-based or cloud-based fencing mechanism
00:08:39 must be used to ensure the failed system is isolated or shut down to avoid the cluster split-
brain situation.
00:08:48 A jumpbox, also called a bastion host, is a secure virtual machine on the network
00:08:54 used to connect to the other virtual machines, and is typically deployed as part of the shared
services,
00:09:01 such as domain controllers or the backup service. The jumpbox is deployed on a virtual
machine to support SAP HANA studio,
00:09:09 SAP GUI, or file transfer, or any other functions that are commonly used for installation and
administration purposes.
00:09:18 Load balancers are used to distribute traffic to virtual machines in the application tier. Virtual
machines for all pools and clusters,
00:09:28 SAP Web Dispatcher, SAP application servers, central services in HANA, are all grouped
into separate availability sets.
00:09:36 and at least two virtual machines are provisioned per role. Azure ExpressRoute, our virtual
private network gateways
00:09:45 can be deployed across zones to protect against zone failures. A proximity placement group
is a logical group
00:09:53 that places a constraint on virtual machines deployed in an availability set or a virtual
machine scale set.
00:10:00 To restrict incoming, outgoing, and intra-subnet traffic in the virtual network, network
security groups are used.
00:10:10 A gateway connects distinct networks, extending the on-premise network to the Azure
Virtual Network.
00:10:17 ExpressRoute is the recommended Azure service for creating private connections that do
not go over the public Internet.
00:10:24 As for Azure storage, Azure-managed disks are used to provide data persistence for a
virtual machine, in the form of a virtual hard disk.
00:10:35 Moving on to Google Cloud Platform. Here is a reference architecture
00:10:39 for deploying SAP S/4HANA on Google Cloud Platform, or GCP. The deployment model
shown here is called a distributed deployment within GCP,
00:10:50 where you install different SAP components on different GCP compute engine instances.
00:10:56 The deployment model, this deployment model is recommended for production
environments
00:11:01 or environments that require a lot of compute power to handle heavy transaction load. As
you can see in the diagram,
00:11:09 the SAP ABAP Central Services, SAP primary application server, SAP Web Dispatcher, and
SAP HANA are all installed on different compute engine instances.
00:11:21 Google Cloud Interconnect, gateway on- premise, cloud storage, VPN connection and tools,
and relays and gateways
00:11:29 are some of the GCP services that are required to deploy this architecture. Google Cloud
Interconnect extends the customer's on-premise network
00:11:38 to Google's network through a highly available low-latency connection, either using
dedicated or partner interconnect networks.

17
00:11:48 The compute engine instance types should be carefully selected based on SAP certification
and match the sizing requirements.
00:11:57 The cloud storage buckets are used to store backups. Relays and gateway components are
used for setting up a VPN connectivity.
00:12:07 The virtual private network where the SAP resources are deployed is segmented into public
and private subnets.
00:12:14 All SAP S/4HANA components are deployed in the private subnet. The SAProuter and jump
servers are in the public subnet
00:12:22 and are used to connect the on-premise network to the SAP S/4HANA resources that are in
the private subnet.
00:12:33 This architecture can be extended to a multi- zone deployment in order to provide higher
availability and disaster recovery capabilities.
00:12:46 Here we see a high-level diagram representing a production-grade architecture
00:12:50 that is able to withstand intra and interzonal failures, of an SAP S/4HANA system.
00:12:57 Unlike the reference architectures we saw previously, this is a Hyperscaler platform-
agnostic representation,
00:13:05 covering the entire technical stack, from connectivity, to application, to database, and the
storage layers.
00:13:13 This architecture uses two availability zones in the primary region, and supports the high-
availability design through the entire stack,
00:13:22 eliminating all single points of failure and by automating resource failovers.
00:13:28 The secondary region is used as the disaster recovery site. This architecture can be used
as a frame of reference
00:13:35 to define the Hyperscaler platform-specific architecture by adapting to the platform-specific
services and components.
00:13:48 Hub and spoke is a networking model used in Microsoft Azure for efficiently managing
common communication or security requirements for SAP workloads.
00:13:57 The hub-and-spoke model helps with cost savings and management efficiency. Centralizing
services that can be shared by multiple workloads, such as DNS servers,
00:14:09 in a single location allows IT to minimize redundant resources and management effort. The
hub-spoke model helps overcome subscription limits
00:14:20 for large cloud-based workloads that might need to use more resources than are usually
allowed in a single Azure subscription.
00:14:31 And the model also helps in separation of concerns in an enterprise by deploying individual
workloads between central IT teams
00:14:39 and specific workload teams, like SAP. A hub is a central network zone that controls and
inspects ingress or egress traffic
00:14:50 between the Internet, the on-premise, and the spoke networks. The hub-and-spoke topology
gives the IT department
00:14:59 an efficient way to enforce security policies in a central location. It also reduces the potential
for misconfiguration and exposure.
00:15:09 The hub often contains the common service components that the spokes consume. Some
examples are the Windows Server Active Directory infrastructure,
00:15:19 a DNS a service to resolve naming for the workload in the spokes, a public key
infrastructure to implement single- sign-on workloads,
00:15:29 flow control to implement single-sign-on on workloads, flow control between the spokes and
on- premises,
00:15:36 between the spoke network zones and the Internet if needed, between one spoke and
another as well.
00:15:44 The role of each spoke can be to host different types of workloads. The spokes also provide
a modular approach
00:15:52 for repeatable deployments of the same workload. Examples include development or test,

18
00:15:59 user acceptance testing, staging, and production. A similar network model in Amazon Web
Services is called Transit Gateway,
00:16:08 and in Google Cloud Platform it is referred to as Network Peering. The careful planning and
management of the network design
00:16:16 forms the foundation of how the isolation and boundaries are provided for resources within
the SAP workload on a Hyperscaler.
00:16:25 Because all the resources in the SAP workload operate in a virtual network, or a VPC in the
case of AWS,
00:16:32 where they inherit security properties from, it's important that the architecture is carefully
designed,
00:16:38 incorporating proper protection mechanisms. In this example, we can see the security
architecture
00:16:45 designed to host the SAP S/4HANA workload on AWS. The isolation of resources used by
SAP workloads into a VPC
00:16:54 that provides no direct access to the Internet helps protect these resources.
00:17:00 For Internet-facing scenarios, another VPC in the diagram, called DMZ VPC, can be used
00:17:08 with the Web application firewall and reverse policies to provide the required additional layer
of protection.
00:17:15 The components within the SAP workload VPC are further segmented into layers found by
instances, that are controlled by security groups,
00:17:24 which allows only the specific type of traffic flow in and out of the instance. Finally, the on-
premise connectivity is established
00:17:33 through the Direct Connect connection, directly going into the SAP workload VPC using the
VPN gateway.
00:17:46 Let us wrap up this unit with a summary of how to define the technical architecture for the
Hyperscaler move.
00:17:52 If you recall, in unit two we learned that in today's landscape SAP applications are hosted in
a hybrid environment.
00:18:00 And to deploy such a landscape, we suggest following an approach of defining the technical
architecture,
00:18:06 which takes into account aspects, with focus on on-premise solutions, as well as a major
focus on all SAP solutions
00:18:16 across the private and public cloud types. Note that some on-premise aspects, like sizing,
datacenter strategy, and scalability
00:18:26 are still relevant when hosting SAP on-premise solutions on a Hyperscaler Infrastructure-as-
a-Service cloud.
00:18:34 These various aspects will then be used to define target technical architectures for hosting
SAP applications on private clouds,
00:18:43 on a Hyperscaler's Infrastructure-as-a-Service cloud, and impacts private and IaaS clouds
00:18:50 via Platform-as-a-Service and Software-as-a- Service connections as well, the outcome of
which will be the architecture templates and detailed deployment plan
00:19:03 that are needed to deploy the defined architecture. This concludes the unit.
00:19:10 Thank you for watching and I hope you enjoyed it. We'll see you in the next unit.

19
Unit 6

00:00:05 Hi everyone, and welcome to unit six of SAP on Hyperscalers - Strategy, Architecture, and
Deployment.
00:00:13 In this unit, we will focus on security on a Hyperscaler. At SAP, we often separate security
into five areas.
00:00:25 First we want to touch on identity and access management. In essence, we need make sure
we know who is accessing the system
00:00:33 and making sure they are allowed to access the resources they are requesting. The second
topic we will discuss is about intrusion detection and prevention.
00:00:48 This is often done in correlation with the Hyperscaler, however. Third, we want to talk about
data security,
00:00:56 whether the data is resting or moving between system and users. Fourth, the infrastructure
needs to be secured,
00:01:08 both in the Hyperscaler location as well as the extended zone to your own corporate offices.
And finally, I want to discuss governance and regulations.
00:01:21 There are so many new rules, like GDPR, for example, and others that we need to adhere
to now.
00:01:32 If you are using one of the Hyperscaler solutions, like Azure AD or AWS IAM, or Google
Identity Platform,
00:01:41 you can easily take advantage of creating SAML or Kerberos for connecting to SAP.
00:01:47 All the above-mentioned solutions support multi-factor authentication as well.
00:01:55 This allows for central storage and management of the authentication components,
00:02:00 something that will secure the system further. It also makes it easy to enable strong
password policies,
00:02:09 both for the authentication as well in SAP, which would not have password access enabled

00:02:15 if you're using single sign-on, for example. SAP would rely on a certificate-based
authentication,
00:02:22 typically known as SSO, which will make the system more secure.
00:02:28 I will not discuss authorization in SAP in this course, as the authorization inside SAP will
stay with your current practice.
00:02:37 In other words, there is very little chance that there will be a change to how you are
designing authorization for the specific SAP data and modules
00:02:48 after migrating to a Hyperscaler. Now that we have moved to a Hyperscaler,
00:02:54 there are other services available that may be of interest, as they can significantly enhance
the overall system security.
00:03:04 All platforms come with a solution like a vault, where certificates and passwords can be
stored.
00:03:11 These are typically administrator passwords and certificates for SSO, for example,
00:03:16 and other trust relationships. It is recommended to take advantage of this.
00:03:25 I would also point out RBACC - role-based access control - that allows you to secure the
different infrastructure components and solutions
00:03:34 on a Hyperscaler. I know this is a lot in a single slide,
00:03:39 and each of these topics should have a unit to itself almost, but I hope this gives you an
indication
00:03:45 of how SAP is approaching authentication on a Hyperscaler. You should also go a little
further on this on your own.
00:03:59 Over the past few years, you have most likely heard about DDoS attacks happening to
customer networks,
00:04:06 as well as Hyperscaler infrastructure. Intrusion into our system

20
00:04:12 is something that has become increasingly important to detect and prevent. This comes
delivered in a couple of different ways.
00:04:26 On one side, we as the customer have access to monitor our own system, as well as the
health of the infrastructure itself.
00:04:35 So in order to detect and prevent, a robust security monitoring strategy will be key.
00:04:45 A second way to move towards the best protected systems is to scheduled penetration
tests.
00:04:51 In essence, this is hiring some white-glove hackers that are trying to penetrate your
systems.
00:04:59 And finally, the Hyperscalers themselves have several services that will help prevent DDoS
attacks,
00:05:06 viruses, malware, and more. It is worth talking to your vendors about these services
00:05:13 to make sure your network and infrastructure is hardened appropriately. With our
infrastructure and servers protected,
00:05:28 we need to look at the data itself. Many of the philosophies that go into data security
00:05:35 are based on strict governance around it, via data owner or custodian. It is important to
define the classification of data.
00:05:43 Is the data public data, is it internal and confidential? And you might have additional
classifications on top of that.
00:05:52 These classifications will help us choose the right solutions for storage, where to store it and
how to store it.
00:06:02 Additional technologies and solutions we need to evaluate are data at rest or in transit.
00:06:08 For rest, we need to define encryption and storage solutions. And for the data in transit,
00:06:14 we need to define whether we need our own gateway to the Hyperscaler or whether VPN is
needed.
00:06:21 VPN is secure and typically the solution that is chosen. Gateway could be considered more
secure
00:06:28 but is often chosen for other requirements as well. And finally, not directly related to a
Hyperscaler,
00:06:36 but one thing that I see consistently with many customers is that there is no data sanitation
plan in place.
00:06:44 Many customers have not designed or discussed it in depth. With the move to a
Hyperscaler,
00:06:51 I recommend you are designing for data sanitation and archiving as well. When you are
starting to design your architecture on the Hyperscaler,
00:07:04 security will be front and center. We typically would start outlining the network zones
00:07:13 and what sort of isolation we would need. For example, do we need to expose some of the
data to the public,
00:07:21 and if so, do we need a DMZ, demilitarized zone? This would involve setting up your private
network with firewalls, routers,
00:07:31 VPN gateways, and more. Load balancers are also key for the cloud.
00:07:38 With your local network most likely being extended to the cloud, the load balancer will
communicate and pass traffic
00:07:47 between the different services on the Hyperscaler, or pass requests to the local data center.

00:07:55 The three Hyperscalers come with a couple of different options for connecting. One that is
the most common is VPN,
00:08:04 a reliable and secure tunnel between your office and Hyperscaler. Another vendor option,
such as Azure ExpressRoute -
00:08:14 note, AWS and Google have similar offerings - could offer more reliability, faster speed,
consistent latency,

21
00:08:23 and higher security than typical connections over the Internet. With the components in
place,
00:08:30 we need to acquire the right certificates for SSL, and implement connectivity and interface
traffic
00:08:39 through HTTPS or SFTP. A second part of limiting and securing the applications
00:08:46 is to implement role-based access to services as well. I didn’t touch too much on this in the
strategy unit of this course,
00:08:56 but another key element of a secure solution is to implement a security patch management
process.
00:09:04 This would include working with the Hyperscaler for when they need to patch and protect
the infrastructure
00:09:11 to when we need to update our OS or other services we use. And finally, to make sure data
is protected at rest,
00:09:21 we need to implement volumes, disks, and file system encryption. Data might be encrypted
in transit via SSL, for example,
00:09:30 and it might even be encrypted in the database. But files and content on the disks are often
overlooked.
00:09:43 Security governance is important, both from what is available and how we implement and
manage our security.
00:09:52 When we are working with third-party vendors and asking them to store data for us,
00:09:57 certifications are key. Some businesses already have strict regulatory guidance.
00:10:04 And we need to evaluate the Hyperscaler we have chosen and see that they have the
certifications that are required.
00:10:12 All three Hyperscalers that we are discussing in this course have a public site where you
can see all the certifications they have acquired,
00:10:21 such as ISO certifications and PCI certifications. Another thing to confirm is the regulatory
audits.
00:10:31 It is good to discuss this with the Hyperscaler before we start so we are aware of the audits,
procedures, and policies they have in place
00:10:41 to make sure the infrastructure is secure and stable. Two additional topics I want to discuss
are change management and incident process.
00:10:53 Both these topics will likely change. Maybe just a little, or it could be significant.
00:11:02 Change management could change significantly because we now have an agile platform.
00:11:09 We have business users that may see solutions that can help them and they want to try
them out or evaluate them.
00:11:17 There might be requests to add features quickly. And with these philosophies becoming
more prominent when we run on a Hyperscaler,
00:11:25 it is key to have a strong change management process in place. And we recommend that
you evaluate your current process
00:11:35 and see where you need to make improvements as part of moving to a Hyperscaler.
00:11:43 Incident management will have a lesser impact, but be aware there will be new tools that go
beyond just SAP.
00:11:53 Check with SAP for what they support and make sure you are using certified hardware
infrastructure from the Hyperscaler
00:12:01 to help with incidents. Finally, in this security unit,
00:12:12 I want to step away from security for a second and talk a little bit about monitoring.
00:12:18 First, as far as your SAP solutions, these can be monitored just the way you do it today,
00:12:25 with Solution Manager and other standard tools you may be familiar with. However,
monitoring is important on the Hyperscaler itself,
00:12:35 not just for security, service level agreements, usage, and cost- saving initiatives are also
very important.

22
00:12:43 When we run our solutions on a Hyperscaler, we have signed up for a service level
agreement
00:12:48 where we have been promised that the service will be available 99.99% of the time, for
example.
00:12:56 If the service goes down and we have access for less than 99.99%, the Hyperscaler will
have to issue us service credits,
00:13:06 or money back, in other words. So it is important to monitor and make sure we are getting
the services we are paying for.
00:13:16 Secondly, as for the cost savings, we have always been able to monitor the usage of our
hardware and software.
00:13:24 But now we have a chance to shut it down so that we do not have to pay for it.
00:13:30 Hyperscalers are consumption based so you only pay for what you use.
00:13:35 So it's recommended to have a good monitoring process in place for shutting down
hardware that is not being used.
00:13:43 I will also touch on this a little bit later on. But it's also key to remember who is responsible
for monitoring what.
00:13:51 As you can see, when we move to a Hyperscaler, we are still responsible for monitoring the
applications,
00:13:58 the operating system, the networking components, and so on. In a IaaS solution,
00:14:06 the Hyperscaler will just make sure that the infrastructure is operational. That is it for this
section.
00:14:17 Thanks for checking in and I'm looking forward to seeing you in the next unit.

23
Unit 7

00:00:05 Hello and welcome to unit seven of SAP on Hyperscalers - Strategy, Architecture, and
Deployment.
00:00:12 My name Yashith Manjunath, and in this unit I will focus on some of the key topics
00:00:18 that are important from a Hyperscaler deployment perspective. Let's start this unit by
reviewing the sizing aspects
00:00:26 for migrating SAP systems to Hyperscalers. Wrongly sized instances are one of the major
contributors
00:00:33 to wasted cloud spend. Finding the right sized virtual machine or a compute instance
00:00:38 also involves choosing the right instance type. Users can choose between reserved, on-
demand, and preemptible instance types,
00:00:48 but dedicated instances are most suitable to run SAP workloads. The question that naturally
arises
00:00:55 when on-premise SAP workloads are being migrated to a Hyperscaler platform is whether
sizing is still an important deployment topic or not,
00:01:04 considering that systems can scale anytime, have faster deployment cycles and easier
management on Hyperscaler platforms.
00:01:13 While it's important to ensure that IT teams don't overestimate resource use in the cloud, it's
equally important to conduct a proper sizing exercise for the migration
00:01:23 that will help determine the right instance type and capacity that is required to support the
SAP workload.
00:01:31 This aspect remains almost the same as on- premise because horizontal scaling cannot be
applied to certain components
00:01:39 like the SAP HANA database. A general approach that can be used for sizing
00:01:45 requires running the sizing exercise for the migration scenario first, and the output of which
is then used to map with the Hyperscaler instance family sizes
00:01:55 to identify the right fit, followed by storage and network sizing.
00:02:03 A more specific approach for greenfield implementation of SAP S/4HANA on Hyperscalers
00:02:09 can use the process defined here on the left- hand side. SAP Quick Sizer should be used
for initial sizing for this type of migration.
00:02:19 The sizing process will involve the customer, who will provide the requirements in terms of
performance,
00:02:25 business SLA, and other key figures. The Hyperscaler vendor provides scalable offerings,
00:02:32 certified hardware, configurations, and technology partners. SAP will bring in sizing tools
and reports,
00:02:40 sizing guidelines, and verification. The outcome of this exercise will be the sizing output
measured in SAPS for CPU
00:02:49 and in gigabytes for memory and disk space. In the case of system migration,
00:02:55 the process defined here on the right-hand side can be used. The focus for this transition
type will be on the delta sizing,
00:03:03 using SAP guidance reports and Notes. For delta sizing,
00:03:09 we will start by regularly monitoring the data footprint on the on-premise environment and
the processing requirements,
00:03:16 followed by the review of the new initiatives or releases to assess which sizing approach to
apply.
00:03:23 For increased load, measurement of the current capability
00:03:27 and extrapolation to accommodate the increased load will give a rough estimate.
00:03:34 For new usage types, it should be treated the same as the initial sizing. Let's now take a
closer look at the capacity aspects of sizing.

24
00:03:48 Every Hyperscaler provider offers many different types of compute instances that are
optimized for various types of workloads.
00:03:55 And the ones that are certified for SAP workloads are usually a small subset of them.
00:04:01 It should be noted that certification for SAP HANA is different than the application server or
AnyDB
00:04:09 Here on the right-hand side, you will see the table for SAP-certified compute instance types

00:04:14 offered by the top three Hyperscalers. For further information,

00:04:19 we recommend reading SAP Notes and SAP Certified Solutions Directory.
00:04:25 In the case of SAP HANA, it's important to also be aware of the capacity limitations
00:04:31 of virtual compute instances. Although Hyperscalers are releasing more and more instances
with larger capacity,
00:04:39 the maximum CPU or memory capacity for a certain virtual machine type certified by SAP
00:04:45 should still be reviewed. An example is that, at the time of the recording of the course,
00:04:51 the M-series VM is available with a maximum memory of four terabytes in Microsoft Azure.
To overcome these limitations,
00:05:02 Hyperscalers offer bare-metal alternatives to expand beyond the limited capacity that virtual
machines come with,
00:05:10 and these can be considered for larger deployments. An example for this type is HANA
Large Instance,
00:05:17 with expand scale-up capabilities of up to 20 terabytes offered on Microsoft Azure. There is
also the option to use the HANA scale- up model in most cases,
00:05:29 but it does need further evaluation. Another important point to note
00:05:34 is that there is usually a mismatch between the sizing result and available virtual compute
instance SKUs
00:05:40 that Hyperscalers offer. So customers have to choose the SKU
00:05:45 that offers the closest capacity to the estimated size. Let's look at some pointers for defining
and validating the infrastructure components
00:05:59 before deploying SAP S/4HANA and other SAP on-premise solutions. From a compute
perspective,
00:06:06 reviewing SKUs and sizes of compute instances, like the virtual machines or AWS EC2
instances,
00:06:13 based on the sizing result, becomes very important.
00:06:16 This is to ensure you are choosing the smallest certified compute instance that provides
more size than the base requirement
00:06:24 that was determined from the sizing exercise. As for storage,
00:06:30 there are various solutions that every Hyperscaler offers for different needs and purposes.
00:06:36 SAP systems require both local as well as shared file systems, and validating the type of
storage solution
00:06:43 chosen for these purposes against performance and cost will become important as well.
00:06:50 For setting up an SAP HANA system, the storage layer must fulfill several requirements.
00:06:56 So the storage performance KPIs should be carefully validated using the SAP HANA
hardware and cloud measurement tool.
00:07:05 We saw that the network aspects can get very complex in the previous architecture unit. So
identifying the proper network components required to support the defined architecture
00:07:16 becomes very critical. Developing a strategy for network segmentation and interconnectivity

00:07:22 using virtual networks, or VPCs, subnets, NAT or transit gateways will tremendously help
with defining the components for deployment.

25
00:07:33 For Internet-facing applications, The DMZ infrastructure should be redesigned using
appropriate components in the cloud.
00:07:42 The cross-premises network connectivity between on-premise and Hyperscaler regions
00:07:49 needs to be set up using private, low-latency connections, such as Azure ExpressRoute,
AWS Direct Connect,
00:07:57 or GCP Interconnect, to run mission-critical SAP workloads.
00:08:03 Finally, network performance should be carefully validated for performance, as SAP
systems and applications are sensitive to network latency.
00:08:19 The basic financial drivers for Hyperscaler migrations of existing business systems like SAP

00:08:26 are usually cost clarity, predictability, and cost reduction. There are many factors that
influence the cost of running SAP workloads on Hyperscalers,
00:08:36 but as far as the core services are concerned, there are a few things to keep in mind when
deploying resources
00:08:43 that can help optimize cost and cloud spending. For compute pricing,
00:08:48 the type of instance, operating system type, I/O throughput, and SKUs are directly related to
the cost incurred.
00:08:57 As discussed previously, there are also options of choosing reserved or dedicated compute
instances
00:09:03 for predictable workloads, which will help significantly reduce compute cost
00:09:08 when compared to on-demand instances. It must be noted that dedicated hosts
00:09:14 are usually required to run high-memory instances for SAP HANA and they would run on
bare metal hardware.
00:09:22 For the network components, cost is greatly impacted not only by the type of components
deployed,
00:09:28 but also by the amount of data transferred. Ingress data is usually free of cost,
00:09:33 but egress of data is charged at a fixed price per gigabyte. For the storage,
00:09:41 the pricing depends on the type of storage class and its performance in terms of
Provisioned IOPS.
00:09:48 The primary storage requires higher IOPS, but for backup, low-cost object storage can be
used,
00:09:55 which can help optimize storage cost. With cloud deployment, it becomes easier to manage
cost
00:10:02 through dashboards and cost management tools that are offered by Hyperscalers free of
charge.
00:10:09 Monitoring, tracking by using resource stacks, and analyzing service usage
00:10:15 will help look for potential opportunities for cost reduction and also for better cost estimation.

00:10:23 As a final note, Hyperscalers offer spot compute power, like Spot Instances in AWS,
00:10:29 which are essentially spare capacity offered at steep discounts compared to on-demand
instance prices.
00:10:37 And it can serve as an excellent candidate for special short PoCs or evaluation projects.
SAP provides different deployment options for some of the key components
00:10:52 that make up the SAP S/4HANA systems. We recommend that customers evaluate the
deployment options
00:10:59 to choose the one that best fits their needs and cost synergies. For instance, core
deployment of SAP HANA database
00:11:07 using a multiple-database container or multiple components on one system
00:11:11 can help reduce the infrastructure footprint and management effort and cost,
00:11:16 and can be explored for hosting non-production scenarios. The other important deployment
options to choose from

26
00:11:23 are the central hub versus the embedded model of SAP Fiori front-end server. The general
recommendation from SAP
00:11:31 is to choose the embedded model, but customers can also leverage the Fiori launchpad
capabilities
00:11:37 offered on SAP Cloud Platform when migrating to a Hyperscaler.
00:11:42 The more advanced locking and lock replication mechanisms that come with the new
ENSA2 and ERS2 instances
00:11:51 of SAP S/4HANA 1809 or later versions can be deployed on separate dedicated instances
00:11:59 for higher availability, or they can be co-hosted with the application servers as well.
00:12:06 From a connectivity standpoint, evaluate the proper deployment of SAP Web Dispatcher,
cloud connector,
00:12:14 and other cloud agents, such as SAP CPI-DS or SAP SDI agent.
00:12:22 Finally, recommend using integration and security best practices for this evaluation as well.

00:12:36 We understand that SAP systems never operate in silos, so the deployment plan should
carefully consider all dependencies,
00:12:44 both technical as well as process-oriented for Hyperscaler migration: Here, we have
identified some key dependencies
00:12:52 that need to be carefully evaluated for the migration,
00:12:56 Obviously, the infrastructure components and services, such as servers, virtual machines,
and storage dependencies,
00:13:03 are very critical. The dependency on shared components and services is sometimes
overlooked
00:13:09 and should be included in the technical architecture delivery plan. Depending on the scope
and the magnitude of the migration,
00:13:16 these components, like DNS, Active Directory, and security,
00:13:21 will also have to be migrated to the Hyperscaler platform where SAP workload is hosted.
00:13:28 There will be changes to the way operations are performed in Hyperscalers when compared
on-premise environments,
00:13:35 so the processes and procedures should be properly adopted for better supportability. And
then there is a major dependency on cross-premise
00:13:45 and intercloud connectivity as well. Cloud migration can be a complicated, painful
experience if done incorrectly.
00:13:57 Migration testing helps reduce this risk and uncover any discrepancies or errors. While the
scope, strategy, and testing scenarios differ depending on the type of workload,
00:14:09 a general non-functional testing approach can be used for this migration. Non-functional
testing is the testing of a software application or a system
00:14:18 for its non-functional requirements, which is the way a system operates
00:14:22 rather than specific behaviors of that system. It is performed to ensure proper functioning of
virtual machines
00:14:31 for SAP Web Dispatcher, load balancer, application servers, database servers, middleware,
SAP Cloud Platform,
00:14:40 network connectivity, monitoring, business continuity, high availability, disaster recovery,
and so on.
00:14:50 Here we are showing how a simple question of who does what, where, when, why, and how

00:15:00 can help define a testing strategy. Depending on the scope,

00:15:04 customers should also consider including regression and performance testing in the
migration plan.
00:15:15 Here, I'm outlining the summary of the elements needed to define the high-level technical
architecture deployment plan.

27
00:15:23 Firstly, the plan should include mapping of all components into the regions and availability
zones
00:15:29 that have been identified for the deployment of the SAP workload. The high availability and
disaster recovery solutions
00:15:36 should be properly outlined, covering all single points of failure,
00:15:40 the clustering solution required for automated failover, SAP HANA system replication for
each tier,
00:15:46 storage replication, and so on, depending on the service level agreements
00:15:51 for recovery time and point objectives. The evaluation of various deployment options for
pros and cons
00:15:59 and leveraging core deployment options, wherever suitable, should also be covered in the
deployment plan for SAP HANA.
00:16:06 SAP HANA system replication and disaster recovery setup and testing plan should also be
properly defined in the deployment plan.
00:16:15 Further, the deployment plan should also include non-functional testing and performance
testing plans.
00:16:22 And finally, a detailed cutover plan for the migration of every system and environment
00:16:27 should also be developed. The learnings from non-production cycles and mock cutover
iterations
00:16:34 should be carefully documented and incorporated into the final cutover plan. We will wrap
up this unit by reviewing some key points to consider
00:16:46 when putting together a project plan for the migration of SAP systems to a Hyperscaler
platform.
00:16:52 The initial project planning phase will include several steps that are typically not part of the
SAP migration procedure.
00:16:59 Usually, Hyperscaler providers assign cloud architects to assist customers with the
migration to their platform.
00:17:09 It is strongly advised to develop a good working relationship with the assigned cloud
architect, as it becomes a key influencing factor for the success of the project.
00:17:19 Designing the SAP landscape in the cloud can potentially require additional time
00:17:24 when compared to redesigning the on-premise environment for hardware refresh cycles or
upgrades.
00:17:32 Security will look different in the cloud. It becomes important to cover some of the things like
enterprise threat detection,
00:17:41 UI masking, single sign-on, Active Directory, identity provider, and so on,
00:17:47 as a basis for a new security design, with the shift to the shared responsibility model,
00:17:53 and that will require additional effort as well. One of the key benefits customers gain by
moving to a Hyperscaler
00:18:01 is the automation capabilities. It not only helps accelerate the migration,
00:18:06 but also to have leaner and more efficient operations in the cloud. When planning the
project,
00:18:12 potentials for automation should be closely looked at and incorporated in the project plan.
00:18:18 This concludes the unit. Thank you for watching and I hope you enjoyed it.
00:18:23 We will see you in the next unit.

28
Unit 8

00:00:05 Hi everyone. Welcome to unit eight of SAP on Hyperscalers - Strategy, Architecture, and
Deployment.
00:00:13 In this unit, we will address a production system running in the cloud. This includes how to
handle changes,
00:00:21 how to make sure we are agile, and the teams required to run SAP on a Hyperscaler.
00:00:31 When we are running on a Hyperscaler, there are key fundamental changes
00:00:36 as to how we think about systems. First, we know that the Hyperscaler will continuously
release new services
00:00:46 and upgraded services, many of which can help make our infrastructure more secure,
00:00:52 perform better, or help to improve how we manage it.
00:01:00 Due to this, we have to learn to be agile. This means we need to understand how to adopt
00:01:08 and take advantage of new services without making it a long, costly project.
00:01:17 This also requires an understanding of the Hyperscaler's preview environment. This is a
solution where new or upgraded services are released first.
00:01:29 It allows us to test them and understand how our production environments would be
impacted. Another thing that we recommend working towards,
00:01:42 now that we are live, is to identify and implement automated solutions.
00:01:49 This helps us make the system more stable, since we know that every automated action will
be exactly the same every single time.
00:02:02 Let's look at automating incidents, for example. When a virtual machine is down,
00:02:08 an incident is created for the virtual machine and the appropriate person is notified.
00:02:16 But via automation, we should be able to bring up a new machine without human
intervention. The notification will still occur,
00:02:26 but it's now for managerial purposes. So as you can see,
00:02:33 the change management might look different in a Hyperscaler environment. It is pushing us
to be more agile, automate more,
00:02:43 and run more efficiently. As we saw, it is likely that we will become more agile running on a
Hyperscaler.
00:02:58 So how does that impact our testing strategies? We must first develop a strategy for those
times
00:03:07 where other vendors are updating a service we are using, or the Hyperscaler is updating the
infrastructure.
00:03:17 When they do, we have x number of scripts ready that we want to execute
00:03:23 to make sure our production is not impacted. A second strategy we should have in place
00:03:33 is to use the Hyperscaler's preview environment. I mentioned it before but I want to say it
again.
00:03:39 This is to test any changes that may come to a service that we use. It allows us to quickly
test the new features against a copy of our production,
00:03:49 before we actually roll it into our production environment. Finally, we should be able to put in
place our communication strategy with the Hyperscaler
00:04:00 for performance testing. In essence, the Hyperscaler would not allow a performance test
00:04:06 without having indicated our need to test in advance. Without prior notification,
00:04:14 the Hyperscaler's DDoS prevention system would be triggered. For example, if we were to
send one million requests in one minute
00:04:24 to our SAP S/4HANA system as a performance test, the Hyperscaler would most likely see
it as denial of service attack
00:04:33 and shut it down. It is worth mentioning that the standard SAP testing principles
00:04:42 we have used for years are still applicable when running on a Hyperscaler.

29
00:04:49 The bottom line is SAP has not changed, it is just deployed on a different infrastructure
00:04:56 with potentially different rules. In the past, when we were upgrading a service pack
00:05:10 or adding a new feature that was installed as an add-on to the SAP system, it was often a
2+ month project
00:05:19 with direct impact on the landscape. In the cloud, however,
00:05:25 this can be simplified significantly. It is easy to move and copy systems on a Hyperscaler
00:05:33 without having to procure new hardware. Now we have the capability of potentially using our
current budget
00:05:44 to stand up a new development and new QA system, for two months, for example, without
impacting the production landscape at all.
00:05:53 We can do the upgrade in the new dev system, transport it to the new QA system,
00:05:59 and complete all the testing. After we are done,
00:06:03 we merge the changes into the production landscape and then we decommission the newly
created dev and QA systems.
00:06:13 This is a classic example of paying only for what we are using. This is often called canary or
green-and-blue architecture.
00:06:25 In SAP, we have often referred to this architecture as an N+1 landscape. There are
potentially restrictions to this strategy.
00:06:37 If your HANA system is too large for a virtual deployment, we might need bare metal.
00:06:44 Bare metal is typically provisioned and priced for a longer time period, since it will be a
reserved machine.
00:06:53 If you use bare metal infrastructure for your solutions, an N+1 landscape should be
discussed early on
00:07:02 in order to reduce cost due to the negotiations of a larger landscape overall. I'd like to follow
up on the previous slide in a different way.
00:07:18 Provisioning of a new system for new features can now be done easily, as I mentioned.
00:07:26 In addition, allocating the cost of the new system is also easy on a Hyperscaler. As we
know, having run SAP on-premise,
00:07:38 we are used to businesses or business users requesting a backup, a new feature to be
installed,
00:07:45 or a rollback for some testing purposes, and so on. This was always challenging to price.
00:07:53 How much electricity did they use? How many servers did they really use versus ask for?
00:08:00 How about the manpower to perform the request? Many costs were hard to define.
00:08:08 With the cloud, this can be significantly easier to manage. We are now able to automatically
create a new virtual machine,
00:08:17 with a solution installed. We are able to allocate the cost of the virtual machine, database,
00:08:24 virtual network, and so on, directly back to the business unit that utilizes the resources.
Business units can now request new servers with their own budgets
00:08:37 to test out new solutions and features quickly. And the IT department is not overloaded with
work and strain on their budgets.
00:08:47 It's a win-win for all. Several team players will have additional or different responsibilities on
Hyperscaler.
00:09:02 I want to mention a few. First up is the IT architect,
00:09:07 who must now develop a broader skillset in order to understand networking, hardware,
databases,
00:09:15 and application servers from the Hyperscaler. On top of that, they will need to understand
security and service level agreements.
00:09:27 Hence, learning and utilizing many of the Hyperscaler management tools for monitoring and
insight is very important for this role.
00:09:40 The cloud architect role is similar but would be more focused on the cloud portion

30
00:09:45 and connectivity back to the office and users. He or she would have a strong understanding
of all networking topologies and concepts.
00:09:57 A deep understanding of security is essential as well - this would include authentication and
identity services,
00:10:05 how data flows, and how various services are secured on the Hyperscaler.
00:10:15 We all know the basis administrator, who is essentially an SAP-focused IT architect.
00:10:22 This role is not changed a lot with a move to the Hyperscaler.
00:10:27 We are still running HANA on top of Linux, and we are still running our application servers
for access.
00:10:34 However, understanding provisioning, performance tuning, and networking is important,
00:10:42 as it will have different limits and considerations on a Hyperscaler. Additional roles that are
important may or may not be directly SAP-related.
00:10:58 In a recent customer workshop, I was surprised to see that there were so many participants

00:11:04 that didn't really know SAP in depth. They were focused on security
00:11:12 or on overall corporate networking, and there were OS specialists and UNIX gurus.
00:11:19 Because of that experience, I want to highlight other roles that will be key as well.
00:11:27 Security teams will have to learn about Hyperscaler certification and governance. In
addition, they will need to learn several new tools
00:11:36 that will be used to prevent intrusion and attacks. VPN and access points will also be
important skills to be required.
00:11:48 These topics come on top of potentially needing to upskill in authentication and identity tools

00:11:54 that will be used after moving to a Hyperscaler. For example, the differences on Active
Directory and Azure AD.
00:12:05 The network architecture team might be the group that is the least impacted. They have
been used to building out networks, zones, and access on-premise.
00:12:18 It is key that they learn the new tools that we will use, though. Is it a new firewall versus the
one we used before?
00:12:27 If so, what are the differences? The firewall has the same functionality,
00:12:32 stopping traffic that is not authorized, so it's more about learning the new tool than new
concepts.
00:12:42 And finally, administrators, they will be working closely with tools
00:12:47 to understand pricing, provisioning, and ongoing cost. They will monitor the health of the
Hyperscaler
00:12:56 to confirm that we are above our SLA agreement. If the Hyperscaler falls below the agreed
upon SLA,
00:13:04 they would owe us service credits. Administrators must also understand resources and
utilization,
00:13:13 in order to suggest ways to reduce cost. For example, as part of their monitoring,
00:13:19 they see that there are three virtual machines that have not been accessed in the last
month,
00:13:24 and hence they will suggest that we shut them down, since we are only paying for what we
are using.
00:13:37 Thank you so much for joining this presentation. Hyperscalers will only get more and more
of our focus and attention going forward.
00:13:48 I hope this introduction course was helpful to get you started down the path of moving your
systems to a Hyperscaler.
00:13:58 Thank you very much for participating.

31
[Link]/contactsap

© 2021 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary softwar e components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express war ranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this docume nt or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or plat form directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time fo r any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See [Link]/trademark for additional trademark information and notices.