Ernesto Garbarino
Pivotal Cloud Foundry: The New WebLogic
Why Pivotal Cloud Foundry (PCF) is not the natural answer for cloud native applications.
Those who do not learn history are doomed to repeat it; the saying goes. Many organisations are still paying the price for vendor lock-in and struggling to get out of “enterprise” platforms such as WebLogic, WebSphere and TIBCO, as they desperately try to break down their monoliths and become cloud native.
In the same way that WebLogic lured prospects with the idea of being an implementation of the open J2EE spec, PCF is doing the same—in terms of their PAS offering—but using a more sophisticated marketing machine that attacks prospects from different angles; open source tick boxers are happy that Cloud Foundry itself is not closed source, corporate Visual Basic Java drones learn that their darling framework, Spring, is cloud’s best friend, oh, wait, there’s actually Spring-Cloud! Application platform administrators who are currently managing WebLogic keep their jobs by embracing a new platform in which, honestly, nothing has changed; the landing planes are now JARs rather than WARs and EARs. It is a happy polygamic marriage whose end goal is fast-tracking all impediments that may be in the way of getting those POs flowing.
Despite the above, the most anti-cloud-native pitch—than many companies have bought—is that PCF is a cloud abstraction also when it comes to the public cloud. Yes, orchestrating VMs on-premise is a hassle and there is a raison d’être for the likes of RedHat, Mesopshere (and PCF itself) but many organisations end up also rolling out PCF on top of a public cloud to be “decoupled” from the cloud vendor. In 2018, this is utterly nuts; it violates the definition is what native is. For example, a HTML5 mobile app packaged using the Ionic framework is not a native iOS application; one written in Objective C, or Swift, is. The word “native” implies less layers of abstraction or no abstraction whatsoever; ergo, requiring PCF to run on, say, AWS, so that I have a “cloud native platform” is an oxymoron.
The whole idea about cloud native is that it should be trivial, a foundational set of OS/Network-level properties that both my applications and the environment take for granted in the same way that *nix operating systems abide to POSIX standard. Primitives should be universal and not dependent on programming-language specific bloatware. If building a cloud native application involves SpringBoot, SpringConfig, Eureka, Ribbon, Zuul, Hystrix, Sleuth, Zookeeper and so on, then something has gone terribly wrong. Forget about the propaganda around meeting the 12 factor app criteria. Think about how you get immutability, decoupling, service discovery, self-healing and auto-scaling, with minimal or no abstraction whatsoever.
As of today, Kubernetes is the only specification that allows to write an application (or complete system) that satisfies the aforementioned properties and deploy it directly on the three of the largest public clouds (AWS, Azure, and GCP) as well as a variety of on-premise platforms including PKS in PCF 2.0 with changes only in the cloud connection initialisation and storage volumes. Oddly enough, Pivotal was the last member to join the Cloud Native Computing Foundation (CNCF) when the penny had finally dropped: “if you can’t beat them, join them”.
In conclusion, in your path to cloud native, pay attention to how your strategy removes unnecessary abstraction, and that the primitives are as polyglot as possible in nature. For example, with Kubernetes you can get your config properties using a virtual file system accessible from any programming language and benefit from service discovery at the DNS/IP routing level; no SpringConfig nor Eureka fat necessary. The fact that you need a platform to be cloud native is already a bad sign. Do you need a “platform” to have access to stdin, stdout, and stderr (the *nix standard input, output, and error streams)? of course not. This is how universal cloud native is meant to be. The CNCF is in the right path with Kubernetes but the answer to “are we there yet?” is still “not quite”. We still have many problems to solve. One of the debates today is what to do about layer 7 concerns. Are they the responsibility of the runtime or a so-called service mesh?