Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Transform your businesses in order to survive in a completely digitized and connected world driven by software innovation.
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
Commenting on Dana Gardner's Briefings Direct blog about freeing mainframe applications, Gregg offers his take on why it is wise to leave applications on the mainframe. This podcast runs for 3:15.
My take, if you will, on keeping applications on the mainframe, as opposed to moving them off, is quite simple. This day and age, it seems to me that whether it’s an IBM mainframe or it’s some other quote/unquote “pseudo mainframe” the industry has recognized the need for large systems which are easily manageable, which are very reliable, which can grow based upon demand quite easily, which are very energy efficient.
And all of these aspects are specifically endemic to the mainframe and the mainframe architecture. So in my mind, folks, when talking about moving off the mainframe, aren’t really talking about moving off the mainframe anymore. They’re really talking about moving to another, quote/unquote, “mainframe”.
However, this mainframe that they're talking about moving to typically has nowhere near the virtualization and management capabilities as the IBM hardware, which means in my mind that while there may be some perceived benefit from a TCO perspective, that in the end, the cost benefits are definitely reduced, and if not almost eliminated. Look at the amount of people it takes to manage, the amount of energy it takes to run, and basically the difficulty that one has with regard to dynamic capacity management specifically when it comes into cloud computing.
It’s hard for me to fathom why anybody would move off the mainframe at this point: easily manage SOA environments across heterogeneous databases, across multiple versions of z/OS, across multiple instances of System z implementation, and then take into account the ability, for example, to run Linux on the mainframe in a very cost effective fashion, I think that what we will see is more and more people moving to the mainframe.
(Photo credit: Pirate’s Gold, Mykl Roventine's photostream)
My basic take is that it’s foolsgood. There’s really no benefit to moving off the mainframe, particularly when you take into account the rest of the industry is moving toward the mainframe architecture. So what would you rather go with, you know, some new architecture with not the history of reliability and serviceability of something like the IBM mainframe System z and z/OS? Or go with -- you know, go with somebody that’s been doing it for three decades? For me, it’s an easy decision.
View all posts from Gregg Willhoit on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.