This is JMP in the Cloud configuring and running JMP

for non- persistent application virtualization services.

I'm Daniel Valente,

the Manager of Product Management at JMP,

and I'm joined by Dieter Pisot,

our Cloud and Deployment E ngineer, also on the Product M anagement T eam.

And today, we're going to talk about how an organization

called Red Triangle Industries,

who's been a JMP user for the last several years,

and their JMP growth has been growing

in their R & D departments, their quality departments, I T,

how they're considering adopting

to new, remote, and flexible work environments,

and hopefully solving some problems with some new technology

for virtualizing JMP in a non- persistent way.

So we're going to play the role of two members of this organization,

and we're going to go through the configuration,

the deployment, and ultimately the use of JMP in this way.

So this is how Red Triangle has been growing.

We started in 2015 with a core set of users,

and every year, we've been growing the JMP footprint at Red Triangle

to solve problems, to visualize data,

to communicate results up and down the organization.

Most recently, we've added JMP Pro for our Data S cience T eam

to look at some of our larger problems.

We've got an IoT initiative,

and we're doing some data mining, machine learning on those bigger data sets

from our sensors and things that are going on

in our manufacturing plant.

And in the last year, we also added JMP Live to our product portfolio.

You can see a screenshot of JMP Live in the back.

And what we're trying to do is automate the presentation of our JMP discoveries

and also our regular reporting in one central database

so that everyone in the organization has access to those data to make decisions

for things like manufacturing quality, for our revenue,

and for other key business metrics that we're sharing

all in one single place with JMP Live.

So how is JMP being used at Red Triangle?

Well, one thing that we did in the past year,

our IT organization of which Dieter and I belong to,

is we've surveyed all of our users,

and we've put together an interactive visualization

looking at which parts of JMP that they use by department.

This is called the workflow assessment.

It's something that we can send out, we get some information,

and it gives us some opportunities to look f or growth opportunities,

training opportunities.

And also, this is how we found out that some of our users

want to have JMP presented to them in different ways.

So this is why we're considering the application virtualization.

We've adopted a Bring Your Own Device policy,

which lets our employees purchase their own laptop,

and we want to be able to give them JMP in there.

So this has put together a set of situations, some pains,

some implications, and some needs that we're considering using JMP

in a presentation virtualization,

in an application virtualization standpoint.

All right, so the situation for us after this workflow assessment.

We're profitable.

We're a growing business in the manufacturing space.

We're adding more JMP users every year in different departments.

As I mentioned, we have our core JMP use growing year on year.

We've also added JMP Pro for our Data Science Team,

and in the past year, JMP L ive

for enterprise reporting and sharing of JMP discoveries.

So I'm playing the role here of the CTO, Rhys Jordan,

and I'm joined by Dieter,

who's playing the role of Tomas Tanner, our Director of IT.

And we've been charged with ways

of getting JMP more efficiently to remote employees.

We want to be able to analyze bigger problems

and also want to support employees that want to take advantage

of our BYOD policy or Bring Your Own Device policy

in 2022 and beyond.

So historically, our standard laptop deployments

have used between eight and 16 gigs of RAM.

And in some cases,

especially with our larger manufacturing problems

and sensors being put on many of our manufacturing equipment,

we've got data sets that we want to analyze

that are just bigger than that standard deployment can be.

We also want to be able to support our employees

and their flexible work environment,

which means if they purchase their own personal laptop,

we want to be able to get JMP to them and other software installed on these

without physically being on site with the employees.

We want to look into delivering that software in alternative means.

Also, when new versions of JMP come out, and other desktop software,

we want to be able to seamlessly apply those updates to our entire workforce

and do that in a way that minimizes the latency between the release

and when our employees actually get that update.

And finally, when and if our employee leaves Red T riangle

or moves to another organization or another part of the organization

that doesn't require use of JMP or another software,

we want to be able to retain those corporate assets

with minimal operational burden.

So the implications for this is we've been given a mandate,

like many other organizations, to reduce our corporate technology spend,

and we feel like the biggest potential for reducing that technology spend

is through automation.

So looking at these non- persistent application virtualization tools

should speed up this entire workflow

of getting software to our end users efficiently.

We want to lower the total cost of resource and computer ownership.

This is why we've adopted the BYOD policy.

But we need to also right size the assets

to the needs of the users, even these virtual assets.

