Chuck D’Antonio: Today I'm going to talk about Publishing to the Cloud Marketplaces with Replicated.
The cloud marketplaces are provided by all of the major clouds, as well as some of the more niche oriented clouds. I'm going to talk about what they are, why you might want to distribute your applications with them, and then I'm going to take you through an example that I built using AWS.
Let's get started on what the marketplaces are all about:
I like the metaphor of thinking about the app store, but for the cloud. The metaphor still holds because you have a situation where your customer wants to use your package, you let them know you're available in the cloud marketplace and they can grab that and get started.
Let's take a quick look at that. I'm going to look in an AWS account. I'm going to look for the SlackerNews application. I've got this instance of this application, it's got a page that says information about it and lets your customer go through and start the process of subscribing.
This has a tag that says it's Bring Your Own License (BYOL), and it's named Bring Your Own License (BYOL). This was my first pass at taking the SlackerNews application and making it available this way. SlackerNews being our sample application for Replicated.
The Bring Your Own License (BYOL), was a great first pass at getting this done. It doesn't necessarily provide all the advantages of using a marketplace listing and using the marketplace to distribute. I went past that one into a more in depth solution that we're going to look at today.
Why Sell Through a Marketplace?
The main reason is you want to make it easier for customers to buy and install your application. Replicated has already made it easy for you to distribute and facilitate your customer's installation once the infrastructure is there, but the cloud marketplaces help you at that step before then, when the infrastructure is not there. The main reason that I see for the marketplaces is not a technical reason at all though, it's the financial circumstances around it.
1.Available Budget:
Your customer generally will have a budget available, in their cloud provider. Any purchase they make through the marketplace is going to count against the committed spend they've made to their cloud provider. And most of your customers are going to have commitments to at least one cloud provider, if not more, certainly their main one.
They're going to have some commits upfront. Your product becomes part of that committed spend up to about a rate of around 50%. In other words, instead of having discussions in a field about, ‘how do we get this customer?’, the budget's there, the budget's already committed, they're going to be spending it either way. It's a great avenue for that and also handles the billing and details.
2.Common Installation Patterns:
The other advantage is some common installation patterns. Generally your customer is going to be familiar with the marketplace options for their cloud provider. They're going to be able to take advantage of these and easily go through starting the installation and bringing it into their environment.
It's going to initiate the installation. They're going to be able to see their subscriptions in a list, in their console. They're going to know what's going on, the installation patterns, the understanding of what's going there.
3.Co-Sell with Cloud Providers:
Then, the cloud teams are actually incentivized to support you. Not only do you have your team going out there, selling and marketing your application when you're selling through a marketplace, but your partners from the cloud providers – even if you don't have a formal partnership with them, they're more than willing to help you out because it fits into how they get incentivized, in addition to how your sales team is incentivized.
There are a lot of advantages to this process; takes some of the roadblocks out, gets you some help, and makes things a little easier for your customer. It makes sense for that customer to buy: It's already there, they know how to install, they know how to get going.
How do we get there?
The first thing you do is what type of product do you want to produce? In general, all the cloud providers are gonna have different types of products. I'm more familiar with the AWS ones. They're going to have server based, container based and data or SAS products. You may even be distributing your SAS that way and want to bring that to your customer managed version.
I would recommend that we do a server product using the Embedded Cluster, and that's the example we're going to look at today.
Make sure you automate the maintenance of all of your artifacts. You need machine images in the server model, you want to create the Replicated license, and have templates and files that are necessary and supported. Some elements are running in your cloud, some elements are running in your customer's cloud.
Make sure you have automated maintenance of everything running in your cloud, to easily modify those and get them up and running. Start simple and iterate.
For example I started to see challenges with – Bring Your Own License (BYOL): 1. It doesn't hit that financial incentive without doing some other elements. 2. Instance wasn't ready to go once it spun up, it was difficult to know when it was ready. There were challenges, but I got that going. Then I made an improvement, and that initial version was a server product, an AMI product, and now we have an AMI with cloud formation.
Other recommendations: Build among the Embedded Cluster. Include all of your cloud dependencies in the machine image that you use. I've built the packer files for one that you can take.
Include any dependencies you have in that image to simplify the spin up. Take advantage of our new customer external ID. When we see the demo, these are going to be coming from AWS accounts. You want to track that on the Replicated side, which account it came from, and follow the best practice patterns for the cloud that you've chosen.
As you go through best practices, pick the ones that make sense for you.
That's for a couple of reasons. 1. It's going to take advantage of what's expected; those patterns that the customer is used to. 2. It's going to help you with the approval process because all of these marketplaces are going to have an approval process.
Providing Your Product on AWS
This is my example – there are similar techniques on Azure,Google, IBM, Oracle, et cetera… We're dealing with four different entities that are color coded:
- The Marketplace - Orange
- The Replicated Vendor Portal - Red
- What’s Running in Your AWS Account - Green
- What’s Running in Your Customer's AWS Account - Blue
We're going to initiate, (as if the consumer deployed), a CloudFormation deployment of your application. In this case it's SlackerNews’ application. We're going to run that, It's going to create some resources on the customer side. One of those is what Amazon calls a custom resource. That custom resource is driven off messaging topic. That message goes through, and calls a Lambda that you maintain - that's why we're using messaging - to maintain and protect the access to your vendor portal account. That creates the license at Replicated. It responds with information from that customer record and the license, namely the download URL for the Embedded Cluster, and the token to do that download, the license ID.
Then CloudFormation is going to spin up a VPC. It spins up a node running your application on top of our Embedded Cluster, using that license. This is in the demonstration.
I have two consoles, one around the AMI and one around the CloudFormation template. The AMI that I'm using is simple, it does not have any real Replicated related bits in it.
It's going to install packages that it needs in order to do the installation. I do some hardening of SSH and then it's going to install some dependencies. One, letting CloudFormation know that the installation is done. and then the AWS API, Python library, KOTs, because we're going to change the Embedded Cluster password. Then we do some cleanup to make sure we stay on the good side of those AWS reviewers and don't allow brute SSH.
Then we also use user data inside that CloudFormation template to spin up the individual instance. That CloudFormation template is going to have some parameters. They’re going to pick their instance type, the disk size, subscription, etc. We select the AMI based on the region that they're running in, and then we start creating those resources.
We have the license, which is triggering a Lambda based on a topic that's going to create the Replicated customer and the license behind it. We create the admin console password.
I use the AWS secret manager. They give you a great way to generate a secret and your customer is going to know how to find those secrets. We're going to spin that up and we do access related things, spin up the VPC and the network, and then show some outputs that are going to be useful.
Let's look at the node itself. The node is going to spin up in that VPC, in that subnet. It's going to have access through its instance profile to that secret, then run its user data. That’s going to download the Embedded Cluster install, using the information from creating the license.
It's going to run the install with that license, get the password from Secrets Manager, change the admin console password, and tell CloudFormation that it's done. That's important because this will take a while. We're spinning up the Kubernetes cluster now. We are substantially faster in spinning up the Embedded Cluster than other types of clusters, but it's still a little bit of time. You want to be able to signal to CloudFormation when that's ready.
I'm now going to run a make here. That's going to take and create the Lambda, the topic to get the message. It's going to make sure all the permissions are right for those, and it's going to drop that template into an S3 bucket.
It's going to output the template that I'm going to use. That's the template that you would use to create your marketplace product. While you're doing development you would continually run through this in CloudFormation to make sure it was working. I recommend you do that in a separate account after you've got it fairly stable. You want to do some testing from another account because it's going to be running in the customer account. Make sure all those permissions are right.
I'm running in a different account from the one I ran it in. We're going to specify all these parameters, which would be done as part of the marketplace normally.
I'm going to scroll through the steps. This is standard, getting started from CloudFormation, again this will all automatically go through once the customer is doing it – I'm going to hit submit. This is going to be going through and spinning for a bit.
I'm going to refresh this a few times, you can see it's created the admin console password already. It's in the middle of creating the license and all the network pieces. The resources start to show up here as they get created. You can see Create License is starting to show me an ID of it.
It's complete. It looks a lot like a Replicated customer ID, as it is. I can go over (pic below) to get the admin console password. I'm going to need that when my instance is ready, Retrieve that secret value in plain text, a nice random password, generated by Amazon for us.
My node creation has started again, that's going to take a few minutes. That's because we're waiting for that instance to be fully ready with the Embedded Cluster running.
If I start looking at my resources it's going to show me that the node is actually there, but it has to run through those steps to install and start the Embedded Cluster, before it's going to report back to CloudFormation that it's ready. That's really critical because you don't want your customer to think it's done because the node has started up, when the cluster and your application aren't ready yet.
We short circuited this diagram and instead of creating this subscription, we provided a template directly to CloudFormation.
We aren't able to wrap up this demo in the time we have left, but overall we'd love to provide you a more productized, comfortable experience than building and maintaining all those pieces.
First of all, we want to support the major cloud marketplaces and the different delivery methods they have. Then how do we do more integration across all of our different components around this, and our product team is looking for who might be a good design partner for that. If you have some interest, you can reach out to Replicated either through your account executive or come to me directly. If you're in a shared Slack with us, jump on Slack, pop it up, and one of us will jump in and answer.
You can reach out to me – I am @crdant or Chuck@replicated.com