Without proper architectural and operational support from the underlying platform, cloud-native applications, which typically comprise of multiple microservices, could quickly become unmanageable. In this blog, I would like to discuss how the SAP Web IDE Full-Stack and the application programming model it supports for developing end-to-end business applications addresses this problem by driving consistency of design, development and operations across the related microservices.
A key motivation for taking application projects to Cloud is to gain unlimited scale, demand-driven elasticity and high availability. However, this requires Cloud applications to be designed as stateless microservices, offering granular functionality, exposed via standards-based API endpoints. I think we all know the famous 12-factor app methodology very well by now. Each microservice is typically owned by a dedicated team, with complete freedom to make technological choices for implementation along with full responsibility for development as well as operations (DevOps) of the microservice.
However, when a group of microservices are involved in materializing a larger cloud application, and if the teams in charge of these microservices work separately from each other, it may lead to overall inefficient designs and complex operations. In addition, the variety of technological choices made by the independently operating teams may result into technological bloat and slow down the overall pace of innovation.
These are some of the valid concerns we hear from the enterprise developers and architects involved in large scale cloud application projects. As an enterprise-grade platform, SAP Cloud Platform addresses these concerns via integrated tooling and technologies, without compromising the fundamental benefits of the cloud-native application development principles.
We can achieve greater efficiencies of design by sharing definitions of commonly used data models across the related microservices. Likewise, operations can be simplified by treating the collection of related microservices as a holistic unit from the lifecycle management perspective. In addition, the burden of choosing technologies can be eased by including built in support for popular languages, frameworks and libraries based on best practices. The features and tools integrated in SAP Web IDE Full-Stack along with the application programming model help mitigate these concerns. Let us look at each of these aspects separately …
As depicted by the examples of cloud-native applications such as the tutorial for Application Programming model, or the exercises for the TechEd hands-on session for cloud-native application development, it is a common pattern to:
You can, of course, independently design and implement the microservices for the UI, service and data layers mentioned above, and have them consume each other’s’ services via their published API, and essentially not worry about the data models used by their implementation, etc. However, since these microservices are part of the same larger cloud application, their design, development as well as maintenance can be a lot more efficient by sharing definitions of the data models common across the different microservices.
Note that each of these layers in the architecture – data, services and UI – have a rich heritage of data modelling technologies that are well suited for that layer. For example, there are plenty of tools for entity relationship modelling for the data layer. Likewise, there are numerous technologies for designing service API or UI controls, etc.
What is needed to allow sharing of commonly used data models and other declarations across the layers effectively is a language for codifying the shared models in an abstract manner that is booth tool-able (translatable to the layer specific models via code generation, etc.) as well as human readable. This is where Core Data Services (CDS in short) comes into the picture. If the previous description was a bit thick to parse, just check out the following example snippets of CDS models of data and services:
As shown above, first, you can define the data models using CDS for the data layer. The data entities may be pre-existing or may be newly created. For the service layer, we can then simply reference the CDS definition of data models and with merely one or two lines, declare which data entities are to be exposed as services and what CRUD operations are to be exposed by the service, etc. Furthermore, the UI layer can benefit from the CDS models by adding OData annotations for shaping the UI controls, providing alternative locale specific texts, and much more.
For more details, check out the blogs introducing the Application Programming model and sharing some first-hand experiences of putting it in action. You can also watch presentations on Web IDE Full stack from the recent SAP TechEd events. My goal here is not to cover the features and benefits of CDS exhaustively but mainly to point out how CDS is a cool technology that enables driving consistency of design across related microservices and thereby simplifies large scale cloud-native application development.
Typically, microservices are developed and managed by separate teams in an organization. At the same time, for enterprise cloud applications comprising of multiple microservices, there is a need to coordinate the life cycle of the related microservices together, which requires proper tools and technologies to:
This is where the Multi-Target Application (MTA for short) model comes into the picture. This technology is developed by SAP and is contributed as an Open Source project to the Cloud Foundry Foundation for its further evolution. The application programming model for SAP Cloud Platform, supported by the SAP Web IDE Full-Stack makes full use of the MTA technology. Currently, it is possible to build and deploy cloud application projects, with multiple modules for database, services, UI, etc, and deploy them as a single unit to the Cloud Foundry environment of SAP Cloud Platform.
Here are a couple of screen shots that show the MTA editor in the SAP Web IDE Full-Stack tooling and how it allows direct deployment to the Cloud Foundry environment:
You can check out this blog for a description of the MTA concept and how it relates to microservices. Again, the point of my current blog is not to exhaustively cover the features of MTA technology but mainly to point out that MTA fills a critical gap in the world of microservices – how to holistically manage the lifecycle of microservices belonging to the same cloud-native application!
The above-mentioned technologies – CDS and MTA – are currently leveraged in the SAP Web IDE Full-Stack tooling for consistent development and operations of microservices built using technologies such as SAP HANA, Java, Node.js and SAPUI5. However, please note that the platform remains open for other programming languages, frameworks, backing services, UI technologies, infrastructure options for deployment etc.
As noted in this blog about how SAP Cloud Platform is both Open as well as Opinionated, the key principle here is to retain complete openness but at the same time, provide tooling that allows customers and partners to take an opinionated golden path based on best practices and not get lost in the myriad choices of technologies.
Here is my favorite picture from a recent TechEd presentation on the topic of Application Programming model of SAP Cloud Platform:
In the above picture, I have highlighted in yellow the commonly used combination of technologies for full-stack cloud application development using the SAP Web IDE Full-Stack tooling. What is interesting to note is the long list of numerous other technologies one may want to use for cloud-native application projects – some of these options are already supported today, with the others being planned out.
As you can guess, I am quite excited about the application programming model of SAP Cloud Platform, which brings the technologies together and simplifies the development as well as operations of large scale cloud-native application projects, in a future-proof manner. Hopefully this blog also makes you a bit curious to learn more about it and give it a try. Looking forward to hearing your feedback and comments …
The problem statement: How to build microservices that are independent and cohesive at the same time?
A key motivation for taking application projects to Cloud is to gain unlimited scale, demand-driven elasticity and high availability. However, this requires Cloud applications to be designed as stateless microservices, offering granular functionality, exposed via standards-based API endpoints. I think we all know the famous 12-factor app methodology very well by now. Each microservice is typically owned by a dedicated team, with complete freedom to make technological choices for implementation along with full responsibility for development as well as operations (DevOps) of the microservice.
However, when a group of microservices are involved in materializing a larger cloud application, and if the teams in charge of these microservices work separately from each other, it may lead to overall inefficient designs and complex operations. In addition, the variety of technological choices made by the independently operating teams may result into technological bloat and slow down the overall pace of innovation.
These are some of the valid concerns we hear from the enterprise developers and architects involved in large scale cloud application projects. As an enterprise-grade platform, SAP Cloud Platform addresses these concerns via integrated tooling and technologies, without compromising the fundamental benefits of the cloud-native application development principles.
We can achieve greater efficiencies of design by sharing definitions of commonly used data models across the related microservices. Likewise, operations can be simplified by treating the collection of related microservices as a holistic unit from the lifecycle management perspective. In addition, the burden of choosing technologies can be eased by including built in support for popular languages, frameworks and libraries based on best practices. The features and tools integrated in SAP Web IDE Full-Stack along with the application programming model help mitigate these concerns. Let us look at each of these aspects separately …
Sharing of Data Models
As depicted by the examples of cloud-native applications such as the tutorial for Application Programming model, or the exercises for the TechEd hands-on session for cloud-native application development, it is a common pattern to:
- Model the data entities to be stored in and managed by a database
- Expose select data entities as services via standards for ubiquitous access such as OData, and
- Finally consume the OData services from UI applications.
You can, of course, independently design and implement the microservices for the UI, service and data layers mentioned above, and have them consume each other’s’ services via their published API, and essentially not worry about the data models used by their implementation, etc. However, since these microservices are part of the same larger cloud application, their design, development as well as maintenance can be a lot more efficient by sharing definitions of the data models common across the different microservices.
Note that each of these layers in the architecture – data, services and UI – have a rich heritage of data modelling technologies that are well suited for that layer. For example, there are plenty of tools for entity relationship modelling for the data layer. Likewise, there are numerous technologies for designing service API or UI controls, etc.
What is needed to allow sharing of commonly used data models and other declarations across the layers effectively is a language for codifying the shared models in an abstract manner that is booth tool-able (translatable to the layer specific models via code generation, etc.) as well as human readable. This is where Core Data Services (CDS in short) comes into the picture. If the previous description was a bit thick to parse, just check out the following example snippets of CDS models of data and services:
As shown above, first, you can define the data models using CDS for the data layer. The data entities may be pre-existing or may be newly created. For the service layer, we can then simply reference the CDS definition of data models and with merely one or two lines, declare which data entities are to be exposed as services and what CRUD operations are to be exposed by the service, etc. Furthermore, the UI layer can benefit from the CDS models by adding OData annotations for shaping the UI controls, providing alternative locale specific texts, and much more.
For more details, check out the blogs introducing the Application Programming model and sharing some first-hand experiences of putting it in action. You can also watch presentations on Web IDE Full stack from the recent SAP TechEd events. My goal here is not to cover the features and benefits of CDS exhaustively but mainly to point out how CDS is a cool technology that enables driving consistency of design across related microservices and thereby simplifies large scale cloud-native application development.
Shared life cycle of microservices
Typically, microservices are developed and managed by separate teams in an organization. At the same time, for enterprise cloud applications comprising of multiple microservices, there is a need to coordinate the life cycle of the related microservices together, which requires proper tools and technologies to:
- Capture the dependencies of microservices upon each other and the underlying backing services
- Configure the overall package of microservices as a unit of deployment
- Handle deployment of the package of microservices to their individual runtimes
- Manage the overall lifecycle of the deployed packages
This is where the Multi-Target Application (MTA for short) model comes into the picture. This technology is developed by SAP and is contributed as an Open Source project to the Cloud Foundry Foundation for its further evolution. The application programming model for SAP Cloud Platform, supported by the SAP Web IDE Full-Stack makes full use of the MTA technology. Currently, it is possible to build and deploy cloud application projects, with multiple modules for database, services, UI, etc, and deploy them as a single unit to the Cloud Foundry environment of SAP Cloud Platform.
Here are a couple of screen shots that show the MTA editor in the SAP Web IDE Full-Stack tooling and how it allows direct deployment to the Cloud Foundry environment:
You can check out this blog for a description of the MTA concept and how it relates to microservices. Again, the point of my current blog is not to exhaustively cover the features of MTA technology but mainly to point out that MTA fills a critical gap in the world of microservices – how to holistically manage the lifecycle of microservices belonging to the same cloud-native application!
Open and opinionated – Bringing it all together!
The above-mentioned technologies – CDS and MTA – are currently leveraged in the SAP Web IDE Full-Stack tooling for consistent development and operations of microservices built using technologies such as SAP HANA, Java, Node.js and SAPUI5. However, please note that the platform remains open for other programming languages, frameworks, backing services, UI technologies, infrastructure options for deployment etc.
As noted in this blog about how SAP Cloud Platform is both Open as well as Opinionated, the key principle here is to retain complete openness but at the same time, provide tooling that allows customers and partners to take an opinionated golden path based on best practices and not get lost in the myriad choices of technologies.
Here is my favorite picture from a recent TechEd presentation on the topic of Application Programming model of SAP Cloud Platform:
In the above picture, I have highlighted in yellow the commonly used combination of technologies for full-stack cloud application development using the SAP Web IDE Full-Stack tooling. What is interesting to note is the long list of numerous other technologies one may want to use for cloud-native application projects – some of these options are already supported today, with the others being planned out.
As you can guess, I am quite excited about the application programming model of SAP Cloud Platform, which brings the technologies together and simplifies the development as well as operations of large scale cloud-native application projects, in a future-proof manner. Hopefully this blog also makes you a bit curious to learn more about it and give it a try. Looking forward to hearing your feedback and comments …
- SAP Managed Tags:
4 Comments
