We talk to developers every day andknow what exceptional specialists they are at designing code to solvetheir customers’ challenges creatively. But when it comes to configuringand planning for that app to be installed ‘on-prem,’ tasks likeinstalling a Kubernetes (K8s) cluster or setting up the app for deliveryof future releases to specific customers on dedicated licenses — thesetasks really become ‘chore work’ for a developer that keeps them fromthe 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 ProductManager Justin Nordeste. Justin’s a true ‘voice of customer’ championand digs in with us about some of their challenges a little bit more.
A: This depends on the vendor andwhere they’re coming from. Is this a vendor modernizing an existingapplication but is hitting challenges with installations into existingcustomers that may not be as mature in their infrastructuremodernization? Or are they a newer organization that built a SaaS-firstsolution but with enterprises who want their own private app instance?
Thereare many different situations based on the vendor’s background, butthere are a lot of common questions they have to answer, too. Forexample, how will they maintain or modernize their development pipelinewhile creating a dedicated version for these customers? How will theydeliver and install the app to customers? How will they supportcustomers using the app? Replicated provides answers in these areas andbeyond.
A: Complexity first comes to mind.Depending on the vendor, whatever mechanisms they have to solve theseproblems may not translate to all multi-prem use cases. There’s also thecost consideration – any product team would know how familiar thissounds.
Customers wanttheir problems solved, including new ones, as their usage of thevendor’s solution grows. Solving these new problems is what drives theirproduct forward in their space, but to do all of this while refactoringexisting mechanisms for established parts of existing or even newerproducts is hard to justify. Does the team focus on building the nextnew marquis feature, or do they invest in refactoring an existinglicensing mechanism for a new multi-prem use case to ‘unlock’ this newgroup of customers?
Whiletaking one of these paths, they may also forego investment into theirdevelopment pipeline. This intricate balancing act is a challenge, andthe decision to ‘build’ or ‘buy’ can be complicated. When a pipeline ofnew customers is available, time can become a critical point forconsideration. That’s where Replicated can help.
A: Absolutely. We’re excited aboutthe improvements to token availability in the vendor portal. Thesetokens have a wide range of uses by our vendors, whether it be for anindividual who is scripting something for their own benefit all the waydown to an app team incorporating Replicated into their developmentpipeline.
Previously, onlytokens at the team level were available, and these provided basictoken-based access for a vendors’ team with basic read-only orread/write access across the team. As our vendors integrated Replicatedmore and more into their processes, there was a clear need for morecontrol and security. To meet these needs, we first introduced usertokens that could be created for a given user and are restricted to theRBAC policy assigned to that user. This helped solve the problem forindividual contributors who may need to be restricted and audited asthey interact with the vendor portal programmatically.
Weadditionally expanded options to include service account tokens. Thesetokens are not tied to a specific user however are scoped to thespecified RBAC policy assigned to them. This helped solve the moresignificant problems teams may face when they have external services andautomation tasks on behalf of the applications development team in asecure way. Replicated helps align tokenswith more mature security practices needed by enterprise softwarevendors by assigning an RBAC policy when defining a new token.
A: I love the fact that our work heresupports vendors to sell their apps faster to multi-prem environmentswhile minimizing impact to their existing CI/CD pipeline.
Inmy previous work as a Sales Engineer, I was constantly reminded of thevariety of requirements from enterprise users: where their data is, whohas access to it, controlling the desired service levels areas. Thesesorts of needs aren’t always trusted to teams outside of the enterprise.Replicated enables vendors to mitigate these worries while maintainingtheir ability to develop, release, and support these enterprises. It’svery exciting!
A: I take a ton of inspiration from our users. What Ithink isn’t the most relevant at first; what matters is knowing whatthe users’ problems are. This focus is really everything. If I can solvethe problem, it must be in a way that not only meets the users’ needsbut at a price point that’s digestible.
Themost elegant ideas come from user adoption and user feedback. We maynot achieve the complete, optimal end state on the first pass with a newfeature, but that spark happens with the people who are using,touching, dealing with it day to day — and it’s this feedback that helpsus 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 Slackchannel with Replicated. If they don’t have a channel with us yet, reachout to whomever you’re working with at Replicated, and we’ll be able tomake 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 demoof how Replicated helps with these initial tasks involved to prepare anapp for delivery. This is an excellent illustration of just how easyit is to take these steps with Replicated and walks through key stepsand capabilities, including:
Watch the entire video below!