Hacker News Reader

Why is it so hard to understand?

a) re FaaS. Of course if you have an on-prem component, someone needs to take care of it. That's why it's on-prem. But still you can separate administration of that from the developers and have the additional new feature that you as admin don't need to care which software runs in these clusters. (In reality it's never that simple since specific hardware for the task outperforms the standard hardware by more than a margin, but at least you have to worry less about getting from cool-product:v1.0 to cool-product:v2.0 as admin anymore.

b) This dream of cross cloud portability needs to die

Well, you are either a cloud provider or a software/hardware provider that is not a cloud provider. If you are the latter of course you need a way to attack the cloud providers when everybody moves to the cloud. It's a common and traditional idea.

And at least for me it also makes sense to use such a solution. I would always go for Openshift (not working for Red Hat) since they are much better at getting on-prem to work than k8s, and you have the almost same setup and interaction experience throughout all your clouds. I hope so much that they can also find a way to more seemlessly work on arm and ppc now that IBM has bought them. Then it's truly hybrid.

PS: That said I also wouldn't trust any of these quickly assembled hybrid cloud solutions from companies who are not well known for their software achievements. It's probably only the marketing aspect that's driving these efforts and IBM has already shown that they don't trust their own solution themselves even.

I'm all for the separation of concerns for managing underlying services! I just suspect most organisations have the scale to warrant running it themselves.

Lets say it takes 5 engineers at 100k each to maintain the K8s and FaaS service internally. Are we getting 500k+ _more_ benefit from that internally managed platform than offloading it to a third party? What is the cost of exit from one platform to another if we just used the native services?

As long as the service management of FaaS continues to sit with your organisation, it feels disingenuous to call it Serverless. We lose out on the per invocation opex costing model, the benefit of scaling offloaded to a third party and the well integrated ecosystem of services which Serverless developer paradigms really shine.

B) Full disclosure, I work for a software consulting company. We are partners with AWS, Google and Azure. I'm relatively agnostic, although my preferences would be somewhere along AWS > GCP > Azure.

"I would always go for Openshift (not working for Red Hat) since they are much better at getting on-prem to work than k8s, and you have the almost same setup and interaction experience throughout all your clouds."

That true if we plan to run _everything inside the OpenShift cluster_; our own database, analytics, logging, iam, secrets managers, etc.

As soon as we get other cloud hosted services involved, the integration becomes really clunky and our teams end up split braining between two orchestration layers which aren't well integrated. An example of this would be Networking and Databases in AWS - You simply can't do microsegmentation inside and outside of the Openshift and cloud networks. Assuming you wanted to offload databases to RDS (and you should), all your security groups are going to have open traffic flow from every node in your Openshift Cluster, whether those nodes are tied to the Databases App partner or not. Welcome back perimeter based traffic rules!

And since the networking and database part of the deployment scripts are tied to a specific cloud, I need to re-write them to move workloads around anyway... So why not just re-write the whole deployment job to use a native service?

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/

"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)

> 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.

> 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.

> What do Pivotal plan to do if both implement breaking changes (extremely likely), maintain a fork?

The main riff team all work for Pivotal and Pivotal was the first external partner brought into Knative by Google. We were the first to submit non-Google PRs and the first to have non-Google approvers.

It would be strange for Pivotal to be blindsided by two projects it is intimately involved in.

Source: as you probably guessed, I work for Pivotal.

Great analysis. I think of it as avoiding the DevOps explosion and it drives me nuts when I see early stage companies sinking lots of time into getting the perfect setup of what is actually just a cost center. There's likely some strained argument for how this ultimately might benefit the customer but that ROI is a long way off, and if you're still in business.

I'm not so sure. If I were a typical small (startup) company, I'd run on top of Kubernetes with a Postgres backend, some business logic layer in a container and serve some html/js to the browser. It's fast, inexpensive and goes wherever Kubernetes does.

Large organizations are a whole other animal. There will be many people entrenched in various ways, each with their own ideas of how things ought to be run. Often guided by technical debt and unique historical needs.

Why not start with Fargate/App Engine, or skipping containers all together and going straight to FaaS on your cloud of choice?

Small companies seem like the primary choice to skip container orchestration layers completely.

Yeah, or Heroku which is super simple and reliable to use.

That's funny, I've set up the infrastructure for 3 startups with exactly that stack over the last year and a half, works wonders and is very flexible.

> Serverless implies that the management of the underlying infrastructure is owned wholy by a third party,

This is an AWS talking point, which they push relentlessly because it suits their purposes. The idea that developers "I don't care about servers" implies or doesn't imply anything about the legal ownership of servers doesn't, by any necessity, actually follow, unless your name is Bezos.

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

I have run them single-handedly in my day job at Pivotal. We have customers who run platforms for thousands of developers with < 10 operators.

> 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?

Or you could use BOSH today and Kubernetes in ~-12 years as its ecosystem firms up. Or both as fits your workloads. Pivotal is ready for both and to help you handle your workloads.

> 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.

Why?

> Just use the native FaaS/Data/Analytics.

I actually half agree with you. Cloud portability is to me not the primary selling pitch of the software Pivotal works on. It's a benefit, one which many of our customers see as essential. But to me the point is: can I just write some damn code? That's what I want to achieve. Solve the damn problem, rather than shaving yaks all the damn day. The portability thing is just a means to that end, not an end in itself.

Disclosure: I work for Pivotal.