We talk to developers every day and know what exceptional specialists they are at designing code to solve their customers’ challenges creatively. But when it comes to configuring and planning for that app to be installed ‘on-prem,’ tasks like installing a Kubernetes (K8s) cluster or setting up the app for delivery of future releases to specific customers on dedicated licenses — these tasks really become ‘chore work’ for a developer that keeps them from the core dev work that they do best.
Now, if you’re in the ‘TL;DR’ (too long, didn’t read) camp, here is the crux of it before you dive into the demo:
For those of you ready for the ‘double-click’, read on for the interview we did with Replicated Product Manager Justin Nordeste. Justin’s a true ‘voice of customer’ champion and digs in with us about some of their challenges a little bit more.
A: This depends on the vendor and where they’re coming from. Is this a vendor modernizing an existing application but is hitting challenges with installations into existing customers that may not be as mature in their infrastructure modernization? Or are they a newer organization that built a SaaS-first solution but with enterprises who want their own private app instance?
There are many different situations based on the vendor’s background, but there are a lot of common questions they have to answer, too. For example, how will they maintain or modernize their development pipeline while creating a dedicated version for these customers? How will they deliver and install the app to customers? How will they support customers using the app? Replicated provides answers in these areas and beyond.
A: Complexity first comes to mind. Depending on the vendor, whatever mechanisms they have to solve these problems may not translate to all multi-prem use cases. There’s also the cost consideration – any product team would know how familiar this sounds.
Customers want their problems solved, including new ones, as their usage of the vendor’s solution grows. Solving these new problems is what drives their product forward in their space, but to do all of this while refactoring existing mechanisms for established parts of existing or even newer products is hard to justify. Does the team focus on building the next new marquis feature, or do they invest in refactoring an existing licensing mechanism for a new multi-prem use case to ‘unlock’ this new group of customers?
While taking one of these paths, they may also forego investment into their development pipeline. This intricate balancing act is a challenge, and the decision to ‘build’ or ‘buy’ can be complicated. When a pipeline of new customers is available, time can become a critical point for consideration. That’s where Replicated can help.
A: Absolutely. We’re excited about the improvements to token availability in the vendor portal. These tokens have a wide range of uses by our vendors, whether it be for an individual who is scripting something for their own benefit all the way down to an app team incorporating Replicated into their development pipeline.
Previously, only tokens at the team level were available, and these provided basic token-based access for a vendors’ team with basic read-only or read/write access across the team. As our vendors integrated Replicated more and more into their processes, there was a clear need for more control and security. To meet these needs, we first introduced user tokens that could be created for a given user and are restricted to the RBAC policy assigned to that user. This helped solve the problem for individual contributors who may need to be restricted and audited as they interact with the vendor portal programmatically.
We additionally expanded options to include service account tokens. These tokens are not tied to a specific user however are scoped to the specified RBAC policy assigned to them. This helped solve the more significant problems teams may face when they have external services and automation tasks on behalf of the applications development team in a secure way. Replicated helps align tokens with more mature security practices needed by enterprise software vendors by assigning an RBAC policy when defining a new token.
A: I love the fact that our work here supports vendors to sell their apps faster to multi-prem environments while minimizing impact to their existing CI/CD pipeline.
In my previous work as a Sales Engineer, I was constantly reminded of the variety of requirements from enterprise users: where their data is, who has access to it, controlling the desired service levels areas. These sorts of needs aren’t always trusted to teams outside of the enterprise. Replicated enables vendors to mitigate these worries while maintaining their ability to develop, release, and support these enterprises. It’s very exciting!
A: I take a ton of inspiration from our users. What I think isn’t the most relevant at first; what matters is knowing what the users’ problems are. This focus is really everything. If I can solve the problem, it must be in a way that not only meets the users’ needs but at a price point that’s digestible.
The most elegant ideas come from user adoption and user feedback. We may not achieve the complete, optimal end state on the first pass with a new feature, but that spark happens with the people who are using, touching, dealing with it day to day — and it’s this feedback that helps us get to that target state. I love hearing from customers on Slack, over Zoom, and old school on the phone.
A: Ping our team, @pm, on their Slack channel with Replicated. If they don’t have a channel with us yet, reach out to whomever you’re working with at Replicated, and we’ll be able to make sure that the feedback is heard.
To double-click on the ‘Day 0’ work that Justin’s talking about, check out his 18-min video demo of how Replicated helps with these initial tasks involved to prepare an app for delivery. This is an excellent illustration of just how easy it is to take these steps with Replicated and walks through key steps and capabilities, including:
Watch the entire video below!