Splunk: to Cloud or Not to Cloud?
If you’re getting ready to deploy Splunk, you might find yourself evaluating whether it makes the most sense to deploy in the cloud or on premise. There’s no right way—it just depends on how your organization typically handles the provisioning of IT resources and what’s easiest and most comfortable.
The good news is, Splunk works equally well in the cloud as it does on premise. To help you make your decision, we put together an objective list of deployment pros and cons, examining time, budget, and people resources. Read on to find out what resonates most with the culture of your organization.
Deployment Pros and Cons
Time
On Premise:
The amount of time you’re going to have to invest in your initial Splunk implementation on premise can vary between organizations depending on how provisioning works. In some cases, it’s as simple as requesting a new VM and gaining access to one within minutes. Other times, it takes days. One possible downside of deploying Splunk on premise is the potential for a significant time sink in the event that you’re sitting around waiting for machines to be available so that you can do actual work.
Cloud:
Deploying in the cloud is typically a pretty quick and painless process, with an exception being if your environment is constrained and you’re running out of IP space in a particular region within your cloud—if you need additional subnets, there might be a time constraint. This isn’t usually the case, though.
*A quick deployment tip:
Regardless of whether you go with on premise or cloud, the actual deployment process can be very similar. If you’re working with a larger enterprise deployment, one thing we always recommend is incorporating some sort of automated provisioning mechanism. A number of excellent configuration management platforms are out there, like Chef, Puppet, Ansible, Salt, and others. You should also spend some time upfront actually configuring the automation so that when it comes to deploying the instances, it becomes a much simpler and quicker task. Think of it as an investment rather than an unneeded use of time, especially for larger deployments. In fact, even for something as small as three to five index clusters, it’s still worth spending some time doing automation upfront. The more manual tasks people are responsible for, the greater potential for mistakes.
Budget
On Premise:
Again, costs of an on-premise deployment can vary depending on the organization. If a given company has a VMware infrastructure available on premise, it enables the ability to lease out computing resources on an as-needed basis and install Splunk instances on virtual instances as if they were actual hardware. If your organization has already made a capital investment in VMware software, accommodating a Splunk installation will likely only require some additional licensing and/or capacity. This results in a much lesser incremented cost.
Other costs aren’t as easy to quantify. Waiting to obtain VMs required for a Splunk installation qualifies as a cost. Also, if we’re being totally honest, sometimes the team that handles VMware infrastructure may butt heads with the Splunk installation team in terms of the kinds of resources required and how they’re supposed to be provisioned. The Splunk best practice for installation requires that resources provided by VMware infrastructure need to be dedicated resources, which means that if you ask for a virtual machine that has 8 CPU cores, for example, you need those to be dedicated to that virtual machine at all times, regardless of what the VM admin prefers in terms of how often those cores are used or not used. VMware is traditionally used for providing resources on an as needed basis, but Splunk needs to be treated more like an enterprise database software installation that requires dedicated resources at all times.
Cloud:
When it comes to cloud resources, companies usually buy from cloud providers in chunks. You start with a budget and access to x amount of services, compute instances, network load balancers, firewalls, etc., and there’s usually less of a problem obtaining the necessary permissions to recreate the cloud instances on an as-needed basis. It’s pretty simple to get those resources dedicated to the Splunk environment, also as required. Overall, there’s less contention in terms of getting the necessary basic resources on which to install Splunk software in a cloud environment.
*A quick deployment tip:
There are certain things about the cloud and the providers you’re working with that you must be aware of. It’s actually a great idea to have a cloud architect and/or a cloud security engineer, at minimum, involved in the architecture to make sure that you’re not unwittingly opening up ports or IP addresses to the public at large, and that Splunk remains within the confines of the private enclaves you set up within the cloud. You can and should be very surgical about what you open to the virtual private cloud to allow ingress or egress of data from the cloud itself across the internet to another provider.
People Resources
On Premise:
In terms of people resources, physical machines on premise require a lot of people who have to accept the equipment in the data center, rack it, stack it, configure it, power it up, handle cabling, and so on.
In contrast, with virtual machines like VMware infrastructure, it’s not as bad because you can just spin it up, and there are less people required for that; one or two at most. At best, you don’t need any admins at all if you have virtual the infrastructure process laid out so well that it just requires an automated request.
Cloud:
Cloud resources don’t require licensing—they’re allocated according to time. When it comes to machine resources in the cloud, you can choose the type and size of machine(s) you need based on Splunk-recommended requirements and pay the associated time-based rate. You can start small and gradually increase with relative ease, and it can be very flexible in terms of adjusting to the budget you have available.
In addition, you don’t need anyone else’s permission to provision resources. You simply choose the size, machine, and resources and deploy it. And you’re done. In terms of people resources, there isn’t much of a cost, except that the person who is doing this needs to understand how that cloud infrastructure works so they know how to select resources within the infrastructure and deploy it.
Lastly, scaling instances is easier in the cloud. You can do massive scaling within a day that could take a week or two on premise.
Need Help Deciding Where to Deploy Splunk?
If you’re not sure which deployment model will work best for you or you have additional questions about Splunk, you’re in the right place. We’ve got a full team of Splunk engineers available to discuss your current environment and identify what will work best with budget, time, and people resources in mind!
Ready to talk Splunk? Speak to a Splunk engineer today, or call us at (301)-838-9470.