3 ms·

We're just not going to agree on this. I hear you saying "I can roll my own for less", and in my head I'm seeing all the snowflake PaaSes I've seen in the past

We're just not going to agree on this. I hear you saying "I can roll my own for less", and in my head I'm seeing all the snowflake PaaSes I've seen in the past few years while working for Labs. It looks good now. Then you move on and someone else is stranded with a completely custom environment that only does the things you thought of at first. Cloud Foundry isn't complex for a developer. That's the point. Deployment involves typing `cf push` and waiting a minute or two. But the essential complexity of managing very large herds of heterogenous applications and services doesn't vanish simply because you aren't using them right now. It's always latent. We and other companies working on Cloud Foundry have already fixed problems you have never thought of.

vidarh 11y ago
Who said anything about rolling my own? I do nothing of the sort. Most setups don't need one. Most needs a tiny selection of functionality that are easily served by selecting from an array of well tested, well understood, components that needs little enough glue that a single person can get the grasp of it a day or two. We know this, because we've gone through the exercise of bringing in people from the outside to walk through more than one system to validate the setups for various customers. I understand your concern about maintainability, and that's exactly where I come at it from. I had developers on my teams in the past that would swear at me (one tried to have me fired) because I made technology choices they found boring and un-sexy because I actually paid attention to our long term costs, such as hiring replacements and ease of even finding replacements. I care deeply about that. And what I'm consistently seeing is that this definitively does not speak in favour of pulling in large, complicated systems like OpenStack or CloudFoundry unless you're working on very large, complicated systems that actually needs all the functionality they offer and where you can justify a team to learn how it hangs together. Typically my requirement from the outset is that a mid level devops guy should be able to take over with minimal training for the simple reason that I have much more lucrative work to do than ongoing maintenance, so I'm 100% dependent on setting up systems that can be quickly and effectively managed by someone much cheaper than myself and that is part of the appeal. As for not being complex "for a developer". I disagree. Automating a build pipeline is trivial compared to getting the application architecture right, and that is the area where dev teams often fall down, and I see all to often that they fall down because they don't realise what it is they've been signed up for and assume everything will be taken care off by magical ops fairies because they have way too little visibility into what is actually happening when they deploy something. > But the essential complexity of managing very large herds of heterogenous applications and services Most companies never end up managing "large herds of heterogenous applications and services". And this may be the fundamental disconnect. If you are dealing with "large herds", then by all means pick a comprehensive platform, as presumably you have the resources to manage it properly too. But the type of businesses who do are relatively speaking few and far between. I'm sure you see lots of them because of what you do, and I'm not saying there aren't good use cases for Cloud Foundry and similar for certain types of businesses. What I am saying is that most companies don't ever even get to the size where they can afford that complexity, much less to the size here they need it.

vidarh 11y ago

Who said anything about rolling my own? I do nothing of the sort. Most setups don't need one. Most needs a tiny selection of functionality that are easily served by selecting from an array of well tested, well understood, components that needs little enough glue that a single person can get the grasp of it a day or two. We know this, because we've gone through the exercise of bringing in people from the outside to walk through more than one system to validate the setups for various customers. I understand your concern about maintainability, and that's exactly where I come at it from. I had developers on my teams in the past that would swear at me (one tried to have me fired) because I made technology choices they found boring and un-sexy because I actually paid attention to our long term costs, such as hiring replacements and ease of even finding replacements. I care deeply about that. And what I'm consistently seeing is that this definitively does not speak in favour of pulling in large, complicated systems like OpenStack or CloudFoundry unless you're working on very large, complicated systems that actually needs all the functionality they offer and where you can justify a team to learn how it hangs together. Typically my requirement from the outset is that a mid level devops guy should be able to take over with minimal training for the simple reason that I have much more lucrative work to do than ongoing maintenance, so I'm 100% dependent on setting up systems that can be quickly and effectively managed by someone much cheaper than myself and that is part of the appeal. As for not being complex "for a developer". I disagree. Automating a build pipeline is trivial compared to getting the application architecture right, and that is the area where dev teams often fall down, and I see all to often that they fall down because they don't realise what it is they've been signed up for and assume everything will be taken care off by magical ops fairies because they have way too little visibility into what is actually happening when they deploy something. > But the essential complexity of managing very large herds of heterogenous applications and services Most companies never end up managing "large herds of heterogenous applications and services". And this may be the fundamental disconnect. If you are dealing with "large herds", then by all means pick a comprehensive platform, as presumably you have the resources to manage it properly too. But the type of businesses who do are relatively speaking few and far between. I'm sure you see lots of them because of what you do, and I'm not saying there aren't good use cases for Cloud Foundry and similar for certain types of businesses. What I am saying is that most companies don't ever even get to the size where they can afford that complexity, much less to the size here they need it.