Companies depend on critical enterprise applications, like Microsoft, SAP, Oracle, and others to run their business. In this session, learn about the compute, storage, and networking services that AWS offers to help you build, run, and scale your business-critical applications more quickly, securely, and cost-efficiently. We also cover the AWS services and partners that are available to help you modernize and migrate your business-critical applications to the cloud.
34. BP SAP in the Cloud
Overview of BPs SAP in AWS Journey and Benefits
35. Who are BP?
• Global energy business with wide reach across the worlds energy system
• 78 Countries of Operation
• 73,000 employees
• Sales and operating revenues of $299 billion
• Underlying replacement cost profit $12.7 billion
Source BP.com, Year ending 31 December 2018
36. Timeline of BP SAP in the AWS Cloud
2014
• Initial
Sandbox
PoC
2015
• Hana Data
Analytics
PoC
2016
• Hana data
Analytics
Live
• First SAP
migrations
begin
2017
• 5 prod
systems live
2018
• 28 prod
systems live
2019 onwards
• Migrating
remaining
SAP systems
and
extending
with cloud
capabilities.
37. Benefits of moving BP SAP to AWS
• Innovation and Efficiency – use new technology with low upfront investment
• Simplification – less to manage
• Scaling – flexibility in performance
• Cost management – make the most of budgets
• Evergreening – reducing the pain of “end of service life”
38. Innovation and Efficiency
• By utilising the AWS platform (including tools such as quick start templates) we benefit
from the rapid innovation in the cloud. BP innovate on top of AWS innovation.
• We can quickly take advantage of new hardware developments, which are normally both
faster and cheaper.
• New technology can be tested with low upfront investment, accelerating innovation.
• BP has developed a SAP standard platform for AWS which has helped us drive rapid
migrations. This is continuously enhanced as AWS release new functionality.
• Automation supports self service, rapid deployment and consistency.
To get an idea of innovation pace, read the AWS blogs.
39. Simplification - Number of Vendors in the SAP Stack
Item On-premise BP SAP in AWS
Business Software SAP SAP
Database 3rd party vendor 1 SAP (ASE or Hana)
Operating System 3rd party vendor 2 SUSE (from AWS)
High availability 3rd party vendor 3 AWS
Hypervisor 3rd party vendor 4 AWS
Server Hardware 3rd party vendor 5 AWS
Shared Storage (NFS) 3rd party vendor 6 AWS
Database Storage (Block) 3rd party vendor 7 AWS
Vendors to deal with? 8 2
This is only the core of the SAP stack and excludes related items like backup, networks, security etc that
involve additional vendors.
40. Scaling – Flexibility in Performance
• Hardware is created on-demand or turned down or off when not in use, for example when
SAP projects are not actively running. This reduces costs.
• Hardware can be upsized or augmented to increase performance during load spikes,
period-end, or specific maintenance activities.
• Migrations can be accelerated using large hardware temporarily, then rightsized for
operations. For example a 16TB database heterogeneous migration has been reduced from
7 days to 2 days, with further optimisation work continuing.
41. Cost Management
• Due to the scale of cloud infrastructure, costs are typically lower than on-premise.
• All AWS prices are publicly available making budgeting easier.
• However, the major savings come from the flexibility and agility in the cloud.
• Cost management is key, it is easy to spend money unless it is managed carefully. AWS
provide tools to do this, as do many third parties, and there is a large focus on cost
optimisation.
• Possible to stand up an X1 and forget about it or not terminate volumes after detachment.
Governance structure is important but ultimately responsibility lies with the engineers.
42. Evergreening - Addressing Hardware Lifecycles
• A lot of SAP projects are driven by hardware and software end of service life.
• A system can typically be moved to new hardware with a stop/start, although sometimes
patching is required to enable new hardware.
• Some of BPs SAP systems in AWS have already been through three generations of AWS
hardware.
• Many storage changes are now made online.
43. • Architecture applies to Hana and ASE
• HA is native AWS via Amazon Cloudwatch
(restart on host fail).
• Native DB replication (Hana/ASE)
• Normal operation actively uses both AZs
• Manual DR failover (can be automated but
depends on requirements).
• Dormant app servers can be used for DR,
planned failover or load spikes (e.g.
maintenance, exceptional load).
High Availability and Disaster Recovery
Availability Zone A
App 1
App 3
(Dormant)
Availability Zone B
Active
SCS/DB
App 2
App 4
(Dormant)
Standby
SCS/DBDB Replication
Web
Dispatcher
Web
Dispatcher
DR switch via
DNS change
44. Storage Design
• Very simple design, no partitioning or striping
ü Allows online extension and volume changes
ü Supports simple snap backups
• Volume types chosen to match workload
ü General Purpose (GP2) for general usage including data
ü Low cost Cold HDD (SC1) for backups
ü High cost high I/O (IO1) can be used for very demanding workloads, so far only required to
accelerate migrations.
• Volumes are sized for optimal I/O and value (e.g. GP2 max IOPs are at 5TB so that would be
the largest GP2 volume).
45. What’s next for BP’s SAP/AWS Architecture?
• Complete SAP migrations from on-premises to AWS
• Increase use of automation
• Research and prove out use of additional AWS services within
the SAP architecture to :
• Simplify
• Reduce cost
• Reduce downtime (planned and unplanned)