Modern On-prem vs Traditional On-prem

Modern On-prem vs Traditional On-prem

Modern On-prem software vendors will find a growing market of sophisticated customers that value both security and reliability and are willing to pay for software that satisfies their requirements. In order to succeed with Modern On-prem delivery, all software vendors will need to focus on a holistic approach to offering a Modern On-prem version that will involve all functional organizations (Product, Engineering, Sales, Customer Success, Professional Services, Support, Marketing, and Recruiting). This guide will largely focus on the strategic, engineering, and product decisions that vendors will need to make in order to be successful with Modern On-prem.

Implications for Traditional On-prem Vendors

Traditional software vendors are accustomed to delivering a single component (rpm, Java app) and requiring their customers to supply and manage the runtime, databases, app server, dependencies, etc. Moving to distributing a Modern On-prem version of their application will enable vendors to leverage the reliability benefits of Kubernetes to improve their customers’ experiences with managing the application.

  1. Traditional software vendors have seen their on-prem product be commoditized by SaaS companies offering less complex versions of the product in the cloud. Many of these SaaS companies are in the best position from a cloud-native architecture perspective as well.
  2. Applications are hard to install and maintain. Competitors will be providing versions that are easy to maintain and scale.
  3. The advantages of standardizing on a cloud-native architecture for on-prem deployments allows for faster application development, the utilization of specialized functional components, and a single set of skills required to support the application wherever it runs (should one also want to introduce a SaaS version).
  4. Shipping a distributed system as a Kubernetes application creates a different support effort than distributing something like a monolithic jar file (requiring the customer to supply the runtime, database, automation etc).

Join the Community

If you’re interested in this topic (agree or disagree), we’d love to have you join the community.