Cloud Foundry Partnering 101: Integration
Most enterprises have proprietary and custom software assets that they simply cannot do without. How can they be integrated with CF if all apps have to comply with the 12-factor principles? In this video, Pivotal’s Cloud Foundry team explain how to work around constraints and use virtually any existing software with CF.
There are many ways you can integrate a piece of software with Cloud Foundry, but how do you decide which way to go? Watch the video to learn about the three levels of integration that exist in Cloud Foundry and when to use each of them.
Forking Cloud Foundry code base may seem like a good way to customize a deployment, but it may be not the best idea. Watch this panel to learn how to add new features and avoid the treadmill of maintaining a fork.
How to Integrate with Cloud Foundry
There are three principal ways for organizations to get involved with the Cloud Foundry ecosystem:
- integration with or on top of the stack
- customization of codebase (during installation, for architectural consulting, for specific customers, etc.)
- operation, i.e. providing services, support, training, etc.
This panel featuring platform engineers from Pivotal mainly focuses on integration of new and existing services into the Cloud Foundry PaaS.
Integrating services with CF
Cloud Foundry is built to be as extensible as possible. Its architecture provides a lot possibilities for the ecosystem to integrate with different components. Naturally, you have to take into account the constraints that exist for apps that run on CF, e.g., the platform only supports one inbound HTTP port and all apps need to comply with the 12-factor principles. Still there are many ways to make existing enterprise assets work with CF.
Mark Kropf explains that there are several levels of integration. User-provided services are the smallest degree. They require most effort to maintain and support. The next step are brokers, which provide services when apps need them. Finally, there are apps and services hosted on Cloud Foundry. What you choose depends on where you are in your journey. If you have a 12-factor compliant app, you can jump right to the end.
As of the question of when it is time to switch from UPIs to service brokers, he says that UPIs need to be wired up to the app every time it is pushed, i.e. they have to be defined in the app manifest or during push time. A service broker can provision services to apps whenever they need them, even if they run in different environments where this service broker is enabled. If a service is used frequently, it becomes too laborious to maintain a UPI. This is the time to start thinking about a service broker.
Generally, the highly flexible service broker API makes it easy to build service brokers of any complexity. A good example is the AppDirect service, which actually serves as an entire mapping layer between the Cloud Foundry API and a range of other services. In addition, you can technically run your PaaS on any infrastructure. The BOSH team are finishing their work on CPI extraction. When that is done, third parties will be able to build CPIs for literally anything, including containers.
CF team to the community
The panel closed with some questions about the Cloud Foundry community and what it should/shouldn’t do. Matt Stine and Mark Kropf listed some common contributor/integrator pitfalls and things that are generally discouraged. These include:
- Forking the Cloud Foundry code base. Cloud Foundry is being developed very rapidly, so maintaining forks is hard. It is also harder for those who use forks to “get back on the train.” There is also a risk that you start working on something the CF development team are planning on doing and by the time it is ready it becomes obsolete. The best solutions here are to communicate with the development team (even if it is just a hint at what you are planning to do), ask them if they can provide an API extension point that you can use, and always consult with the roadmap.
- Failing to communicate with the CF development team. Mark Kropf explains that the amount of code that you want to contribute should be in line with the amount of communication that you do with the team. Pull requests with minute fixes are accepted every week, but if it is something that changes the way CF works, it is better to open an issue, e-mail the team, and talk to the relevant person beforehand. That way there is a much better chance that the code will be pulled in quickly and your work won’t go to waste.
In the end, all the panelists shared what they would like the community and partners to do. Scott Frederick said that it would be great to have more services, while James Bayer noted he would love to see more work done in the area of lifecycle management, source code control, and CI. Mark Kropf mentioned that it would be great to get more feedback and real use cases of how the platform is being used by the community. Finally, Matt Stine said he would be happy if the gaps that exist in the area of running microservices on Cloud Foundry would be filled, however there is a lot of work to do in that space.
In their discussion "Partnering 101: Partnerships, Businesses, and Cloud Foundry," the Pivotal team undoubtedly nailed all the technical details of integration with CF. Still, there are some other questions that might have been asked and answered.
Potential partners and CIOs would like to learn about best practicies of monetizing integration solutions built on top of CF, as well as challenges and lessons learned. Thus, ActiveState, HP, and IBM could have shared their valuable experience in building Stackato, Helion, and Bluemix. It would also be useful to learn what Cloudsoft (the company behind Apache Brooklyn), AppDynamics, or AppDirect have faced while delivering integration solutions.
Finally, it would be great to hear more about how the CF Foundation deals with the existing and new partners, certification programs, etc. Hope, discussions like that are coming soon.
Want details? Watch the video!
Table of contents
|
Related slides
About the presenters
is Head of Business Development and Chief of Staff, Cloud Foundry at Pivotal. At the moment, he focuses on business development and partnerships for the Cloud Foundry PaaS. Before Pivotal, he worked at Joyent, a cloud computing leader, and Six Apart, a company that provides the TypePad social platform, powering Avatar, Paris Hilton, and other brands. He also held positions at Flickr and Sun Microsystems, Inc.is Senior Director of Product Management for both open-source Cloud Foundry and commercial projects at Pivotal. Before he started working on Cloud Foundry in 2011, he specialized in Java EE technologies (at Oracle, VMware, IBM, and BEA Systems). He is recognized for his expertise in cloud computing, enterprise architecture and software, Weblogic, distributed systems, etc. and a willingness to share his knowledge at different events.
is Senior Product Manager, Spring Cloud Services for Pivotal CF. His extensive experience embraces healthcare, biomedical research, e-commerce, and retail store domains. He is also a technical editor of the NFJS magazine and a recognized conference speaker who delivers sessions on project automation, continuous delivery, Lean and Agile software development, modern Web app testing, etc.
is Senior Software Engineer at Pivotal. He can boast over 30 years of experience as software developer and architect and a vast skillset that covers applications, communications, networking, and embedded systems. Scott has held senior technical positions in a number of companies, including Travelocity.com, Sabre Holdings, and VMware.
is Product Manager, Cloud Foundry at Pivotal, responsible for Cloud Foundry Core product. He was previously responsible for incubation of emerging technologies at Diebold. Before that, he worked at Monte Forex and Webworks Interactive S. Mark has three patents to his name.
