3 ms·

Thanks for chiming in, Jacques from Pivotal! I don't know which teams have the most meat behind them, but I know my team (or, the part of my team that deals wi

• jacques_chester 9y ago
  > Large engineering effort, community footprint, and sales are all good indicators, but from a technical perspective, why do you think we should be looking at CF? Broadly it's that a good platform gets everyone out of everyone's way. Cloud Foundry (these days, it's called the Application Runtime or CFAR) has made it possible for small teams of operators to support thousands of developers and applications. Similarly, it means developers can deploy rapidly, get databases and integrations on a self-serve basis, enjoy uniform platform features and so on. There's now a lot more interest in the container as the unit of deployment, which is where kubernetes has become the winning orchestrator. So there's also a Cloud Foundry Container Runtime (CFCR), which is based on kubernetes, designed to use the same low-level operator tooling, BOSH, and to integrate smoothly with the Application Runtime. Both the Application Runtime and Container Runtime are intended to run on any major IaaS; BOSH provides a uniform layer that abstracts away the raw interfaces. So you can deploy to AWS, GCP, Azure, OpenStack, vSphere, RackHD and there are others I forget. Last week we had our flagship conference, Spring One Platform, which had a parade of customers talking about how much faster they move. Months per deployment turning into deployments per day. Thousands of developers running tens of thousands of apps. I am aware of customers handling billions of requests per day and handling hundreds of millions of business events using CF. Going through black friday effortlessly without having to massively overprovision. tl;dr we build installable superpowers.
  • yebyen 9y ago
    > developers can deploy rapidly, get databases and integrations on a self-serve basis, enjoy uniform platform features That's what I'm looking for, personally. It's a real headache that in our environment, we usually have exactly one each: dev, test, prod. Sometimes you need a couple more dev environments for a few days, but it's totally not worth it to go through a RFC or REQ process to get it. Instead, you tend to get developers merging features before they're ready, just to be able to get them in front of customers at the same time. > tl;dr we build installable superpowers. I was assuming this, but it's good to hear it out loud ;) Honestly don't know what my teams will go with, but we're starting a trial of ECS for the organization's first formal foray into containers. Convox looks to me like it might actually make using ECS palatable. I was frankly not at all optimistic about ECS until I found it. The scope of the pilot is written to deliberately exclude K8S, which I'm not sure I agree with, but there are also a lot of people saying they believe we will fail on our first attempt to implement containers as an organization, and I'm not sure there is any choice we can make (K8S or otherwise) that would surely make those people wrong (to make the first attempt succeed.) Solely due to institutional inertia, and also difficulty integrating with people who are slow to adopt new things. It's tough working in a group where everyone must insist on moving together. As a developer, I've been using containers seriously in various shapes and sizes since probably well before 2013; here it's still considered new (and scary.) So I almost prefer that we fail hard, at least once, so that we're not stuck carrying legacy garbage along with us forever. Failed launches may leave orbital debris to burn up on reentry. But a successful launch could remain in orbit with its components, for better or worse, basically forever...
    • jacques_chester 9y ago
      The biggest risk is going to be the temptation to roll your own PaaS on top of ECS. Later on it might be to roll your own on top of Kubernetes. It just doesn't seem like a lot of work. Assemble this logging system, that proxy ... before long you have a working PaaS and a source of pride and joy. And a future millstone around your neck. A lot of people who work at Pivotal have worked at other places that tried to DIY. Usually this was a long-running bonfire of cash, during which any potential competitive advantage was lost. No matter how technically capable your team is, there is just a hell of a lot of engineering to be done to build systems of this depth and breadth, especially when they are distributed systems. Software generally is a sharp illustration of comparative advantage. Even if you can do everything better than anyone else, it does not make sense to do everything. Focus on the area where you can add the most value. It is almost certainly not in rolling your own cloud application platform.