Cloud Foundry, a developer’s Paas for rapid development - could Cloud Foundry component orchestration replace “Low Code” development?

Cloud Foundry Summit Basel 2017

I was at the Cloud Foundry summit in Basel at the end of last year and was impressed by the knowledge and attitude of its developers, as well as by its size (99 keynotes, breakouts and lightning talks), its 67 member companies (with seven certified platforms) and 865 registered attendees. I suppose that Cloud Foundry is most obviously a competitor for Red Hat Openshift, but I think that it also competes with the commercial low-code PaaS offerings out there. The commercial opensource version of Cloud Foundry comes from Pivotal Software.

Abby Kearns and Cloud Foundry Announcements

Abby Kearns, Executive Director at the Cloud Foundry Foundation, seemed quite receptive to the idea of an orchestration of Cloud Foundry components, obtained from an active marketplace, as (part of) the future for Cloud Foundry – which implies that the jobs of many of her development-oriented audience will change a great deal over time. She took us through a lot of Cloud Foundry announcements, such as:

• Cloud Foundry is being reorganised. There is now an Application Runtime  (formerly Elastic Runtime), which takes code, written in any language or framework, and runs it on any cloud (Open Service Broker extends this to services);
• and a Container Runtime (formerly Project Kubo), powered by Kubernetes;
• BOSH(the open source tool for release engineering, deployment, life-cycle management, and monitoring of distributed systems) remains, managing the deployment of both runtimes.
• SUSE is now partnered with Cloud Foundry, along with Ubuntu, and Cloud Foundry’s emerging Developer Training and Certification Program is well underway (with nearly 10k developers enrolled).

Cloud Foundry and Low Code

I found myself thinking that a lot of the Cloud Foundry message was similar to the “Low Code” messaging. Is it “low code”? Well, in itself, not exactly, but the platform does do a lot of the heavy lifting for developers, and could support a rich ecosystem marketplace, supplying reusable, pre-written, components.

However, I usually see “low code” in terms of visual coding, with model-driven development from business process models etc., although this is not the only approach (ref LANSA). None of the people I talked to at Cloud Foundry seemed very interested in visual programming, although at least one was aware of BPMN tools in Cloud Foundry, without remembering the name of the company concerned.

Cloud Foundry, Mendix and SAP

All of which is a bit odd, because one of the most popular visual Low Code PaaS offerings is Mendix (which supports extended BPMN modelling) and this makes great play of its implementation on Cloud Foundry. In fact, Mendix has just announced a global reseller agreement with SAP, which means that it is is being sold as “SAP Cloud Platform Rapid Application Development by Mendix”.

SAP Cloud Platform did indeed feature heavily at Cloud Foundry Summit, and SAP was a platinum sponsor. Mendix runs directly on the SAP Cloud Platform and combines all the benefits of rapid, visual low-code development with seamless access to SAP systems.

I think my take-away here is that there are two sorts of developers, those who like visual model-driven development and those who like coding, and never the twain shall meet. That is my general experience talking to developers, in fact, it’s very binary, they “get” visual development, or they don’t.

SAP seems particularly keen on Cloud Foundry for its Cloud offering and on SAP Leonardo for EdgeComputing and IoT. Never fear, the old on-premises monolithic SAP is still there – I wonder whether the Cloud offering will encourage its modernisation? I do see possible cultural conflicts managing both on-premises commercial software and Cloud OSS in the same company but SAP seems confident that it will overcome any that do arise. In the meantime, as mentioned, Mendix is SAP’s low-code environment of choice, and I think that is a very good choice.

Cloud Foundry and Serverless

I noted an interesting discussion about Cloud Foundry and Serverless  from Dr Julz Friedman (Product Manager and Software Engineer at IBM). Basically, instead of using cf. push to send stateless code to (trigger) cf map-route, and supplying state with cf bind-service; you can trigger cf map-event and, again, supply state with cf bind-service. Of course, as usual, one has to remember that “serverless” doesn’t mean that there are no servers underwriting the Cloud Foundry PaaS; it’s just that one needn’t worry about servers (although someone somewhere has to), one just supplies a function to run when a particular event happens. The high-level Cloud Foundry concept seems to fit well with the intent behind Serverless.

GDPR and Security in Devops

GDPR (General Data Protection Regulation) is increasingly being recognised as important and I did manage to find a presentation on GDPR (Privacy by Design and Breach notification) at Cloud Foundry Summit around HashiCorp Vault. Although, as the presenters freely admitted, there’s more to GDPR than just managing secrets, Vault seems to manage secrets quite well with: secure secret storage; dynamic secrets; data encryption (AES cypher); and leasing, renewal and (importantly) revocation. Find out more on GitHub from HashiCorp here; and from Pivotal here. One should be thinking DevSecOps, with security built in from the start, rather than DevOps now…

Summary

The Cloud Foundry Haiku (from Onsi Fakhouri) is “here is my source code; run it on the cloud for me; I do not care how”. And that is how it should be – the platform supplies what you need in order to run, you worry about supplying the business logic. But I suspect that, although this is true, most current Cloud Foundry developers are working at a rather lower level than, say, Mendix developers.

The most exciting Cloud Foundry innovation today, taking the larger picture, and the long view, is probably the Cloud Foundry Ecosystem. Join over 1k people talking about Cloud Foundry in its Mailing Lists; or some 7k people, who’ve sent more than 1.3 million messages, on SLACK. Its “community velocity” seems to be what Abby Kearns is particularly proud of – over 93k committed updates in the last 2 years and nearly 3k contributors to 482 public repositories. However, this ecosystem is just starting – does Puppet (for example) have a bigger ecosystem today, with a more diverse reach? SalesForce certainly does. I have heard suggestions (from OSS rivals) that Pivotal and Cloud Foundry are becoming a bit of a silo, complete unto themselves – but I can’t help feeling that that can only be true if Cloud Foundry users allow it to be.

Nevertheless, I see Cloud Foundry as one of the key future platforms for developing business automation, as more and more people move away from commercial software and vendor-specific platforms, and adopt Cloud and open source.