
Pivotal launches serverless framework that works across clouds and on-prem - tpurves
https://techcrunch.com/2018/12/07/pivotal-announces-new-serverless-framework/
======
mothsonasloth
Pivotal Cloud Foundry is terrible. I am having a terrible time working with
PAS.

The use case of PCF is weak especially when Kubernetes does everything it can
do. It just sells enterprise fluff to "architects" in suits who haven't
touched code in years and are so far from the reality of Devs working day to
day.

The time it took me to migrate a Java spring boot service from AWS to GCP was
around a day. Getting it to work with Pivotals way of doing things was more
like a week.

We are now starting to do some of our infrastructure on Kubernetes, much less
headache.

If anyone wants more info feel free to ask. My post might seem angry but as a
developer I know better than the execs.

~~~
jambay
i work on pcf at pivotal. i'd love to hear how we can improve. spring boot
should work great with "cf push" and when it doesn't we would love to know why
and make it better. while pks and k8s are able to run stateless workloads, if
pas isn't offering a lot of additional productivity with routing, logging, and
multi-tenancy features then we've missed the mark. pivotal-cf-feedback at
pivotal dot io will reach the product managers that work on different parts. i
saw your note further below about having to login, the "email" prompt instead
of username, you had to ask to get the redis tile, and that you find the cf
cli confusing compared to other platform clis you are familiar with. we
definitely want to know let us know if there are other major issues.

~~~
erikb
I work in a big corp myself. If you worked on cloud foundry you probably
worked with some of my colleagues. ;-) Please don't mention the name though,
so I can speak openly.

I see this in my corp every day. Very smart people, super interested in actual
feedback, and super interested in really providing great software. But in the
end they still fail. I'm not 100% sure about the reasons, but I have a guess.

Usually people who move up the ranks and get into positions where they can
make decisions, tend to build relationships with other such people. So more
and more they change from "why the hack is dns not working on server-13
anymore?" to "this is the big problem the market has, let's attack that". And
slowly that thought croaches in that you should only think about the big
picture problems and not worry about the nitty-gritty details of every day
getting-things-to-run.

And that's probably the problem. While it's clear that you can't solve all the
details and work on big picture problems at the same time, you should not
devaluate the details. Great solutions solve big picture problems BY SOLVING
THE DETAILS.

That's why K8S for instance is a mediocre solution. Sure they have great big
picture ideas, but usually people spend their time with having DNS not
working, having servers hanging, having etcd nodes not talking to each other
without explaining why, having deployments say "SUCCESS" while actually not
running. K8S provides a standardized API for every detail and every use-case,
cool. But in the end you need to be an expert in everything to make it run
around 50% of the time (outside of AWS and GCP). Nobody really wants to
develop on k8s when the underlying platform is only available 50% of the time.
And that's the current experience.

So please, if you are one of these people who is really interested in creating
great software, consider finding solutions to the detailed low-level problems
an important part of the goals and tasks you define. Usually the core low-
level problems are not a big amount. For instance with k8s it usually is
networking, dynamic storage or security related. Have one person in your team
really become an expert in one of these areas (by checking out problems and
solutions that exist, not just by making up ppt slides with plans that have
nothing to do with the real world) and allow them to influence your task
planning.

~~~
gtirloni
_> And that's the current experience._

Maybe that's your experience? I haven't had any of those problems in
moderately sized on-prem k8s clusters.

~~~
yebyen
I think I've had that experience. I wouldn't generalize and say it's "the
current experience," and certainly not 50% of the time, but I can say I have
had this experience at least once on every cloud provider that I've used
Kubernetes with to any degree of depth. Something goes wrong, and it's outside
of your control, you just have to wait for them to fix it (or sometimes I
guess, you can just pick a different AZ and try again.)

It's almost just enough to make you wish for a Hybrid cloud. If you don't have
Kubernetes experts on staff, you shouldn't be trying to manage your own
Kubernetes on-prem. It won't be surprising that this is the experience 50% of
the time – honestly that has to be why managed services for Kubernetes are
evidently becoming so popular.

