We all are living in a world, which is changing at rapid pace and as we say — change is the only constant, is quite evident now. Many Organization’s IT department is also facing challenges to keep Organization‘s change at the same pace at which their business is changing. I am a firm believer of the statement “Technology is changing every second and it will continue to do so” and this leads to many opportunities and challenges for every organization. This blog is not intended to deep dive into which technologies and how and which of these technologies are changing day to day basis, rather than that, I would like to share my experience for one of the important technical aspect(s) of every organization, which is Public Cloud.
We all know what cloud computing is and what values it brings to any organization, as there are many online forums, talk show, blogs, etc., on this topic, however the big question comes to our mind that, should we consider moving to Public Cloud and, if yes, then what are the benefits and how should we start this journey ?
This blog focuses more on how SAP workload can or should be migrated to Public Cloud, and what are the areas, which we should take care before we embark on this journey, and continue until we reach to our goal.
In my opinion, Public Cloud’s biggest value is ‘ Freedom’, along with many others, like Scalability, Efficiency, and Agility etc. What kind of freedom does Public Cloud bring? SAP workloads are always considered as enterprise level workloads, applications and systems, which require heavy servers to support it. Every organization which have implemented SAP in past knows that implementation and hosting of SAP servers is time consuming and costly affair. Any changes in SAP server’s size or hosting is not an easy task due to its complex deployment nature.
Imagine you are planning to start new SAP implementation for your subsidiary or extending existing SAP solution to other departments, The first and foremost question will come to IT stakeholder’s mind is, which existing SAP environment should be used for this project, should we create parallel landscape for project phase, should we use existing non-production landscape, is our current production server is sufficient for additional load and many more like these. All of these questions are valid and It should be dealt before the organization starts their journey, however answers for these complex questions are quite simple on Public Cloud as Public Cloud gives you freedom to scale up(or out) existing servers on cloud or deploy new servers quickly just for the project phase. We can deep dive more into this topic however I would like to keep this part short, as our focus is not on what values it brings but how we should adopt Public Cloud.
Ok, so we have agreed to start a journey to Public Cloud for SAP workload after considering all the pros and cons, what is next? There will be many questions or aspects, which every organization needs to be discussed or agreed, some of these common questions are?
- Which Public Cloud?
- How about Hybrid Cloud?
- What are the areas, which we need to cover before we start?
- Where should I host my SAP servers?
- Which approach should we use to migrate on-premise or private cloud servers to public cloud?
- Do we need Disaster recovery systems?
- How to choose the correct server’s sizes on cloud?
- How to estimate server’s cost
There are already many proven successful stories around the world, which give insight for moving to the Public Cloud, however, as we say everyone’s journey is different, though we can take some inputs from other’s journey but we cannot follow other’s journey. In addition, the biggest challenge remains unanswered, what are the all areas, which we should try to cover and how these areas should be covered?
I am writing this blog to share my experience and point out some factors for organizations to consider before moving to Public Cloud. Every organization’s business relies on their Internal IT department to guide them or show them a path for any transformation journey. And this blog focuses more from the Internal IT department view, as in, what Internal IT department can do or to plan for Public Cloud journey. This blog will give insight to end user customer for Public Cloud Migration.
Therefore, I have categorized topics into different areas, which should be discussed or aligned before or during Public Cloud migration, please note this is not an exhaustive list, however it covers almost all aspects of Public Cloud migration, support and future innovation.
First blog focuses more on Introduction and Requirement’s section. We will discuss different areas like Things to cover during initial vendor assessment process, Public Cloud Design, and Common issues in subsequent blogs.
In my opinion, it is the most critical phase for an organization’s IT department, Every organization should spend ample time to come up with detailed requirements for Public Cloud migration projects. What should we put as requirements, we don’t have much knowledge of Public Cloud? This is our first project of moving SAP workloads to Public Cloud? Should it be just move SAP servers to cloud? Should we ask our trusted vendors to guide us and advise us what we should ask for? What are the common things we need to aligned or agree before, during and after migrating to public cloud? Should we do horizontal or vertical migration? More and more… There can be many more questions like this.
We cannot answer all the questions at same time, we would need to categories our questions or gaps in different stages. Requirements stage is an ideal stage to understand current on-premise details, align internal organization’s requirements, and draft future requirements. Below is the list of topics, which can or shall be covered in this phase:
A. Non Functional Requirements (RPO, RTO and Availability):
Availability — The first and foremost thing is availability of SAP applications, Please note we need to determine availability of SAP application not SAP servers, SAP server’s availability is driven from SAP application’s availability requirement, example application availability should be 99.99% which means your SAP application can be down for 52 minutes in a year. It also means that SAP server’s availability should be more than 99.99%. Ok, I have understood this but how to define availability for my SAP applications.
Every organization can define application’s availability based on their business critically, however we can follow some basic guidelines to standardize this section, ideally each application should have its own criticality based on two factors, 1) what type of data it holds and 2) what type of user’s accessing this application.
Applications can be categorized into different tiers based on these parameters, Tiers can be Critical, Urgent, Important, Static, etc., and for every tier there should be defined availability SLA.
RPO — Recovery Point Objective — This is another critical part of requirement, entire cloud design is dependent on this and RPO can make your solution expensive as well. RPO is a parameter, which is tightly couple with application tiring, it is essential to align RPO with application tiring definition. Critical applications should have very less RPO SLA, something like 1 minute, whereas non-critical applications can have higher SLAs. Application Tiring and RPO SLA are interdependent.
RPO drives Backup Solution, Replication Solution, DR and many more design part, so pay huge attention to this topic. You will see RPO in action in design part of this blog.
RTO — Recovery Time Objective — Another important part of requirements, this parameter make sure SAP servers come back to normal state after any disaster in specified time. RTO refers to how much time an application can be down without causing significant damage to the business. Some applications can be down for days without significant consequences and some important applications needs to be up in seconds. RTO is not simply the duration of time between loss and recovery. The objective also accounts for the steps IT must take to restore the application and its data. If IT has invested in failover services for high priority applications, then they can safely express RTO in seconds. RTO and Availability goes hand in hand.
If we see all three parameters mentioned above then we can clearly understand that it is very important to understand the criticality of your SAP application. These three parameters are core for any organization’s requirement section, These parameters have direct implication to cloud design, cost and maintenance. I would highly advise to work out these parameters with utter details and considering your user’s requirements.
Please note there are many more important NFRs like end-to-end user to application latency, future SAP growth, Data Archival, Monitoring etc. that should also be covered as part of NFR.
B. Current Landscape details, including size and utilization:
Every organization is trying to save cost along with providing values to customers and project related to public cloud migration is no different. Running workload on Public cloud give us freedom of choosing of what we want, it is like a shopping mall where you can buy anything you want. Public Cloud gives you many server options for running SAP workload, but you need to decide which servers you want to buy, very similar to shopping mall experience. How should we select servers? What inputs are needed? Answers for most of your questions lies in SAP Early Watch Alert.
It is a good idea to make an inventory for all the existing on-premise servers’ details including capacity, sizing, utilization and other parameters. This inventory can serve as starting point to understand current landscape and its usage. Please note you will need to do a mapping against current to future server requirements, these mapping can be done in later stage of project.
EWA, serves a vital document to understand the current utilization of on-premise servers, IT should review EWA for three consecutive months along with any period where user count is higher than usual, example: year-end promotions, any special promotions. One key point to check, check average user count for system login for chosen 3 months, if you see user’s average is diverting for more than 20% then please reconsider your chosen months as this cannot be reliable information.
Please note, this exercise will also help you to understand what type of server instance you would need to buy, RI and On-Demand instances are two types of servers for any Public Cloud solution and it is very important to understand which types of servers you will opt for.
There are some basic guidelines, which we should follow to decide about RI or on-Demand server types. Production servers should always be on RI, Non — production servers can be chosen between RI or On-Demand, Training severs are ideal candidates for on-demand instance, and if you have, training severs. Please note whole process of identifying which instance is based on your current system utilization report.
This exercise also serve another very important aspect, which is future SAP landscape. Every Organization usually have 3 or more tier landscape, Dev, Quality, Production, others. Every organization should review their existing landscape’s utilization and see if they really needs to run whole separate environment, if utilization is low. On-premise to Cloud migration for servers can be one to one, however this is not a mandatory requirement, review current environments and predict future requirements. As I mentioned before, Public Cloud gives us freedom to be agile in spinning or removing servers on cloud so don’t hesitate to experiment, in order to simplifying your landscape on Public Cloud and also in saving cost.
RI or On-Demand instance types selection for servers is very critical decision from cost perspective and deciding this upfront can be huge cost saving exercise.
C. Chance to change heterogeneous landscape to homogeneous:
Managing workloads on Public Cloud needs human effort and it becomes BAU cost for every organization. Activities like applying patches on server, taking regular and ad-hoc backups, aligning servers with latest security features, etc. Your trusted service provider will help you to perform all these activities, but having diverse server footprints increases complexity in design and support cost goes significantly up. In my opinion, it is an ideal time to see your existing server’s entire footprint and see if you can simplify your landscape from heterogeneous to homogeneous landscape. Question comes in our mind what server’s we are talking and how? Review all existing OS’s in your landscape and see if you can move from diverse OS design to single OS design, example: can we have all applications severs on windows and all database servers on Linux. This can really save a lot of maintenance cost over the period. Please do see SAP recommendations for all the application in scope, SAP has already defined guideline on application vs OS compatibility.
Caution — Please be aware that changing OS types have cascading effect on existing file directory names, so please keep this in mind.
D. Service catalog for managed service:
This is my personal favorite area as Service catalog is something, which gives you freedom in the future for any maintenance activities on Public Cloud by your selected supplier. Please be aware that moving SAP workloads to Public Cloud is just a start of cloud journey and real benefits can only be seen over the period in BAU phase and, if you can predict your future support needs on Public Cloud then you are already won half of the battle.
Questions like, I am not sure what are the services should my vendor provide on Public Cloud, what are the areas they should cover? Should they cover only networks and applications? On the other hand, they should also cover security, backup, DR, etc. are important topics, which needs discussion and alignment. Imagine a scenario where you have migrated all your workload to public cloud and then many services are not supported by anyone. Cloud Platform always need manage service for all components and there are many areas, which needs attention from day one.
I term all future support services on Public Cloud as ‘Managed Service’ and it becomes essential to have service catalog for these managed services. Managed Service catalog serves two purposes, 1) Scope and 2) Service Delivery expectation. SR catalog items needs to be very detailed and every organization should cover all possible areas for cloud, example of areas are below:
- Server Management
- OS Management
- DB management
- Storage Device/Data Services
- Networking services
- Cloud Operation and Security
Please note this is not exhausting list, there are few more areas which needs to be discussed and agreed, also each of these areas should have detailed tasks list defined under it. This is also a good idea to have some estimated numbers against each SR, example number of servers, how many patches in a month, etc.
E. Success factors:
Like any other project, Public Cloud migration project should also have measurable success factors, ok, so what should it be? In my opinion, Public Cloud migration can be consider successful based on three parameters:
Accessibility — Biggest challenge for cloud migration projects is to keep SAP access channel same as before, imagine you have thousands of SAP’s users who are accessing existing on premise SAP on daily basis and after cloud migration this needs to changed or modify. None of the organization would like to take this risk, so access to SAP systems on cloud should be seamless for the entire user. This should be given as requirement upfront as this can have huge design impact if not dealt properly. Keep an eye to Active Directory solution to make this happen.
Performance — Another critical factor, many organizations suffers due to this. What should we do make our system’s performance acceptable on cloud? There are few areas, which needs special attention to make sure we do not have performance issue, areas like:
- Region selected for hosting SAP workload
- System sizes
- Network path between organization’s location and Public Cloud
Security — As we all can imagine security on public cloud is an important area, ok, so what should we do? Every organization should make sure their data on cloud is encrypted, ok, this is general assumption, and how can we do this? Make sure all DBs on cloud have in build feature of DB encryption as a pre-requisite and define required security catalog, please refer above service catalog architecture to understand this in detail.
The most important aspect to look out here is network path between your organization’s network and Public Cloud, This can make a huge difference in overall end to end performance. Design solution very carefully here and make sure you test this part upfront to avoid any last minute hiccups.