For most companies getting ready to tackle on-prem, it’s difficult to understand what a successful distribution architecture will look like. Maybe they haven’t done it before, or maybe their current architecture gets the job done but feels fragile and is constantly breaking. At Replicated, our tooling transforms both scenarios into a great experience for an ISV and their customers.
At RepliCon Q2, our quarterly virtual conference, Director of Solutions Engineering Chuck D’Antonio walked through where most companies start on the Software Distribution Life Cycle and explored how Replicated can enhance and mature their software distribution architecture in each step.
Below is an edited transcript from Chuck’s talk:
I'm going to talk about tying the whole Life Cycle together with the Replicated platform. Instead of looking at one feature or capability, we're going to look at different capabilities across the platform.
We're going to imagine that we are SlackerNews, a company and product that we use to demonstrate a lot of what the Replicated platform can do. It’s similar to Hacker News, but for your internal Slack team.
As a business, SlackerNews might get started by adopting a Software Distribution Life Cycle and mapping their architecture to each step before they’ve started using Replicated.
In this case, there wouldn't be any code related to distribution.
There is likely to be basic testing. They're going to have GitHub actions that spin up KIND clusters. They're testing against what they use for a SaaS, like an EKS or an AKS, but a fairly basic, limited amount of testing. I find that testing, especially end to end testing, doesn't always happen right away when a company like SlackerNews gets going.
The release tools are what they're familiar with from open source. This is either what they've installed or open source projects they've participated in.
We're probably going to have Docker Hub, one of the cloud provider registries, or GitHub registry for images and maybe GitHub pages for distributing Helm charts. That's a really easy way to distribute static content.
It's not likely they're considering licensing right away. Trust is likely their licensing model.
There may be private images in the registry and an intern is setting up credentials and forgetting to delete them when business relationships or trials end.
There are potentially some real costs there - access to private repos on Docker Hub, for example, can cost you quite a bit.
They do installations of Helm charts. Likely, they’re using their Helm chart repository on GitHub pages to grab the charts.
They probably don't have much reporting. They may not be able to tell who's pulling the image, but they can get the image pull counts.
Supporting the first few customers, they may start formulating some issue templates that say ‘tell me xyz’ and people do an okay job of telling you that information. There's a lot of back and forth at the beginning as you sort out what's going on. It can be challenging to get people supported.
___________________________________________________________________________
You can see above that there’s quite a lot to be desired with SlackerNew’s current software distribution capabilities.
Some big reasons for them to adopt the Replicated platform are to:
Ultimately, they want to give their customers a better experience and give their team a better experience in shipping and distributing commercial software.
Let's look at how this might evolve and what the Life Cycle might look like when a company like SlackerNews is using Replicated as their Commercial Software Distribution Platform.
They're getting feedback from the Replicated platform that can help them with development in terms of who's using what, what versions they are on, and if they are adopting new features.
That's going to help their product teams, when they get down into the code level. The Replicated SDK provides that usage data, and they can write code around licensing or identify their customer instances.
The Replicated SDK can help them develop this capability around this Life Cycle, customer usage, and more to tell them how well their product is doing.
They can test using the Replicated Compatibility Matrix to test the customer-representative environments.
As customers start to adopt, they're able to understand the environments their customers are running in and they can run tests against what their customers are using and doing. They can define our supportability matrix around that.
When they release code, they can have CI and CD. They can go to internal users, beta users, and general availability users.
They have a private registry for distributing their Helm charts, and they start to have more control over the chart than they might have with a traditional repository. They can have credentials on that; authorize who can get which chart. They have a proxy registry that allows them to manage, with that same set of credentials, access to all of their images. They don't have the cost of working with Docker Hub or the complexity of setting up multiple different places to be permissioned to access.
The above ties into their licensing. They have artifacts that are limited only to their licensed users. Those credentials map to the license terms that they have in place - whether that's certain features being enabled and therefore those images are accessible or not, or their license expires and you can't install a Helm chart again until you're renewed.
Pre-flight checks become a great way to avoid installation issues, hopefully helping people self heal before they get an issue.They make sure they're installing into supported environments and they also have ways to avoid all the challenges you might have with installation by using the embedded Kubernetes installer.
Shipping as an appliance brings the Kubernetes cluster along with their application.
They report on the above information. As opposed to their last model pre-Replicated, they have standard user metadata, they can have custom usage metrics. They can have different people using different features: installing, licenses expiring, licenses are renewing.
When they look at SlackerNews, their licensing model might be based on users, based on what they do, how many users they have right now, and so on.
They can get notifications as well. It starts to give them a really rich set of information around how we're working with our customers and what's happening there.
With Replicated, they have a support bundle that's going to encapsulate all of what someone might need, for instance: logs, descriptions, locations and so on.
There’s tooling that allows them to treat that like a Kubernetes cluster. They can escalate to someone who's used to seeing it running live and then run the same commands they would normally run. They have instance insights into ‘What is this instance running? When did they upgrade it? Where is it running?’
This will help them resolve time to resolution and potentially lead to self resolution because the support bundle can be good about saying things like, ‘This is SlackerNews. You can't connect to Slack, check your network.’
They then have escalation paths into Replicated, where they can help you out with different types of issues.
____________________________________________________________________________
With Replicated, SlackerNew’s distribution architecture is much more robust. By using Replicated’s capabilities to properly address each stage of the Software Distribution Life Cycle, the experience of distributing the SlackerNews application is much more pleasant for both their internal engineering teams and end customers.
Watch Chuck’s whole presentation to dig in deeper on how Replicated can transform a company’s Software Distribution Life Cycle.
Want to learn more about what Replicated does to help vendors distribute software to self-hosted environments? We would love to show you – click here to schedule a demo.