This is JMP in the Cloud, configuring and running JMP
for non- persistent application virtualization services.
I'm Dan Valente, the Manager of Product Management at JMP,
and I'm joined by Dieter Pisot, our Cloud and Deployment Engineer,
also on the product management team.
Today, we're going to talk
about how a organization called Red T riangle I ndustries,
who's been a JMP user for the last several years,
in their JMP growth has been growing
in their R&D departments, or quality departments, IT,
how they're considering adapting
to new remote and flexible work environments
and hopefully solving some problems with some new technology
for virtualizing JMP in a non- persistent way.
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.
This is how Red T riangle has been growing, started in 2015 with a core set of users.
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 P ro for our data science team
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.
In the last year,
we also added JMP Live to our product portfolio.
You can see a screenshot of JMP L ive in the back.
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 L ive.
So how is JMP being used at Red T riangle?
Well, one thing that we did in the past year,
our I T 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 for growth opportunities, training opportunities.
Also, this is how we found out
that some of our users want to have JMP presented to them
in different ways.
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.
This is put together, a situation, some pains,
some implications, and some needs that we're considering using JMP
in a presentation virtualization
in a application virtualization standpoint.
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.
In the past year, JMP Live for enterprise reporting
and sharing of JMP discoveries.
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.
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.
Historically,
our standard laptop deployments have used between 8 -16 gigs of RAM.
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 e nvironment,
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.
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.
The implications for this
is we've been given a mandate, like many other organizations,
to reduce our corporate technology spend.
We feel the biggest potential for reducing that technology spend
is through automation.
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.
Our power users that are analyzing our biggest datasets will need more RAM,
more speed available to them.
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.
That's what we'll get to in the demo here.
Finally, that better rollout of software updates
and the transparency of usage to our executive team,
who's using the software, how much are they using it, et cetera,
are our implications for us investigating this technology.
As far as needs, we want to go with a cloud provider.
We're not going to build this tool inhouse.
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 S ervices, 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 i nformation,
and also have that seamless version control.
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.
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 AppStream.
Dieter.
Thanks Dan.
The first thing we have to do is we have to go to the image builder
and launch that.
We have to pick a Windows operating system.
Windows Server '19 is what we want to pick here.
There's 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 are Red Triangle, we use Red Triangle for this one.
We have to pick a size for the image that we want to configure.
We pick a standard one, medium.
I'm going to add an I AM role
because I want to connect to S3, where I keep all my installer.
Just to make sure I can connect there, I add a role with access to S3.
Then, I have to define in which private network
I want to run my image builder here.
Pick a 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, s o we launch our image builder.
This is going to take a while.
AWS AppStream basically set up a virtual machine for us
that we can connect to and set up our application.
After that has started,
we connect to the machine as an administrator.
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.
We have the application icon here.
In addition to that,
I have created a JSL script in the Program Data- SAS- JMP directory,
jmpStartAdmin, 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 L ive 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 Pro that we just installed.
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.
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.
We are going to switch users here.
We have the ability to switch to a template or test user.
The template user, that's defining
how the user would actually run the applications.
Whatever we do here is going to be remembered,
and the user will have the same experience as our template user.
We can do a few things in the setup.
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.
Here we are, applications perfectly connected to our database.
With that, we're fine with our setup.
We go back to the image assistant.
Not going to use the test user, switch users again.
We're not going to show the test user.
I'm going to go back to the administrator and continue with the setup of our image.
We switch here.
Same, not going to the test user.
Now, what we have to do is we have to optimize.
You have to configure the application.
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.
What AWS AppStream is doing now
is optimizing the application for the user.
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.
We disconnect and create the image now.
With that, we are going to get disconnected
from the image builder.
Lost the connection, obviously, and our session expired.
We return to the AppStream 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.
The next step is to create the fleet the images are going to run on.
We create the fleet, we pick which type of fleet.
We're going to go with on-demand fleet because that's much cheaper for us.
The images only run when the user actually requests the image,
whereas the always- on will be running constantly.
Here, we give it a name and a description.
We then pick the type of image we want to give to our users.
A 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.
We click Next.
We pick the image that we just created to run on our fleet.
We define the virtual network,
and the subnets that our fleet should run in.
We'll just pick the same we used before.
Also a security group, of course,
to make sure that only the users and host that we want can access our fleet.
Again, we want to give the fleet internet access.
We're going to check that
to make sure users can publish to our JMP Live site.
We could integrate active directory authentication here,
but we don't want to do that.
That would take us some time.
We're just going to go with some local users
that I have already created.
We click Next.
We are presented with a review of what we did,
and it's all fine.
We are creating the fleet.
There's some pricing information we have to acknowledge.
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.
Here, we create the stack.
As well, give it a meaningful name.
Since this is our Red Triangle site,
we'll go with a very similar naming convention here.
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 S3 bucket that's available to each of the users.
We could hook up others, but S3 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.
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'd mentioned earlier
since we're not using active 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.
In my case, I'm going to pick me
and assign that stack that we just created.
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.
If I now go to the link that was emailed to me,
I can log into that AppS tream session.
I use my credentials that my admin has defined for me.
Here are my stacks.
I use the Red Triangle.
Here's the application that that stack provides for me.
This is going to take a while.
As I said, it's on -demand.
It's like booting a PC and running JMP on that machine.
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.
Here in my browser, JMP is started,
and JMP is running just perfectly fine in my browser.
Let's do some work.
I'm going to connect to a database.
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.
My table's available to me.
I'm going to pick one of the tables in my database.
This is a Postgres database.
I'm going to import it right away.
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 AppStream image
by using the menu that's available to me.
Now, I can cut and paste it into my scripting editor.
I run that.
Here's my report.
That report I'm going to publish to our Red Triangle JMP Live site now.
I'm going to do File , Publish.
Because again, my administrator has set this up for me,
the information about my Red Triangle site is available to me.
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 publish dialogue,
and don't change anything, just hit Publish.
Report has been published.
Now, what I can do, I can go to another tab on my browser
and verify that the report is actually published
to our Red T riangle JMP Live site.
I switch over, go to All P osts.
Here's the report that Tomas just posted a minute ago .
It looks exactly as it did in my virtual machine.
Thank you very much.