Greetings folks!
Nice to see a few of you contributing to various JumpClodu threads. Let me give you a bit of background on 'why Servers' with JumpCloud...
Roll back time: It's where we began. The original instantiation of JumpCloud was to provide a central authentication and management console across Linux/Windows servers in any cloud service (e.g. AWS, Google Cloud, Rackspace, Softlayer and so on). The main thrust of what we were doing/offering (and still offer) fairly progressively, was to provide REST services to stimulate the efficiency of large-scale server infra - and mainly very ephemeral infra. The use cases varied but generally speaking, DevOps guys would bake our image into an AMI or similar image, and when they would light these up, they would perform initialization routines against the JC Directory....drop users accounts on, enable POSIX Groups, deploy sysadmins SSH keys, etc etc. It became a 'thing' and basically obviated the need for LDAP servers and wrangling with PAM. Yes, there are super elegant methods for this now....but mainly codified. e.g., Chef, Puppet, Salt, etc. These are actually used in concert with us but there is overlap.
FWIW, feel free to geek on this KB and go play with our APIs and SDKs on Github:
https://support.jumpcloud.com/customer/portal/articles/2429680
This use case is still extremely important for our customer base. We see a typical pattern of companies evaluating us, driven by DevOps where they get to get 100's or in the case of quite a few customers of our larger customers, 1-2K virtual servers. They find success and this bleeds to general IT *(e.g. those servicing rank and file employees and their personal systems, networks and apps).
So that's effectively the story, absolutely feel free to ping us to go deeper in the server management side of things!
Greg