The on-premises software market is four times larger than the SaaS market, but harder to reach. Every software vendor who wants to pursue it has to decide how they are going to package and deliver applications inside customers’ firewalls, automating away the complexity of keeping applications deployed and running. Should they build or buy a deployment tool (and how should they think about the features they’ll need beyond just deployment)? Both have their pros and cons, but as demand to reach the larger enterprise market grows, more software vendors are choosing to buy.

Deploying apps on-premises used to be very different. Fifteen years ago, sysadmins and database administrators (DBAs) would manually configure servers and the applications that ran on them. When something broke in production, admins would often troubleshoot and fix by SSHing in to tweak a config file or setting. But now, particularly within agile development organizations, everything is done via automation (i.e., the evolution of DevOps and SRE). As a result, customers have lost patience with 150-page installation manuals and bespoke, hand-written scripts.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

Today, any ISV looking to modernize an existing on-premises app (or SaaS-only company considering creating their first on-premises offering) is, most likely, going to default to using Kubernetes because it abstracts away the technical overhead of keeping production-grade applications operating.

With that in mind, software vendors should consider seven areas when deciding whether to build or buy a delivery and management solution. These include:

Maintenance

There are free or low cost resources if a software vendor wants to go it alone. Kubernetes and cloud-native technologies let capable engineers stand up a solution in months. But software vendors often overlook the long-term cost of keeping the tool up and running. There is a lot of tooling “around Kubernetes” the vendor has to build to successfully operationalize this. Sure, if you’re going to deploy to up to five customers, you don’t need formal tooling and processes that make it easy to engage whole teams of people (favoring a small build and manual effort), but when you want to go from five to 50, or 50 to 500 customers, you need advanced tooling (favoring buy).

Cost

Purchasing a ready-made solution comes with up-front costs, but building and maintaining a bespoke solution can be much more expensive. The obvious costs of building a deployment tool are design, engineering, support and operational costs. There are larger, long-term costs to consider, most notably pulling away one of your greatest assets, software engineers, to spend months (or years) on ongoing support needs. Redeploying your engineers results in opportunity and productivity costs, such as neglecting your core application(s) and stalling your business growth.

Internal Resources

You also need to evaluate your internal resources. Building a bespoke deployment tool is a commitment because the tool becomes a product in and of itself. Do you have a team with the available time and the technical skills? If your team isn’t large enough, you may incur costs for expanded headcount or contractors. If you don’t have added FTE costs, you may have a skills gap. When developing a custom deployment tool, most teams focus on the features that enable software distribution and installation, but they don’t consider management and troubleshooting features. In these situations, the FTE and skillset costs may be higher than paying for a comprehensive solution.

Business Continuity

Most homegrown solutions are created by an engineer or two who become experts in the systems they’re developing. This makes tons of sense for core business logic, apps that are constantly going to be improved and onto which new members will be onboarded. However, for ancillary systems that support the core business, these applications end up becoming a silo of knowledge. The question isn’t, “How much time will this take me to maintain after I build it?” but rather, “Who will maintain this after me, and who after them?” followed by, “How will they learn the intricacies of this system?” If the answer(s) to this question isn’t clear, this approach should be reconsidered.

Beyond The First Team

If you expect that your team will be the first, or one of the first, teams within your company to face the problem you are solving for (but you are certain others are sure to follow), then this decision is even more complex. A common customer delivery and management platform can increase cross-sell by simplifying the marginal effort for your customers to deploy a second, third, fourth, etc. application from your company. Buying will likely require a long-term relationship with a vendor dedicated to solving the problem. Similarly, building a solution will require extra investments. Beyond the initial technical/product requirements of abstracting a home grown solution to meet the needs of additional teams/architectures/products, there are also the other implications. The winning solution will win because it will evolve to meet the needs of multiple teams and have strong internal advocacy. Depending on the size and complexity of the company, this internal advocacy can be quite time consuming and require more than just engineering talents (generally, this is what customer success and account managers do 100% of the time).

Target Environments

Your application may need to be deployed in varied on-premises environments and may not have the time to adequately address all of them. If your team has not previously built an installer, they may not have the skillset to build out richer features in AWS, Azure, VMware and others, to solidify the customer experience and day 2 operations, beyond just bringing the application up. An AWS Cloud Formation template might get you out the door, but when the next customer says, “I need GCP,” you’d have to start over.

It’s rinse-and-repeat for each of the target environments, which slows your time-to-market, potentially losing high-value sales. Conversely, if you look at ready-made solutions, you can select the best out-of-the-box experience for your customers.

Control and Compatibility

There are situations where your team must build the on-premises deployment tool themselves. For example, when the app requires so much last-mile configuration for each customer deployment that there just isn’t a way to standardize it. Or if you don’t have enough customers to justify paying for a commercial product, it might make more sense to do a quick sprint and hack something out.

An off-the-shelf solution can significantly accelerate your time to market, but you have to order off the menu. Also, if you have access to your customer’s infrastructure, then building your own tool may make more sense. On the other hand, requirements such as faster time-to-market, an off-the-shelf comprehensive solution and lower costs over time may outweigh customization. If speed, lower costs and quality are important, a solution from a focused vendor who has thought through all of the technical and operational challenges, with no surprises or last-minute fixes, is the way to go.

Competitive Advantage

Your software engineering team may be your company’s greatest resource. But it’s far better to keep your engineers focused on innovation, adding value to your application and winning more customers through improved software. Coding a deployment tool is undifferentiated overhead. It does not make your business more successful. Installers and support tooling are table stakes to deliver a good customer experience, but the reality is that no customer is going to pay you more money for that capability.

The Bottom Line

Simplified access to the on-premises software market is one of the greatest opportunities for software vendors today. Kubernetes and cloud-native technologies make it easier to develop tools to package, deploy, manage and troubleshoot apps. But the job isn’t for everyone. The costs, both up-front and long-term, favor ready-made commercial applications for most software vendors. Consider your resources and customer needs to decide if it makes more sense to build or buy your solution.