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