4 ms·

But did kubernetes really won the orchestration war or is it still an ongoing thing?

aynyc 5y ago
It won. Right now it's a speeding train. To compete with it, you better come up with something that's mind blowing, or a culturally shift in development.
- debarshri 5y ago
  I am not sure. almost 80% of the customer we talk to have troubles with kubernetes. They might be too small to operate it or something.
  - aynyc 5y ago
    K8s aren't easy, but if you have enough workloads that you can't keep track of on a single spreadsheet, you probably could use K8s. I haven't seen really true alternative to manage large enough and variable enough workloads successfully. One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases, apps, etc.. K8s might be too much.
    - magicalhippo 5y ago
      > One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases That's our situation soon. We're about to start migrating away from a desktop win32 application. Any good deployment options for such a scenario? We're talking 4-500 customers with their own db, less than 10k users. On-premise installation must be possible (though "give us a VM" is what we currently do, so that might not be to different).
      - jiggawatts 5y ago
        Depends a lot on what the new application architecture looks like, but one option is this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/overview https://docs.microsoft.com/en-us/azure/azure-resource-manage... You could use the same templates to deploy both the vendor-hosted and customer-hosted version of the app. The physical architecture can be anything. A single container, the PaaS App Service, VMs, etc...
      - aynyc 5y ago
        The other poster made some very reasonable suggestion. The answer is largely depend on your app architecture. For example, if it's as simple as an web-app + db, then docker compose image should be sufficient. Do your best to extract some of the more generic features such as email list, storage, log server out of your app and have a shared service for those if possible. Honestly, managing on-prem VM is actually one of the easiest thing to do in my experience if the entire architecture is in a single bundle. For the rest of your customers, you can still run K8s. If you aren't concern about scaling, then run webapp + db in a single pod. This is somewhat of an anti-pattern because it changes your ability to scale. If you do want to scale for an individual customer, then move db into its own pod, and then connect to it from your webapp. Personally, I would rather run your ephemeral load such as webapp in K8s, then run databases on VMs to make it a bit easier to manage.
        magicalhippo 5y ago
        > For example, if it's as simple as an web-app + db Yes, this is most likely the architecture we'll go for, maybe with a few microservices. I had suspected all we needed was docker compose, so good to know I'm on the right track. Thank you all for the feedback, very much appreciated.
  - preommr 5y ago
    two types of software: those that people complain about and those that nobody uses
mountainriver 5y ago
It has for the most part, nomad is it’s only real competitor now

It won. Right now it's a speeding train. To compete with it, you better come up with something that's mind blowing, or a culturally shift in development.

debarshri 5y ago
I am not sure. almost 80% of the customer we talk to have troubles with kubernetes. They might be too small to operate it or something.
- aynyc 5y ago
  K8s aren't easy, but if you have enough workloads that you can't keep track of on a single spreadsheet, you probably could use K8s. I haven't seen really true alternative to manage large enough and variable enough workloads successfully. One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases, apps, etc.. K8s might be too much.
  - magicalhippo 5y ago
    > One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases That's our situation soon. We're about to start migrating away from a desktop win32 application. Any good deployment options for such a scenario? We're talking 4-500 customers with their own db, less than 10k users. On-premise installation must be possible (though "give us a VM" is what we currently do, so that might not be to different).
    - jiggawatts 5y ago
      Depends a lot on what the new application architecture looks like, but one option is this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/overview https://docs.microsoft.com/en-us/azure/azure-resource-manage... You could use the same templates to deploy both the vendor-hosted and customer-hosted version of the app. The physical architecture can be anything. A single container, the PaaS App Service, VMs, etc...
    - aynyc 5y ago
      The other poster made some very reasonable suggestion. The answer is largely depend on your app architecture. For example, if it's as simple as an web-app + db, then docker compose image should be sufficient. Do your best to extract some of the more generic features such as email list, storage, log server out of your app and have a shared service for those if possible. Honestly, managing on-prem VM is actually one of the easiest thing to do in my experience if the entire architecture is in a single bundle. For the rest of your customers, you can still run K8s. If you aren't concern about scaling, then run webapp + db in a single pod. This is somewhat of an anti-pattern because it changes your ability to scale. If you do want to scale for an individual customer, then move db into its own pod, and then connect to it from your webapp. Personally, I would rather run your ephemeral load such as webapp in K8s, then run databases on VMs to make it a bit easier to manage.
      - magicalhippo 5y ago
        > For example, if it's as simple as an web-app + db Yes, this is most likely the architecture we'll go for, maybe with a few microservices. I had suspected all we needed was docker compose, so good to know I'm on the right track. Thank you all for the feedback, very much appreciated.
- preommr 5y ago
  two types of software: those that people complain about and those that nobody uses

mountainriver 5y ago

It has for the most part, nomad is it’s only real competitor now