In this unit, we delve into the ABAP Cloud development model (ABAP Cloud), the model in which cloud native applications can be both built in and run on ABAP. But as ABAP Cloud is partly inspired by the emergence of cloud computing and the cloud native paradigm, a brief discussion of both topics is warranted.
As discussed in the course S4CP01: Exploring SAP Cloud ERP, in today's business climate, companies need to adapt business processes quickly to respond to changing business conditions and changing customer demands. This need for adaptation requires applications that are scalable, sturdy, and importantly, flexible. Cloud computing environments are one way that this need is addressed. The other is cloud native.
Cloud computing is still computing, but cloud computing is designed in a different way than from the typical on-premise data center infrastructure that IT personnel have traditionally been used in the past. With on-premise infrastructure (often referred to as an on-premise data center), the customer is responsible for the installation and maintenance of physical elements, such as servers and networking equipment. With cloud computing, these infrastructure components are provided by an external cloud provider.
Generally speaking, the following components are provided by the cloud provider:
- Servers (providing compute and memory capacity)
- Operating systems and virtualization
The initial setup of these components, as well as their ongoing operations, maintenance, and upgrades, is handled by the cloud provider.
Cloud Computing Principles
These components are made available to the customer using the following principles:
Most organizations experience peaks and valleys in resource usage. Payroll, for example, may run twice a month and during those times, extra network and server capacity is warranted. Cloud providers typically have an elasticity feature for customers as part of their offering. This way, as more resources are needed, they can be allocated and both individual and overall application performance can be maintained at desired levels.
Cloud computing components are offered to customers at an agreed upon pricing and consumption plant. This can vary from provider to provider. SAP, for example, offers various runtimes and services as part of its Platform as a Service (PaaS) offering SAP BTP, in not only asubscription-based plan, but also two different types of consumption-based purchase plans.
Returning to the payroll example mentioned previously, the availability of cloud computing resources is semi-monthly (assuming payroll runs twice per month). For other types of business processes (supply chain management processes, for example), the availability varies depending on the type of process in question and how the company chooses to operate. For larger organizations especially, it is fair to say that 24 hours a day, seven days a week, at least one process needs resources to be able to execute. That's where availability comes into play. As part of their offering, cloud providers transparently communicate the expected availability of their components to customers. Again, while technically not required, almost all providers offer a 24x7 availability option, giving customers maximum flexibility if certain operations need to execute continuously or at unpredictable intervals.
- Service Level Agreement (SLA)
Closely related to availability is service level agreement (SLA). Whereas availability is usually expressed as a number (24x7), SLA adds in a time dimension (that is, 24x7 for 99.99% of the month). Using this example, if a month has 30 days that would translate to 43,200 minutes (30 days times 24 hours per day times 60 minutes per hour). At a 99.99% SLA, the system would not be available (over the course of that month) for about four and a half minutes (.0001 times 43200).
Is There a Difference?
While at first it may be tempting to think, "Other than the provider, it seems that there is no practical difference between cloud computing and a customer-provided data center" this should not be the case. The consequences of having computing infrastructure provided by a cloud provider mean that software applications should be designed to be infrastructure independent. They should run the same regardless of the specific server, OS, or storage system being provided by the cloud provider. It's entirely conceivable a cloud provider may change its infrastructure frequently. As well as that, a customer may decide to change cloud providers (that is, a different provider provides superior SLA performance). Moreover, the need to adapt applications quickly means that testing an application on different types of infrastructure to ensure compatibility should not be necessary, not to mention the time and cost of developing different versions of an application just so that it can run on different infrastructure types, which once again is a non-starter. From the point of view of the developer (and ultimately the end user), the infrastructure components used in cloud computing is an abstraction.
To ensure this abstraction, a top to bottom rethinking of programming models, tools, and technologies used to do application development and maintenance is required in cloud computing. Cloud native has emerged as the result of this rethinking.
What Is Cloud Native?
Cloud native is, first and foremost, an approach – an approach to developing, deploying, and maintaining software applications in a cloud computing environment, which enables fast application adaptability and flexibility. While the specific definition of cloud native varies from source to source, depending on whose definition is being used, there are a few components that all definitions generally agree on and become very important in the understanding of the ABAP Cloud development model:
- Infrastructure independent
- Application Programming Interfaces (APIs)
As previously mentioned, the cloud provider provides the infrastructure components, which comprise a cloud computing environment (that is, network, servers (providing compute and memory capacity), storage, operating systems, and virtualization). Different cloud providers provide these resources using different techniques, configurations, brands, and so on. A cloud native application runs the same regardless of these differences and regardless of the cloud provider.
Many cloud native programming models follow a three-layer approach to application development. The first is the user layer (sometimes referred to as the consumption layer), which is responsible for the visual rendering of the user interface that end users interact with. Second is the data layer, which is where the data that the application needs is permanently stored in some data source (normally a database). In between these two layers is the service layer. The service layer responds to requests triggered by the user layer on one side and in doing so performs operations on the data in its data source at the data layer level. These operations are commonly categorized in the following four types, which are often referred to as CRUD operations:
While not required, these layers are often designed to run in different locations and in different types of runtime environments. Some of these locations and environments may be cloud-based, others on-premise based. This hybrid approach is not uncommon and used by many customers. Microservices design means that each layer is implemented as its own standalone piece. As such, it can be maintained and adapted separately from the other layers while at the same time being able to communicate and coordinate with them in the context of a complete application.
Application Programming Interfaces (APIs)
The communication and coordination referred to in the previous section is carried out by the use of APIs. An API is a technique by which two pieces of software can communicate with each other and exchange or manipulate information using agreed upon data definitions and representations (these are often referred to as a protocol). For example, an app that most people have used is a banking app that allows the user to execute various functions, such as checking the balance of their account or initiating a funds transfer to pay a bill. The app can be accessed freely over the internet using the banks Web site, or installed on a mobile phone. Either way, the design of the app is such that behind the scenes, it uses one or more APIs to perform the various banking functions requested by the app end user. Each API is designed to perform some task an app may need and is typically available "on demand" to be used. The usage is usually based on some form of a "call and response" process (that is, the app makes the call to the API and the API responds in some way).
The bank in this scenario provides the APIs (since they have legal governance of bank accounts) and at their discretion, they may make them available for third-party usage (developers who design products where they wish to add banking features, for example) as well as utilize the APIs themselves in their own app development. APIs have been around for many decades and predate cloud computing. However, the API concept has evolved to encompass the needs of cloud computing and microservices development. One of the ways this evolution has manifested itself is in the adoption of one of the most common API architectures in use today: Representational State Transfer (REST).