Managed services have these issues some of the time too, and if your managed
service has those issues often enough that you'd want to talk about them, you
better find a different managed service. I think AKS and GKE have had those
issues, but they are rare. Don't know personally about EKS.

I think some people interpret the promise of managed K8s services to be that
you don't need to have someone anymore on-staff who is the expert in how
things might go sideways on Kubernetes.

On the contrary, you still need that person to be able to take advantage of
Kubernetes with confidence, but maybe now thanks to (whatever vendor you chose
for Kubernetes) you simply don't need to have an actual department of 6-12 of
those experts focused on only doing that (managing Kubernetes.)

A result of using a real, stable managed K8s service should be that on a day-
to-day basis, those people won't actually need to run around with their hair
on fire doing ops things just to keep the business going. Automation.

With on-prem, maybe just don't expect it to come like that out-of-the-box; if
your whole team is still new at this they're going to need training and
planning and ramp-up to get it to that stage. This is exactly how you get "it
might be better for us to start with a managed k8s service."

~~~
gtirloni
I was replying to a specific list of problems:

 _> usually people spend their time with having DNS not working, having
servers hanging, having etcd nodes not talking to each other without
explaining why, having deployments say "SUCCESS" while actually not running_

I'm not saying k8s is free of problems.

~~~
yebyen
Not disagreeing with you, and those are all "noob problems" from my
perspective as I've done all of those things wrong before myself, and I myself
am a noob. But they are some actually very complex problems (and you can even
have them on your managed platforms once in a while, too.)

Self-healing is great when it works, and those items you listed are all real
problems. But they are not problems that you should expect to encounter on a
managed service, at least hopefully not more than once. (YMMV, amiright?)

------
rorychatt
Pivotal haven't launched a serverless framework, they've launched a FaaS(ish)
framework.

Serverless implies that the management of the underlying infrastructure is
owned wholy by a third party, and the only exposure to you is the higher order
abstractions, leaving you to only worry about the business logic.

This is not that.

You still need to water and feed a Pivotal/K8s platform, and those things are
awful to run.

"What’s interesting about Pivotal’s flavor of serverless, besides the fact
that it’s based on open source, is that it has been designed to work both on-
prem and in the cloud in a cloud native fashion, hence the Kubernetes-based
aspect of it. This is unusual to say the least."

This isn't unusual. Every software house seems to be building a dream of
hybrid cloud on-top of Kubernetes. Rightscale, Openwhisk, Cisco Cloud Centre,
IBM Cloud Private, ServiceNow and others build their sales strategy across
cloud mobility.

 _This dream of cross cloud portability needs to die._ You either end up:

Option A

\- Leveraging the cloud native logging, storage, networking, database and
analytics services, leaving behind only the container layer which is portable.
By this stage, you end up having to re-write those parts of the
json/yaml/terraform to handle deployments into other clouds ANYWAY. So what's
the benefit again?

It also encourages you to do stupid things like single account deployments in
AWS since federation for these abstraction layers are still very much a pipe
dream, significantly increasing the blast radius concern.

Option B

\- You run your own logging, storage, networking, database and analytics
services inside the K8s which defeats the entire point of being in the cloud
in the first place.

Being cloud agnostic is a great pipe dream, but the economics of running an
abstraction layer (Pivotal / Openshift / Mesos) vs cost of exit just doesn't
add up for 99% of companies. Just use the native FaaS/Data/Analytics.

~~~
stevenacreman
It's even worse than that.

Knative is really an alpha piece of software at version 0.2.2 for the serving
component. Riff is also at 0.2.0. What do Pivotal plan to do if both implement
breaking changes (extremely likely), maintain a fork?

The other issue is what value is this all really providing? Kubernetes
provides a standard API that abstracts infrastructure and deployments.

