Cisco and Google Hybrid Cloud through Service Broker - Part 1
Cisco and Google Hybrid Cloud through Service Broker - Part 1
Make things a little easier using Service Broker for hybrid cloud optimization.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
You have heard this Cisco and Google Hybrid Cloud through service broker. This is the first part of the series where I cover the usage of Service Broker and its components with the lifecycle.
Hybrid Cloud Platforms
It is a new reality. We are in the multi-cloud world. To create more innovative solutions and speed up the market-ready product delivery, a hybrid cloud approach is the key to eliminating multi-cloud complexity.
There are a lot of use cases and options to achieve a hybrid cloud between Cisco Container Platform (CCP) and Google Cloud Platform (GCP). In this series of the articles, let's us see the hybrid cloud using the open service broker API option.
Key Use Cases of Hybrid Cloud
- Running apps in a public cloud environment and consumes data from on-premises
- Running apps on-premises which consumes public cloud services.
- Leverage CI/CD in both cloud and on-premises.
What is Open Service Broker API?
"Connect anything" is the key principle of Service Broker API irrespective of platform. The Open Service Broker API (OSB) project allows independent SaaS providers, software vendors, and developers to easily provide backing services to workloads running on cloud-native platforms such as Cloud Foundry and Kubernetes.
The catalog describes all of the services that can be provisioned through a service broker, and each service is made up of plans. Plans typically represent the costs and benefits for a given variant of the service.
Service brokers manage the lifecycle of services, and platforms interact with service brokers to provision, get access to, and manage the services they offer.
A service instance is a provisioned instance of a service and plan as described in the service broker’s catalog.
Each service broker built to the Open Service Broker API spec has the same intuitive set of lifecycle commands. Commands to fetch the catalog of services and plans, provision new service instances, connect and disconnect from those service instances, and de-provision service instances are the same for all OSBAPI-compliant brokers.
When a service binding is made against the service instance, authentication information and parameters required by developer application would be given out unique to the service instance.
Authentication information would be persisted in an encryption format called secret which will be used by the application to consume cloud services offered by service catalog.
- Application developers can connect their applications and containers to the back-end services they need. No changes in the operation, irrespective of back-end service.
- Infrastructure team no longer must manually provision and delegate access to services. Instead, they simply configure a marketplace of services and service plans. From there, developers can self-serve, reducing the administrative overhead many enterprises face today.
What is Cisco Container Platform?
CCP is a lightweight container management platform for production-grade environments, powered by Kubernetes.
Nobody likes the manual work of deploying, monitoring, and managing them — especially across multiple public and private clouds. But this CCP reduces the complexity of configuring, deploying, securing, scaling and managing containers through automation and simplified UI page.
Cisco Devnet provides a free sandbox developer login for CCP. It helps the application developer to log in and play with research and developments.
No additional configuration. It just a key start to get started fast, with a single, integrated stack that addresses container orchestration, management, networking, load balancing, storage, security, and analytics and in a simple, easy-to-play with the platform.
Open to All
CCP is based on open-source components, such as 100% upstream Kubernetes container engine, Docker Image, etc.
Flexible for All
Since all its components are open source based, there’s no limitation. And it would run anywhere, with consistent deployment across all infrastructure, VM Instances, public and private clouds.
No Risk at All
This production-ready platform is developing and maintaining by Google and Cisco cloud team. Provides lots of documents, faqs with all troubleshooting. It is the production-grade risk-free platform.
GCP Service Broker simplified the provision and delivery of its service to applications that run on Kubernetes. It can be achieved by creating GCP resources along with necessary permissions. Service Broker makes it easy to consume GCP services from within your own Kubernetes cluster.
GCP and CCP Hybrid Cloud Services Through GCP Service Broker
This approach extends GCP services to CCP on-premises environments. On this, applications which are running on CCP can be future-proofed to consume GCP services using a consistent set of APIs.
Let us see how can provision GCP Services from CCP and leverage in the application in upcoming articles.
- Provision and Consume GCP Pub-Sub services from CCP and test it using Spring Boot
- Provision and Consume GCP Big Query services from CCP and test it using Spring Boot 2.0
- Leverage CCP CI/CD to push application image to GCP Container Registry and deploy it
In normal usage, in a Spring Boot application, .properties does contain all credentials and project details to consume GCP Services as like below whereas, in service broker mode, all of that would be taken care by service binding as discussed above.
spring.cloud.gcp.project-id=xxxxxx-216107 spring.cloud.gcp.credentials.location=classpath:xxxxxx-216107-87755105eb1a.json spring.cloud.gcp.config.credentials.scopes=https://www.googleapis.com/auth/bigquery spring.cloud.gcp.config.enabled=true
Please have a look at source code for the GCP pub-sub implementation through service broker using Spring Boot 2.0.
Hybrid Services through Service Broker is the cleaner and modular way as there is no additional configuration like which endpoints to be used, which credentials need to be passed, or what kind of permission to provide to consume cloud services. Sample working codebase added to this article.
In Part 2, I’ll deep dive into the details of consuming GCP Pub-Sub services from custom Spring Boot application deployed in Kubernetes Cluster that running in Cisco Container Platform through Google Service Broker including Service Broker and Catalog set up. Also, a step by step explanation will be given in detail for the source code given on this article.
Opinions expressed by DZone contributors are their own.