So our power users that are analyzing our biggest data sets

will need more RAM, more speed available to them,

and the casual users will be able to just right size that to their needs.

With employees on three different time zones,

doing something like just having a fleet of virtual machines

for everybody at the same time doesn't make a whole lot of sense.

Because we want to work the global clock, we can design a fleet of virtual assets

that's going to look at just the total number of concurrent users

that are accessing the asset at once.

And that's what we'll get to in the demo here.

And finally, that better roll out of software updates

and the transparency of usage to our E xecutive T eam,

who's using the software, how much are they using it, et cetera,

are implications for us investigating this technology.

And as far as needs, we want to go with a cloud provider.

We're not going to build this tool in- house,

so we want to use one of the cloud providers

and the out- of- the- box capabilities

that they have for application virtualization.

Since we've moved a lot of our data sources

to the cloud, to Amazon Web Services, for example,

we'd like to be able to put our analysis or analytic tools

close to those data sources to minimize the costs of moving data around.

Our IT Department wants to centralize

the management of JMP setup and license information,

and also have that seamless version control.

So as soon as a new version is released,

we want to be able to push those updates as efficiently as possible

and then look at usage tracking

through things like cloud metrics and access controls.

So with this, I'm going to hand it over to Dieter to give a demo

of running JMP in an application virtualization,

a non- persistent application virtualization tool

like Amazon App Stream.

Dieter.

Thanks, Dan.

So the first thing we have to do is we have to go to the image builder

and launch that.

So we have to pick a Windows operating system.

So Windows Server 19 is what we want to pick here.

So there are several available.

We just pick a generic basic one like this one, move on,

and give it a meaningful name and display name.

Because we're Red Triangle, we use Red Triangle for this one.

We have to pick a size for the image that we want to configure.

So we pick a standard one, medium.

I'm going to add an IAM role

because I want to connect to S 3 where I keep all my installers.

So just to make sure I can connect there, I add a role with access to S 3.

Then I have to define in which private network

I want to run my image builder here.

Pick the public subnet so that I can actually connect to it

from my local desktop.

Security group,

just to make sure only I can do that and not everybody else can connect.

We're not worrying about the Active Directory set up,

but we want to make sure we have Internet access

so we can download things from the Internet,

like, for example, a browser.

We check all the details, they're fine, so we launch our image builder.

This is going to take a while.

AWS App Stream basically set up a virtual machine for us

that we can connect to and set up our application.

So after that has started,

we connect to the machine as an administrator.

And to save some time, I downloaded the JMP Pro installer already

and did install JMP Pro

just like you would on any other Windows desktop machine,

and we have the application icon here.

In addition to that, I have created a JSL script

in the Program Data, SAS, JMP directory, jmpStartA dmin that has a few settings

so that we make it easier for our users to do certain things.

What they contain is a connection to a database

and the JMP Live connection to our Red Triangle JMP Live site.

So the users don't have to remember and type that in.

So that's perfectly fine here.

Then we have to go to the image assistant

and configure our image.

The first thing, we add an application to our image,

that's going to be the JMP P ro that we just installed.

So we are going to pick the executable.

We use the JMP executable.

We give it just some properties, give it a more meaningful display name.

Save that.

And what we can do now,

here's our application that we want to make available to the user.

The next thing we can do is test and set it up

as the user would see it.

So we are going to switch users here.

We have the ability to switch to a template or test users.

So the template user,

that's defining how the user would actually run the application.

So whatever we do here is going to be remembered,

and the user will have the same experience as our template user.

So we can do a few things in the set up.

We can here also make sure that our database connection is working.

We could do this as the test user as well,

but I'll just do it here as our template user.

So here we are,

application is perfectly connected to our database.

And with that, we're fine with our set up.

And so we go back to the image assistant.

Not going to use the test user, switch users again.

I'm not going to show the test user.

I'm going to go back to the administrator and continue with the set up of our image.

So I switch here.

Same, not going to the test user.

Now, what we have to do is we have to optimize,

we have to configure the application.

So we 're going to launch JMP.

Once it's running and we're happy with all of this,

we continue the setup of the image by clicking the Continue button.

And what AWS App Stream is doing now

is optimizing the application for the user.

So we just wait for that to finish,

and then give our image a name and a display name as well.

Again, we're using Red Triangle here.

We also want to make sure we use the latest agent

