Two Reasons Independent Software Providers Can’t Afford to Ignore Cloud Native
KubeCon + CloudNativeCon sponsored this post, in anticipation of KubeCon + CloudNativeCon NA, Nov. 18-21 in San Diego.
Unless you have been living in splendid isolation for the past couple of years, it should be clear that organizations large, medium and small are embracing the cloud as an IT strategy. In fact, many are using cloud computing to drive their digital transformation with microservices, serverless computing, infrastructure as code, streaming, AI/ML, digital assistants, et al.
While this may sound obvious and full of buzzword bingo, it reflects a fundamental change in how organizations are aspiring to deliver business value: adopting a cloud native strategy for new, in-house development projects. This approach of short development cycles, iterative functional delivery and automated CI/CD tooling is allowing them to deliver innovation for users and customers quicker than ever before.
This move to cloud native is seated in the fact that, at heart, all companies are software companies. Those that can use software to their advantage, to speed, automate their business and make it easier for their customers to interact with them, win. This is the nature of business today and the reason that start-ups can disrupt whole existing industries. Cloud native technologies like Kubernetes, containers, microservices and functions, among others, provide the basis to scale, secure and enable these new solutions.
The reality, however, is that many organizations have a complex stack of existing applications and infrastructure including custom and ISV applications that are anything but cloud native. These new cloud native solutions need to be able to interact with these legacy systems but are running in the cloud rather an on-premises and need delivery cycles of days rather than months.
Organizations are on a relentless journey to the cloud and independent software vendors (ISVs) need to be part of their customers’ journeys primarily to survive but also to prosper. So, what strategies can ISVs adopt?
Open Up and Remain Relevant
One journey to cloud and digital transformation that organizations are taking is to develop new services and applications that are deployed using containers. They are also adopting modern, agile development techniques and tooling to deliver business value quicker. Many organizations are getting close to four-week cycles with an aim to get to three. In the fast-paced world of start-ups and disruptors, this may appear glacial, it does, in fact, represent huge changes for established organizations with existing stacks and development processes. Very often, these new services need to access either data or functionality from existing systems of record. For example, policy management systems the insurance sector are typically supplied by ISVs and reside on-premise running under some sort of enterprise application server.
The key for ISVs to remain relevant in this scenario is to make it easy to access the data and functionality from their applications. Providing API access to their application is the most effective way for ISVs to do this and remain relevant.
This does not mean a complete redevelopment with microservices to deliver new functionality every couple of weeks. The fact is that a system of record such as a policy management system should not be changing with high frequency. Separating the user interface from business logic and a defined set of APIs is enough to provide the required access. With modern cloud infrastructure proving secure, high throughput access between on-premises and the cloud, these systems may not have to move from the data center.
Containerize and Orchestrate for Scale
Providing API access is a great first step to remain relevant in customer cloud transformation, it does not address the need to be able to scale. Many enterprise ISV applications are deployed using an application server such as Tomcat. Installation of a new environment in a customer data center can take days or weeks and upgrades/patches can take hours. Although this is very manual, time-consuming and expensive, when an ISV counts its customers in tens, it becomes a real barrier if you want to scale to hundreds of customers.
Let’s look at an example, an ISV with a customer base of 50 has committed to investors to grow the customer base to 200 and eight release cycles a year. If a manual upgrade takes two hours and every customer has at least two instances, then the time needed to deliver this in a year is two hours x two instances x 200 customers x eight releases a year equals 6,400 hours or nearly nine months. Not sustainable.
However, there are open source tools to run these systems in the cloud and make use of modern tooling and delivery techniques. Many of these application servers are available as Docker containers and there are Kubernetes operators available to orchestrate and manage these containers.
Integrating with version control like GitHub, secure Docker repositories and using CI/CD tooling to deploy to Kubernetes can automate upgrades and patching to minutes rather than hours. Removing the manual element enables upgrades to run in parallel across multiple customers. This really transforms an ISV to be agile. It also means existing skills continue to be relevant.
Conclusion
More and more organizations are adopting a cloud native approach for new development projects. They are also struggling with the technical debt of enterprise ISV applications when trying to modernize. However, there are strategies and technologies that ISVs can adopt to help their customers transform, innovate and importantly remain customers. If they restrict their customers transition to the cloud, they will find themselves being replaced by something lighter and more flexible.
To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, Nov. 18-21 in San Diego.
Feature image by from Pixabay.
