Choose Language Hide Translation Bar

JMP in the Cloud — Configuring and Running JMP for Non-persistent App Virtualization Services (2022-US-30MP-1088)

Managed, non-persistent desktop and application virtualization services are gaining popularity in organizations that wish to give employees more flexible hardware choices (so-called "BYOD" policies), while at the same time gaining the economies of scale for desktop software management, system upgrades, scale-up and scale-down and adjacency to cloud data sources. In this paper, we examine using JMP Pro in one such service: Amazon AppStream 2.0. We cover configuration, installation, user and session management and benchmark performance of JMP using various available instances.

 

 

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,

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.

Presenter