[Info-vax] Should VSI create a modern day VMS applications book ?

Kerry Main kemain.nospam at gmail.com
Tue Aug 21 22:12:17 EDT 2018


> -----Original Message-----
> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of IanD via Info-
> vax
> Sent: August 20, 2018 1:18 PM
> To: info-vax at rbnsn.com
> Cc: IanD <iloveopenvms at gmail.com>
> Subject: Re: [Info-vax] Should VSI create a modern day VMS applications
> book ?
> 
> On Monday, August 20, 2018 at 12:10:06 PM UTC+10, Kerry Main wrote:
> > > -----Original Message-----
> 
> <snip>
> 
> >
> > Those that try to implement the DevOps concept are either part of a
> > small office or have no experience in the culture of medium to large
> > IT environments.
> >
> > Regards,
> >
> > Kerry Main
> > Kerry dot main at starkgaming dot com
> 
> Where I work now is not a small organisation in terms of IT.
> In 2016 (I'm using Google data), they spent 1.9B on IT. That's 5.2 million
a day.
> I think that qualifies as at least a medium IT shop
> 
> They have already begun moving to a DevOps model and it's working rather
> well for them
> 
> Here's what works today, already deployed and already running supporting
> production workloads. The trend to deploy to a DevOps model is growing
> rapidly and is being asked for by the business arm of the organisation as
they
> experience tangible benefits
> 
> - Continuous deployment (That's from software releases through to OS
> patching)
> - Automated environment refreshing (If an issue is detected, the server is
> simply refreshed, as in wound down and spun up again in it's pool)
> - Standard pattern offerings, which fit an increasing number of
requirements
> - Workload analytics to attempt to predict workloads as well as curtail IT
> overspend on servers just sitting there idle (especially important in
Cloud
> environments)
> 
> DevOps is not pie-in-sky but it does take time to deploy and move towards
> 

The issue is not technical (ok, perhaps a small bit), but rather cultural. 

> The biggest change is in people's thinking. Getting the various parties to
> come to grips that they cannot lay claim to the underlining
infrastructure.
> Everything is a service, the OS being offered, the DB instances,
networking
> (although this is a work in progress, virtual load balancing is tricky),
logging is
> also a service, in-depth workload metrics (there are standard offerings
that
> come with every deployment but if you want extra you order it as a service
> offering)
> 

Reality check for the "everything is a service" (aka SOA).

Again, its not technical. 

Sample issue:
App A uses serviceA created by Group1. No issues. 
App B finds serviceA lacking in some way. Requests Group1 add functionality
to ServiceA.
Group1 says "good idea, but its not our priority right now. We will do it in
next years release"
AppB group says "not good enough". AppB writes their own service to address
their specific requirements.

Result - you end up with hundreds/thousands of overlapping or similar
functionality services - how do you manage the complexity and/or keep track
of these across all of the various App/Infrastructure support groups??

> It's not a silver bullet and it will not solve every IT issue out there
but in terms
> of the next logical layer over the IT landscape, I think it's doing ok.
You also
> need to remodel how your groups interact with one another too, turning
> those processes into DevOps compliant models is part an parcel of a total
> DevOps solution
> 
> The real question is how will VMS mingle in such a crowd and turn-heads?
> How will it stand out and offer value against this backdrop of near real
time
> reconfiguration offerings?
> 

Again, DevOps issues are not technical. All platforms have the same
non-technical cultural issues.

> HP harped on a lot about the cost of ownership with VMS, that fell on deaf
> ears by and large. People stopped listening when they saw the cost of VMS!
> Linux simply hammered VMS out of existence on this point
>

 I agree HP (and Compaq/Dec before them) failed to recognize that their
competition was not Solaris, AIX etc., but rather commodity OS's that were
not better technically, but offered "good enough" functionality at a
fraction of the cost (or at least it was perceived to be a fraction of the
cost)

Having stated this, VSI has already discussed moving to a subscription model
of some sort in the future on X64, so it will be much more competitive.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com








More information about the Info-vax mailing list