Cloud diagram with connected devices

Splunk Cloud vs. On-Premise Deployment

So, you’ve heard about Splunk Cloud and it’s intriguing… Here’s what you need to know before making the ascension…

It’s now common for software companies to provide a cloud-based solution, and Splunk is no different. Splunk Cloud is an alternative to Splunk’s on-premise software solution.  While Splunk Cloud offers some relief from purchasing and administering the infrastructure that Splunk sits on, it doesn’t alleviate all of a customer’s platform administrative duties. This article looks at where Splunk Cloud helps customers and other factors that any organizations evaluating the on-prem versus Cloud decision need to take into consideration.

Background –  How Splunk Works

To understand what part of Splunk platform administration does (and doesn’t) get alleviated with Splunk Cloud, it’s important to remember the three major components to Splunk’s technology stack:

Forwarder – Components that collect your machine data

Indexer – Storage area for your machine data

Search Head – Provides end-user searching, reporting, alerting, dashboards, and visualizations

What Splunk Cloud Alleviates

Splunk Cloud shifts the administrative burden of two of these three components, managing Splunk (a) search head(s) and (b) indexers to Splunk’s secure cloud.  This alleviates:

  • Cost and overhead tied to administering and regularly refreshing (procuring) the technology infrastructure that Splunk sits on (servers, software, storage, and security).
  • Tool/platform administration; this means you no longer need to perform Splunk upgrades, OS upgrades, or firewall changes for anything related to a Splunk search head or indexer.

Splunk Cloud also minimizes the risk that many organizations face:

  • The responsibility of Splunk (search head/indexer) administration being in the hands of one or two individuals who, if they were to leave, would create a significant void. This void is not easily nor immediately remediated, given the niche nature of Splunk, the expertise required to administer the platform, and the ramp time for newly-assigned FTEs to master Splunk.
  • Splunk administration being in the hands of an internal resource (employee) who may not have the necessary subject matter expertise with Splunk. An improper configuration of Splunk will result in difficulty around scalability as new users are being added, or new components of the Splunk stack are added over time. This can result in poor system performance including slow queries or time out, or data not being ingested into Splunk and log data being missing, among other performance issues. (Note that neither of these things should occur when Splunk is properly architected, whether on-prem or in the hands of Splunk Cloud operations.)

Which administrative duties are not alleviated by Splunk Cloud?

Data collection infrastructure is still the responsibility of the client.  Even when migrating to Splunk Cloud, the data collection (forwarder) portion of the Splunk stack must be maintained and administered by the client.  This means that the client is responsible for:

  • Splunk Universal Forwarder (UF) on client endpoints (normally Linux and Windows servers)
  • Deployment server to manage Splunk UF instances
  • Syslog servers that collect data from infrastructure systems (firewalls, IDS, UPS, or any other syslog generating device)
  • Splunk heavy forwarders which can collect information from various databases or third-party systems
  • Splunk HTTP event collector to obtain data from custom applications (Java, .net, JavaScript, or other web apps)
  • Splunk Stream to capture wire data and output raw or statistical information about the data.

This component of the Splunk stack – let’s collectively call it the Forwarder component – can’t be managed by the Splunk Cloud operations team because the source systems for the log data reside in the client organization’s environment.

The knowledge required to maintain the forwarder infrastructure can be significant especially when things don’t go as planned.

What is Splunk “Administration” Anyway?

Aside from dividing the responsibility of managing Splunk’s technology components, there are (2) broad roles within Splunk, when looked at a high level:

  • “Back end” Splunk Administration
  • “Front end” Splunk Administration

What we refer to as “back end” Splunk administration includes the deployment and maintenance of the various Splunk instances, or components, previously mentioned herein: forwarders, search head(s), and indexers.

What we refer to as “front end” Splunk administration includes the building of reports, dashboards, queries, and alerts within Splunk. Some companies refer to this as content creation.

In some corporations, these front-end Splunk duties are carried out by Splunk end-users: the security analysts, sys admins, developers, business analytics team members, etc. that use Splunk on a day-to-day basis. In those environments, these duties do not fall on the shoulders of the Splunk Admin.

However, in other organizations, those end users open tickets with requests for reports, queries, and alerts that are the responsibility of the organization’s Splunk Admin, who has developed the required Splunk expertise that these end-users rely on.  This structure varies from organization to organization and is to some degree dependent upon how well-versed the end-user community is with Splunk.

Why This Matters

This matters, because Splunk’s Cloud operations team is not in the business of performing content creation. Your organization will still need to develop the capabilities to build queries in Splunk for the purposes of creating reports, dashboards, and alerts. This is especially critical because it’s not the setup and maintenance of Splunk that is the key value driver for any organization. The real driver of attaining up to 90% reduction in incident investigation time or troubleshooting time that Splunk is capable of is the front-end content creation. The role of Splunk Cloud operations is the administration of the platform itself, including Splunk software (indexers and search heads), the servers that Splunk sits on, storage, security, etc. – but not content creation.

Other Considerations

There are other aspects of Splunk that Splunk Cloud doesn’t address, including the adoption of Splunk within the organization.  Splunk adoption is accelerated when the business engages a team of Splunk experts who understand what the business wants to achieve and can show the business how to achieve those goals faster and better with Splunk.  Understanding business drivers enables the quick creation of new ways to search for data, visualize data, enrich data, assist with the selection and onboarding of key data sources, alert and troubleshoot missing log sources, and interactively train users.


Moving to Splunk Cloud does alleviate the burden of managing core Splunk (search head/indexer) but it is exceptionally beneficial to partner with a team of trained Splunk experts who can troubleshoot log collection (forwarder) infrastructure to ensure scalability and reliability, to help assist with content creation that is the real value driver within Splunk, and to help drive adoption forward to ensure the value of an incredibly powerful tool. Only then can Splunk’s value be fully realized.

About SP6

SP6 is a Splunk consulting firm focused on Splunk professional services including Splunk deployment, ongoing Splunk administration, and Splunk development. SP6 has a separate division that also offers Splunk recruitment and the placement of Splunk professionals into direct-hire (FTE) roles for those companies that may require assistance with acquiring their own full-time staff, given the challenge that currently exists in the market today.