The benefit that Lambda brings is very simply connecting together cloud
services. None of these FaaS on Kubernetes products do that. For anyone
interested I looked into the current landscape on Kubernetes and gave up since
it's all pretty worthless.
[https://kubedex.com/serverless/](https://kubedex.com/serverless/)

~~~
andor
_" The other issue is what value is this all really providing? Kubernetes
provides a standard API that abstracts infrastructure and deployments.

The benefit that Lambda brings is very simply connecting together cloud
services."_

Generally, the benefits of a function service are:

\- scale to zero: when a function is not active it won't use any resources and
create costs.

\- higher level of abstraction: if a piece of software fits well into the FaaS
abstraction, it should be more productive to implement and operate it on the
FaaS level over lower levels (PaaS, container, IaaS, etc.) K8s in particular
is quite a complicated system to target by an app, which is why Knative was
started.

If Lambda makes it easy to call other cloud services, I'd say that's a side-
effect of a good FaaS implementation. Bringing this benefit to other function
services should be a matter of using the right libraries.

(I work at Pivotal, but not on Riff or Knative)

~~~
sturadnidge
> If Lambda makes it easy to call other cloud services ... Bringing this
> benefit to other function services should be a matter of using the right
> libraries.

You are correct in that the calling out to other things is just a concern of
the function itself, but the value in the 'connecting' that Lambda does is
from being _invoked_ by other Cloud services by way of integration to their
event systems. e.g. Object storage file creation event X triggers Lambda
function Y to update resource Z (resource Z isn't necessarily a Cloud service,
it could be a database).

This is why I'm skeptical of on-prem FaaS. It's an easy value proposition to
sell when you can use Lambda as an example. But Enterprises have heterogeneous
environments so Lambda-like integration into other services is far from a
given, and 'scaling to zero' is a little disingenuous because there always
needs to be underlying infrastructure (k8s in the case of PFS) running to
handle function invocation.

~~~
jacques_chester
> _But Enterprises have heterogeneous environments so Lambda-like integration
> into other services is far from a given_

Because it's not a walled garden. As the ecosystem grows that pain (and it's
real) will ease.

> _' scaling to zero' is a little disingenuous because there always needs to
> be underlying infrastructure_

The point is to use it more efficiently. Mixed workloads with scale-to-zero
help achieve that end.

