At SapphireNow 2017, our annual user conference, SAP emphasized its vision of bringing Openness to the enterprise by announcing general availability of Cloud Foundry within the SAP Cloud Platform (link here) and rolled out the multi-cloud architecture underneath. As a part of this announcement, SAP also introduced the option of consuming open-source, industry-proven, and community-loved technologies as 'Backing Services' with Enterprise-grade features to build business applications (link here).
Applications and microservices built on Cloud Foundry, would of course require one or the other 'backing' services like PostgreSQL, Redis, and so on, for persistence, caching and other needs.
So, what is the best possible way to provide these services on the SAP Cloud Platform?
Let us look at the above problem from 2 different perspectives:
Let us consider this real-world scenario:
John, a service provider, plans to offer “Service-A” as a part of the marketplace in his platform. Ideally, he would need to write a Service Broker for Service-A & register it, so that any consumer who wants to use the service can use the broker for service instance creation and provisioning. Next, he also wants to include support for operations like backup and restore for Service-A. He spends a significant amount of time including the ‘hooks’ for this functionality into his service broker.
Done! Service-A can now be created and provisioned automatically; Also, we can backup and restore the service in an unattended way. Great!!
But, is it necessary that John spends efforts to build these enterprise qualities to his service???
Now his colleague Jane, wants to offer “Service-B” in the platform. Service-B is not too different from Service-A, in that, it needs a set of additional parameters, for it to function correctly.
Jane must now follow almost ALL the steps John followed, to create her own service-broker for Service-B.
What can Jane do here??!!
Any provider who wants to provision his service on the platform, would need a tool/service broker, which can help him deploy his service and provision an instance, easily and quickly on the platform.
In the world of cloud applications, these service instances can grow at an exponential rate and run into numbers of hundreds, if not thousands, very quickly. So, it is not enough if the tool/broker helps to provision instances. It is essential that it also helps in managing these instances; else monitoring, upgrading, patching of service instances can quickly get out of hand.
Additionally, if the service should be provided on multiple infrastructure providers like AWS, Azure, etc., the service implementation needs to adhere to the requirements of the underlying infrastructure, which requires additional efforts.
Hence, we need a solution to make the operator's life easy...
Let us consider this real-world scenario:
Steve, is an application developer who wants to build an online chat application using Node.js, and requires a MongoDB “backing” service to store the conversations. He does not want to install MongoDB on his laptop, which would add additional effort for maintaining it and does not have a direct path when he moves his application into production. All he needs is a small MongoDB instance which he can use for development and testing purposes. Once he is confident of the application and its capabilities, he would then move to a productive MongoDB instance.
What can Steve do here??!!
Any developer who wants to build cloud foundry applications would require one of the backing services in his application. It would be great if he can get a non-expensive service instance for developing and testing his application and then move onto a production-ready, enterprise-grade service cluster, without having to make any changes to his application code.
Hence, we need a solution to make the developer's life easy...
In addition to these perspectives, when we talk about enterprise application development and operations, there are a few cloud qualities like high-availability, scalability, fault tolerance, backup & restore and so on, which are expected from every service used in the application.
Service Fabrik is SAP's multi-cloud, enterprise service provisioning, management and operating solution. It has the capability to spawn single node Docker container-based service instances and managed enterprise grade, BOSH-based, multi-node service clusters.
Application developers can now choose to start their development of polyglot applications using single node containers, test them thoroughly and switch to the Enterprise-grade service clusters, as and when the application matures and is ready to get into production.
In addition to provisioning, we have also built-in additional capabilities like instance monitoring, alerting, logging, update support, backup & restore, automatic failover in case of instance down times, and so on.
In other words, Service Fabrik is THE solution which can help you to provision, maintain and operate Cloud Foundry services as “Managed” services.
What is the proof you ask??
Service Fabrik is the work-horse or the factory (Fabrik = factory in German) which takes care of provisioning and managing enterprise-grade backing services on the SAP Cloud Platform today. We already have hundreds of BOSH based & thousands of container based service deployments running in production, which are deployed by Service Fabrik.
To take the Openness story to the next level, at the Cloud Foundry Summit 2017 held in Santa Clara, California, we announced that Service Fabrik will be open-sourced.
We are proud to announce that today on August 21st 2017, we have made a proposal to include Service Fabrik as a Cloud Foundry incubation project and we look forward to continue evolving it together with the community!!
Service Fabrik code can be found here. We welcome you to try out Service Fabrik and share your valuable feedback with us.
Github repository details below:
[1] service-fabrik-boshrelease - Bosh release to deploy service fabrik
[2] service-fabrik-lvm-volume-driver - Logical volume driver for docker based service
[3] service-fabrik-blueprint-service - Test service to try out service fabrik
[4] service-fabrik-blueprint-app - Test app to try out blueprint service
[5] service-fabrik-blueprint-boshrelease – Bosh release for blueprint service
[6] service-fabrik-backup-restore – Library for backup & restore of service instances.
Watch this space for more information on the architecture, features of Service Fabrik and tutorials on working with Service Fabrik.
See you soon!
Applications and microservices built on Cloud Foundry, would of course require one or the other 'backing' services like PostgreSQL, Redis, and so on, for persistence, caching and other needs.
So, what is the best possible way to provide these services on the SAP Cloud Platform?
Let us look at the above problem from 2 different perspectives:
1. Service Provider / Operator perspective
Let us consider this real-world scenario:
John, a service provider, plans to offer “Service-A” as a part of the marketplace in his platform. Ideally, he would need to write a Service Broker for Service-A & register it, so that any consumer who wants to use the service can use the broker for service instance creation and provisioning. Next, he also wants to include support for operations like backup and restore for Service-A. He spends a significant amount of time including the ‘hooks’ for this functionality into his service broker.
Done! Service-A can now be created and provisioned automatically; Also, we can backup and restore the service in an unattended way. Great!!
But, is it necessary that John spends efforts to build these enterprise qualities to his service???
Now his colleague Jane, wants to offer “Service-B” in the platform. Service-B is not too different from Service-A, in that, it needs a set of additional parameters, for it to function correctly.
Jane must now follow almost ALL the steps John followed, to create her own service-broker for Service-B.
What can Jane do here??!!
Any provider who wants to provision his service on the platform, would need a tool/service broker, which can help him deploy his service and provision an instance, easily and quickly on the platform.
In the world of cloud applications, these service instances can grow at an exponential rate and run into numbers of hundreds, if not thousands, very quickly. So, it is not enough if the tool/broker helps to provision instances. It is essential that it also helps in managing these instances; else monitoring, upgrading, patching of service instances can quickly get out of hand.
Additionally, if the service should be provided on multiple infrastructure providers like AWS, Azure, etc., the service implementation needs to adhere to the requirements of the underlying infrastructure, which requires additional efforts.
Hence, we need a solution to make the operator's life easy...
2. Application Developer perspective
Let us consider this real-world scenario:
Steve, is an application developer who wants to build an online chat application using Node.js, and requires a MongoDB “backing” service to store the conversations. He does not want to install MongoDB on his laptop, which would add additional effort for maintaining it and does not have a direct path when he moves his application into production. All he needs is a small MongoDB instance which he can use for development and testing purposes. Once he is confident of the application and its capabilities, he would then move to a productive MongoDB instance.
What can Steve do here??!!
Any developer who wants to build cloud foundry applications would require one of the backing services in his application. It would be great if he can get a non-expensive service instance for developing and testing his application and then move onto a production-ready, enterprise-grade service cluster, without having to make any changes to his application code.
Hence, we need a solution to make the developer's life easy...
In addition to these perspectives, when we talk about enterprise application development and operations, there are a few cloud qualities like high-availability, scalability, fault tolerance, backup & restore and so on, which are expected from every service used in the application.
Enter Service Fabrik!!
Service Fabrik is SAP's multi-cloud, enterprise service provisioning, management and operating solution. It has the capability to spawn single node Docker container-based service instances and managed enterprise grade, BOSH-based, multi-node service clusters.
Application developers can now choose to start their development of polyglot applications using single node containers, test them thoroughly and switch to the Enterprise-grade service clusters, as and when the application matures and is ready to get into production.
In addition to provisioning, we have also built-in additional capabilities like instance monitoring, alerting, logging, update support, backup & restore, automatic failover in case of instance down times, and so on.
In other words, Service Fabrik is THE solution which can help you to provision, maintain and operate Cloud Foundry services as “Managed” services.
What is the proof you ask??
Service Fabrik is the work-horse or the factory (Fabrik = factory in German) which takes care of provisioning and managing enterprise-grade backing services on the SAP Cloud Platform today. We already have hundreds of BOSH based & thousands of container based service deployments running in production, which are deployed by Service Fabrik.
To take the Openness story to the next level, at the Cloud Foundry Summit 2017 held in Santa Clara, California, we announced that Service Fabrik will be open-sourced.
We are proud to announce that today on August 21st 2017, we have made a proposal to include Service Fabrik as a Cloud Foundry incubation project and we look forward to continue evolving it together with the community!!
Eager to try it out??
Service Fabrik code can be found here. We welcome you to try out Service Fabrik and share your valuable feedback with us.
Github repository details below:
[1] service-fabrik-boshrelease - Bosh release to deploy service fabrik
[2] service-fabrik-lvm-volume-driver - Logical volume driver for docker based service
[3] service-fabrik-blueprint-service - Test service to try out service fabrik
[4] service-fabrik-blueprint-app - Test app to try out blueprint service
[5] service-fabrik-blueprint-boshrelease – Bosh release for blueprint service
[6] service-fabrik-backup-restore – Library for backup & restore of service instances.
What next??
Watch this space for more information on the architecture, features of Service Fabrik and tutorials on working with Service Fabrik.
See you soon!
- SAP Managed Tags:
