Cloud Strategy
We are excited to share our experience and best practices with you. You will learn how to choose the right BTP setup and how to build secure and scalable applications on SAP BTP as single or multi-tenant versions.
With the increasing demand for speed and scalability in today's business landscape, having a cloud strategy has become essential. It is no longer something that can be ignored or delayed, as it is necessary to be able to scale up your products or landscapes at a rapid pace.
We believe that by following best practices and leveraging the right BTP setup, you can achieve your goals faster and with greater ease. We look forward to sharing our insights with you in this post, and we hope that you find it informative and useful for your own cloud journey.
We will break down this blog post into several segments, covering the essential aspects of getting started with BTP successfully:
How to get started with SAP BTP
As a company, you have several options to get started with SAP Business Technology Platform (BTP) and explore its capabilities. One popular choice is the Pay-As-You-Go (PAYG) model, which allows you to initially set up your BTP account and use most of its services free of charge up to a certain limit. This is an excellent option for initial experiments and getting started with BTP. For SAP partners there are also different price rates than for customers.
Alternatively, you can activate a free trial version of BTP, which requires no bank card or payment information. The trial version provides access to almost all services for testing purposes and is not intended for any productive use. Furthermore, some components, such as the SAP HANA database, will shut down daily overnight and the account may be deactivated or deleted if there is no activity for an extended period.
At our company, we often use the trial version to test and try out new features. It's a great way to get hands-on experience with BTP without committing to a paid plan.
Below you will find the links to the respective platforms:
What to consider and where to find information on costs and services
Before you start creating your final landscape, you need to check which BTP payment model is the most fitting for you. There are currently 2 different models available if we leave the trial aside.
- Cloud Platform Enterprise Agreement (CPEA)
- Pay-As-You-Go (PAYG)
The CPEA is a commercial model offered by cloud providers to help businesses manage their cloud costs. The CPEA is often used by larger enterprises with complex cloud needs, as it allows them to consolidate their cloud spending and manage their budget more effectively.
PAYG is a consumption-based commercial model that is commonly used in cloud computing. PAYG is often favored by businesses that have unpredictable or fluctuating workloads, as it allows them to scale their cloud usage up or down as needed and pay only for the consumed resources. This can result in cost savings and greater flexibility, as businesses can adjust their cloud spending to align with their changing needs.
To get Informations about the cost of a service or also a detailed service overview, SAP provides a highly detailed and nicely explained SAP Discover Center where you can find all needed informations.
Understanding the different terminologies and names associated with BTP
As SAP BTP continues to evolve and expand its offerings, new terms and names have emerged, leaving many customers confused or unsure of what they mean. In this section, we'll help you make sense of the jargon and provide clear explanations for each term.
The global account is the top-level account that contains all the subaccounts within an organization. S-users are assigned to the global account, which serves as the central management point for all subaccounts.
A subaccount is a second-level account that contains all the spaces where your applications or products can be stored. Subaccounts are a key component of the platform's organization structure, allowing you to isolate projects, applications or development environments.
In a multi-tenant scenario, each connected customer should have a separate subaccount where they can subscribe to your multi-tenant-enabled service or application.
A space is a third-level organizational unit within a subaccount that allows you to separate applications or environments. By creating spaces within a subaccount, you can consume global destinations or services connected to the subaccount, making it easier to manage your resources. However, keep in mind that services directly within a space cannot be accessed automatically and may require additional configuration.
Ensuring security and migration risks
Designing and architecting a cloud system is vastly different from an on-premise one. In the on-premise world, system environments are typically separated from the Internet, with ERP, backend services, and other components secured behind DMZs, proxies or other encapsulation methods. This makes it much easier to design and build solutions, as internal security measures can be relied upon. The IT department can handle the proxy settings, Cloud Connector or PI interface, allowing developers to focus on the internal use of the system.
However, cloud computing changes everything. Developers must now consider that the applications or services they create are accessible to everyone and the entire world, unless proper security measures are put in place. Ignoring security or designing it in the wrong way can result in open access to sensitive information.
So what can you do to prevent unauthorized accesses to your service or app? First, you should make sure that services which should not be accessed directly are not published to the internet. This can be done in BTP by setting your service to internal only.
Accessing your application or service in the cloud requires careful consideration of your architecture and who should have which CRUD rights. One possible solution is to create an SAP iAS instance and bind it via XSUAA to an application router. Set all routes inside the approuter to "auth required" and only the approuter will be accessible from the internet, acting as a proxy for your service. Define all your routing endpoints for your application within the approuter and redirect all routes accordingly. Any routes not explicitly defined will be rejected. This setup provides your first security layer and a secure entry point to your service.
When it comes to connecting to a HanaDB securely and keeping client, application or service data separated in different HANA schemas, there are a few things to keep in mind. It is essential to design a solid schema layout and migration setup from the beginning. Furthermore, it is also crucial to think ahead and consider how to ensure no data loss occurs in case you need to make changes to the database layout after a client requires an adaptation.
Our final tip is to avoid reinventing the wheel when connecting services or APIs. Instead, consider using tools like OpenAPI, or specifically for SAP CAP, leverage the destinations and SAP Cloud SDK for connecting. Additionally, be careful not to store API keys or other sensitive data in your code or files submitted to the version control system (e.g. git). Instead, use destinations on the BTP side or environment variables, which can be customized later in your deployed application on SAP BTP. By following these practices, you can ensure better security and avoid potential risks down the road.
Choosing the right architecture
Let's dive into the topic of selecting the appropriate architecture for your project or product to achieve stability and scalability. It is worth noting that SAP's North Star architecture is usually the optimal approach for designing complete system landscapes, modules, applications, backends and other components. But why is that the case?
To begin with, it is important to grasp the concept of the North Star architecture. Essentially, it entails adopting an event-driven microservices approach.
But what exactly does that mean?
In practice, it involves breaking down your application into various services, each with its own database schema and API endpoints, to store different types of data. This approach enables you to effortlessly scale each component, upgrade it with new versions, reuse it in other areas or integrate it into multiple scenarios.
The event-driven architecture introduces another layer on top that handles events automatically, known as the event mesh. This approach is a game-changer for your architecture as it allows you to create services raising events and other services consuming or listening to them which are completely decoupled.
For instance, let's say a car-building company is implementing an event-driven architecture. They have several microservices for different parts of the car-building process, such as a service for the engine, one for the body, one for the tires and so on. Each service has its own database schema and API endpoints.
Now, when a car is built, events can be raised by different services, such as the engine service when the engine is built or the tire service when the tires are attached. These events can be consumed by other services, such as the assembly service, which listens to these events and triggers the final assembly of the car once all parts are ready.
Designing your future landscape
Now you should be familiar with the basic knowledge and tools to start moving some of your processes to SAP BTP or one of the other hyperscalers. There are several factors to consider and multiple ways to achieve your goal, but ultimately the most critical aspects are a secure and protected environment, a stable and well-organized error handling and reporting system and monitoring functionality using SAP CloudALM or similar tools.
Below is a typical system landscape pattern for a three-system landscape to help you bring your microservices or products to BTP and integrate an S/4HANA system and third-party services. Each landscape has its unique set of requirements and complexities, so it is essential to design a customized landscape based on your specific needs and objectives.