so that we always have an up- to- date image.

Next, review,

and we disconnect and create the image now.

So with that, we are going to get disconnected from the image builder.

Lost the connection, obviously.

Our session expired.

We return to the App Stream 2.0 console,

and we see that our image has been created.

It's pending right now.

This also takes time to create it the way we want it to be.

We have to wait for that to finish.

We're done.

It has finished.

And the next step is to create the fleet the images are going to run on.

So we create the fleet, we pick which type of fleet.

We 're going to go in on- demand fleet because that's much cheaper for us.

The images only run when the user actually requests the image

versus the always- on would be running constantly.

So here, we give it a name and a description.

We then pick the type of image we want to give to our users.

Bunch of other settings are available to us

like timeout settings and capacity.

For now, we're just going to go with the default.

We can adjust to the needs of our users if necessary at any time.

Click Next.

We pick the image that we just created to run on our fleet.

We define the subnet, the virtual network,

and the subnet that our fleet should run in.

Just pick the same we used before,

and also a security group, of course,

to make sure that only the users and hosts that we want can access our fleet.

Again, we want to give the fleet Internet access,

so we're going to check that

to make sure users can publish to our JMP Live site.

We could integrate active directories authentication here,

but we don't want to do that.

That would take us some time.

So we're just going to go with some local users

that I have already created.

So we click Next.

We are sending a review of what we did and it's all f ine.

So we are creating the fleet.

Some pricing information we have to acknowledge.

And with that, the fleet is starting up.

Once that has happened, we can move on and create the stack.

The stack helps us run that fleet

and helps us define persistent storage for our fleet, for example.

So here, we create this stack.

As well, give it a meaningful name.

Since this is a Red Triangle sit e,

we go with a very similar naming convention here.

And we pick the fleet that we want to run in our stack.

All looks good.

We move on.

Here, we define the storage.

We're going to go with the default,

which is an S 3 bucket that's available to each of the users.

We could hook up others, but S 3 for us is fine at the moment.

Just a couple of things on how we want to run our stack.

All of them seem fine.

We go with the defaults here.

Quick review.

Everything's fine, and we create our stack.

That's it.

The stack is there, stack has been created.

What we now need to do is go to that user pool

that I mentioned earlier, since we're not using a fixed directory.

In here, I have defined three users that can access our stacks.

But what we need to do is we need to assign that stack to each of the users.

So in my case, I'm going to pick me

and assign that stack that we just created.

And we could send an email to the user to make sure they are aware

of what just happened, and the stack has been assigned to them.

That's all we have to do to set this up.

So if I now go to the link that was emailed to me,

I can log into that A ppS tream session.

I use my credentials that my admin has defined for me.

Here are my stacks.

I use the Red T riangle,

and here's the application that that stack provides for me.

So this is going to take a while.

As I said, it's on- demand, so it's like pooling a PC

and running JMP on that machine.

So it's going to take a few minutes.

The always- running would be much faster.

But again, they would cost money because they're running constantly,

versus the on- demand runs only on demand.

And here, my browser, JMP is started

and JMP is running just perfectly fine in my browser.

So let's do some work.

I'm going to connect to a database.

And just because my administrator has set this up already for me,

there's nothing much for me to do.

The connection to my database is already there.

There are my tables available to me.

So I'm going to pick one of the tables in my database,

and this is a Postgres database.

So I'm going to import it right away, and here's my table.

I've written a nice script to build a wonderful report.

I'm going to just quickly create a new script.

I'm going to cut and paste that from my local machine

to my AppS tream image by using the menu that's available to me.

And now, I can cut and paste it into my scripting editor.

I run that, and here's my report.

That report, I'm going to publish to our Red Triangle JMP Live site now.

So I'm going to File, Publish.

And because, again, my miss rate has set this up for me,

the information about my Red Triangle site is available to me,

so I'm just going to get prompted to sign in to make sure it's really me.

In this case, I'm going to use our imaginary identity,

use the username and password,

sign in, go through the published dialog,

and don't change anything, just hit Publish.

Report has been published.

And now, what I can do,

so I can go to another tab on my browser

and verify that the report is actually published

to our Red Triangle JMP Live site.

So I switch over, go to All Posts,

And here's the report that Tomas just posted a minute ago.

And it looks exactly as it did in my virtual machine.

Thank you very much.