------
mchmarny
It’s exciting to see ecosystem build commercial products using Knative
([https://github.com/knative](https://github.com/knative)). The developers on
those platforms benefit from increased portability. Congratulations to the
riff team behind the new Pivotal Function Service offering

------
yodon
From an economic perspective, using a service like Pivotal feels like placing
a bet that the pricing difference between cloud providers will be higher that
the cost of paying for Pivotal's support plan (I know, open source, but if you
reach a scale where these things matter enough that you care about the cost to
switch clouds you are probably at the scale where you find yourself paying for
Redhat and etc support plans).

As cool as "cloud agnostic" sounds, paying any real tax to achieve it probably
exceeds the long term price differential between major cloud providers. The
major clouds sell commodities, recognize that they sell commodities, and they
operate as low margin large scale providers. Over time the pricing differences
have to average out to about zero, otherwise the market would abandon the
always-more-TCO-costly provider (which would cause them to lower their margins
to recapture the higher total earnings).

~~~
richards
Honestly, this rarely seems to come down to cloud pricing considerations.
Rather, the goal for most shops who choose something like PCF is to (a)
simplify onboarding and ongoing work of devs since they don't need to learn
the nuances of each cloud IaaS, (b) stripe a single ops model across each
infrastructure pool, which matters since no enterprise of size is using only
one. People buy because they struggle to ship, and PCF helps these big
companies put their focus back onto shipping software, not where or how it
runs.

Disclosure: I work at Pivotal.

------
fuball63
One of the reasons I prefer function as a service "FaaS" over "serverless" is
because of how useful on demand ephemeral functions can be on premises.

The term serverless implies that the main benefit is not having to deal with
infrastructure. While that is helpful, setting up a "standard" means of event
driven and stateless business logic is useful in its own right.

Can you accomplish that with long running processes? Sure, as long as you are
disciplined enough to do so.

------
mohdmasd
Azure functions is also a serverless framework that works across clouds and
on-prem.

~~~
GordonS
I seem to recall Microsoft actually open sourced it

------
frou_dh
On-prem serverless? Stone cold classic.

------
polskibus
I wonder how does Pivotal new framework compare to OpenWhisk?
[https://openwhisk.apache.org/](https://openwhisk.apache.org/)

~~~
jacques_chester
Project riff most closely compares to OpenWhisk and in fact both riff and
OpenWhisk contributors work together on Knative. Of the two, riff has the
advantage that it came along at the right time to be based directly on Knative
without to be "ported", so to speak.

PFS might be more fairly to commercial plans announced by other vendors to
repackage OpenWhisk.

Disclosure: I work for Pivotal, though not directly on PFS.

------
PaulHoule
My take.

These kind of things face the problem that they pump entropy out of one part
of the system but risk creating more overall. In fact, unless you get _all_
the details right you will end up worse than you started. The "minimal viable
product" is not minimal at all if it is going to be viable.

For instance I was using Vagrant years ago and realized eventually that I
didn't need 80% of what it did and that I hated the DSL. (eg. if it has to
support five different ways to build your image, maybe that's a "bad smell"
that none of them are good enough)

Even though I was using it locally to start, I wound up using it only in AWS
and I also used it to stack up systems that I put in front of the public.

I wrote my own Java program that would set up a virtual server, networking,
all that and write a bash cloud-init script that would run on the machine to
set it up, then send a message via SQS when it was ready. If it passed tests,
the system could then switch over the elastic IP to the new instance.

I looked at the problem of getting it to run on other clouds and it wasn't
that bad but it wasn't that good either. In AWS you have to choose a region,
availability zone, VPC, subnet, disk types, and a number of details.

In some cases those choices could be arbitrary but sometimes you have
infrastructure that you have to hook into and you have to match that.

In GCS or Azure it's basically the same but it is different, and if you want
to support those platforms you have to also embody the differences in the
platforms and also the differences between customer's environment.

\----

Being involved with software vendors, "hybrid cloud" has a special meaning. My
biz dev guy and I picked it up as part of our pitch a few years ago because
_we_ needed it. We knew we needed to support customers wherever they were, but
of all the messages we tried that was the one that confused customers the most
and resonated the least.

"On premise" is a special case BTW, because there are many customers who have
issues with privacy, security, etc. and they don't have a choice or perceive
they have a choice to use public clouds. (eg. Bridgewater thinks that it is
better to safer to desktop virtualize into AWS then risk people walking out
with laptops, physical destruction of their HQ, etc.)

------
exabrial
My issue with Spring is it became what it was supposed to replace. Originally,
we flocked to Spring because IBM WebSphere and WebLogic were slow and bloated.
Now Spring has classes that are 72+ characters long and an inconsistent
programming model.

I really like CDI, which grew from ideas hatched in Spring and Guice.
Microprofile is built on top of it as offers standardized, mutiple competing
implementations, modular, interoperable specs.

------
Proven
It's (the idea to manage on prem K8S from the cloud) a reaction to

1) Hyperscalers doing hybrid cloud

2) VMware's growingly independent approach to K8S (which I believe will
ultimately result in VMware offering "generic" Kubernetes)

3) IBM Redhat becoming more aggressive with their on-prem approach (let's not
forget SoftLayer and Redhat OCP can do hybrid K8S on bare metal, without
VMware)

4) On-prem-focused vendors like NetApp having announced similar service
(NetApp Kubernetes Service, which already works in all hyperscalers and on-
Prem NetApp HCI is next) in recent months.

Pivotal's on-prem problem (compared to IBM Redhat, NetApp) is problem is they
have little on-prem presence, sell no hardware or storage, and need to rely on
DellEMC and VMware (which have been great for Pivotal but that was when
Pivotal played nice and wasn't helping VMware (and Dell) customers escape to
non-VMware based clouds.)

