This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
To start at the beginning, follow this link to the first post.
The next post in the series is here.
---------------
You may want to run your production Liberty servers on z/OS like you run your production WAS traditional servers, as started tasks managed by some automation. But what about servers for use by development (I’m thinking of ‘development’ as the folks who write and maintain the applications you run in your production servers)? For WAS traditional those were just other servers that ran as started tasks like the production servers (maybe on different LPARs or otherwise separated). With Liberty you have the option to run those servers as simple Java programs started from the USS shell. Application developers could just start and stop them on their own.
A first reaction to that proposal might be, “We can’t let application developers start servers on their own!” But why not? A server started from the shell will run under the identity of the person who started it. If that identity doesn’t have access to Liberty authorized services (via the Angel) then it is simply a Java program. Do you let your developers run Java programs on z/OS? It may be that the only difference between them running some Java program and running a Liberty server without any authorized services is that the server might try to open a port. You probably have restrictions about who can open ports on your z/OS system. But you could grant access to a range of ports used for development purposes on a development system, perhaps.
And access to any other resources would be constrained by what that developer is allowed to access (test DB2 instances, MQ queues etc). This might be better than having ‘official’ development servers that manage to get accidentally configured with access to production resources.
With access properly restricted, you might be able to allow developers to start their own servers on z/OS (just like they would do on their laptop or other non-z/OS environment) and get your WAS administrators out of the business of managing all those development servers.
Of course you still have to worry about developers starting up hundreds of servers or chewing up ridiculous amounts of system resources. But you can manage that through the same controls you have in place to prevent people from doing that today. Remember, without authorization, this is just a Java program. If your developers can’t start a JVM with a 100GB heap today, they won’t be able to start a Liberty server with a 100GB heap tomorrow. Restrict their ability to trash your system in the same way you are already (hopefully) preventing it today.
My point is, as you ponder migrating your WAS traditional servers over to Liberty on z/OS, you might only really need to migrate the production ones and let the developers worry about their own servers. That might allow them to get started doing any application migration work that is required without waiting for formally defined ‘development servers’ and substantially cut back on the number of servers the sysprogs need to worry about. Maybe.