Listen to my podcast with Mark Haynie, CTO for Application Modernization and Cloud Computing for Micro Focus. In this podcast, Mark and I discuss some of the continuing questions surrounding cloud computing. Also, Mark gives an excellent explanation on which applications are right for the cloud, along with does it make sense to test applications in the cloud.
Listen to or download the 12:23 minute podcast below:
---TRANSCRIPT---
PS: There's just so much hype going on about cloud right now. Exactly how can an IT purchaser right now cut through the hype and get to what they need to know?
MH: Well, yeah essentially, there is a lot of hype but a lot of it is around, hey, cloud is new, let's start writing new applications. And what we've been doing at Micro Focus for 30+ years is basically saying, no, no, no, existing enterprise applications are proving a valuable service. In many companies, they provide the backbone of what that company is. If it's a healthcare company, then it's the application, the key IT applications that are keeping track of those records and they're doing so using business algorithms that are embedded in.
Well, depending on the age of the applications, they might be COBOL, PL1, even good old mainframe Assembler Language, or newer language Java, C, C++, etc. And so a trap that a lot of folks when they're looking at cloud want to fall into it is, hey, if I'm moving into the cloud, I better learn some of these new languages, Python, Ruby, Apex, a lot of other interesting languages. Maybe I should start rewriting in those languages. But the problem is you fall into that trap. Not only does it take a long time to rewrite those applications and just get up to the same level of functionality, but while you're doing that, your base applications are being changed by your IT staff to come up to speed with new requirements so you're constantly missing the mark.
So with our approach, and I think it's a best practice. When you're looking at moving applications into the cloud, is take existing applications and move them into the cloud providing essentially an enterprise platform-as-a-service, something we do, to be able to provide that veneer that maps the existing APIs and services needed by those applications onto the cloud infrastructure-as-a-service providers. So I think that's one of the ways to cut through the hype. The hype is, hey start writing new applications. We're here to say, no, no, no, cloud is too important to be left to amateurs. Let's use proven business applications and algorithms and just run them in this new environment.
PS: Now, what metrics should a company use to determine what exactly -- which applications they should put to the cloud?
MH: That's a good question because sometimes you don't even know what all the applications are that are in your portfolio. You've built them up over time. I've run across customers that are just still running batch jobs, overnight batch jobs, just because they were always there. And in fact, there's nobody that looks at the reports that are generated from those batch jobs. So fortunately, Micro Focus, other vendors, make tools that will analyze your application portfolio and basically tell you who's using what, what applications use the output of what other applications, or who the human or departments that actually look at those outputs are.
So essentially, that's a first cut. Decide, okay, what applications are important then you can start to look at other metrics to decide whether I move them into the cloud. For instance, if you see applications that require a variable demands, so you have sort of a steady stayed computation throughout the day, throughout the week, throughout the quarter. But then there are these peak times where you're running end-of-year reports, end-of-month reports, end-of-quarter reports. Well then, maybe that's one opportunity to take those applications and exploit the elasticity of the cloud by moving those applications and their data into the cloud. And again, with tools such as those from Micro Focus for providing an enterprise platform to turn these commodity clouds into an enterprise cloud is what we do.
What that means is it is the same environment that's running on-prem so now this gives you the flexibility to say, okay, today I'm going to move these applications and run them in these infrastructure-as-a-service providers such as Microsoft Azure or Amazon Web Services. But tomorrow, maybe I'll bring them back on because I've got more capacity I'll run them locally. And so that's what you want. You want flexibility. It lowers risk; it lowers exposure to changes.
PS: Interesting. Now, once an application is actually in a cloud, how can a company assure itself that it actually performing?
MH: Yeah, what you need to do is because there are different characteristics, the cloud vendor. I mean let's face it, everything is backed by hardware at some point but it's virtualized by hypervisors. It has essentially virtual hard disks. Depending on network traffic, it may be meeting or not meeting the SLAs required for response time, etc. so you need to be able to measure that.
Well, we've just announced a new product, CloudBurst, which essentially is testing-as-a-service taking our proven SilkPerformer product, running that now in the cloud so the tests are executed in the cloud and they test the cloud applications ideally, or they could test on-premise applications. But either way, what you're doing is we're leveraging essentially the elasticity of the cloud once again to test those cloud-based applications so you don't have to build up on-premise data center resources buying hardware or adding software licenses etc. You can use utility based pay-as-you-go pricing schemes just to run these testing-as-a-service applications so you're doing testing today of testing those applications and then maybe tomorrow you're through your test cycle so there's no reason to allocate those resources locally. So yes, testing is important in order to go about verifying that applications are running well in the cloud.
Then what happens? What do you do if they aren't running as well as on-prem? Are you stuck? Do you have to pull those applications back into the cloud? Well again, our enterprise cloud services that hosts SaaS based applications, business applications in these cloud platforms have a number of scalability components such as our Micro Focus Cluster Server that will scale out across these infrastructure-as-a-service providers to create a single system image of multiple, say Amazon instances or Microsoft Azure web roles. So in other words they're working as a group now and so that's how through auto scaling we can mitigate the changes, or the variability, and the performance of individual instances.
PS: Interesting. Now earlier you brought up legacy applications, which I imagine most companies have plenty of. What are some of the considerations of bringing legacy applications into the cloud and what are some of the obstacles as well?
MH: Well, what's funny is in legacy applications is any app i wrote yesterday so it might be an Excel spreadsheet app, or it might a Google App Engine app that I wrote yesterday, it's legacy today because I'm off building something else. So what you want to do is you again want to use some of those application portfolio management tools to say, okay, which is most important to my business or which is the most variable of types of applications.
And now, how can I move those? Can I move those into a cloud framework? And for something like an Excel spreadsheet, well, that's going to be tough to do although you can use remote desktop techniques into a Windows image that's running into a cloud but it syncs still single user, single threaded, single screen type of application. But if you look back on say, business IT applications of a bygone era, those that used CICS, or DB2, or IMS, these transaction managers, applications written in COBOL, PL1.
What's interesting about those applications that might be running on mainframe systems, mainframe transaction managers today, those are actually perfectly suited for running in the cloud if you could get that compatibility layer once again. Because applications that were built to run 20 years ago on mainframes of the era, they were supporting maybe a thousand users on a machine as powerful as a smartphone today in terms of memory, and in terms of processing power.
When I got into this business, the mainframe was 6 MIPS of processing power and 6 megabytes of RAM. Well, you got more power than that in your smartphone. Yet they supported a thousand concurrent terminal users. In other words, those applications and the application frameworks could support this multi-tenant, multi-user capability very well and they used a technique that's very similar to RESTful web services today. So what you see is the same techniques that were essentially invented 20 years ago to support large amounts of users on less powerful hardware platforms now work perfectly for scaling those applications out into the cloud and then scaling them up to potentially tens of thousands of transactions. And so the key then again is to make sure that the platform supports all of those same APIs so applications can move seamlessly into the cloud.
PS: Interesting. Now, in terms of applications testing, does it make sense for companies to do application testing in the cloud?
MH: Yeah, again with this CloudBurst application testing environment that I mentioned earlier based on SilkPerformer, is basically -- it still works pretty much the same so as the SilkPerformer tool that's been around for a long time so you still build the tests, and construct them, and manage them from like a desktop GUI, that's nice. But then when you push the button, okay, now let me do stress testing and let me start ramping up over time from 1 concurrent user to 10, to 100, to 1,000, to 10,000 or more. Some of our early customers are already testing next Christmas' Christmas shopping websites so naturally they're trying to test 100,000 concurrent users or other customers are testing next tax year's online tax preparation software so now you're talking about hundreds of thousands of concurrent users that you need to test.
Well, why are you going to go out and buy on-premise hardware to do that level of stress testing or performance testing? Just use the cloud to drive those web service requests. So as long as an application is web service based, or web paged based, Web 2.0, Web 1.0, or similar kinds of technologies you can design tests and then push them up into this testing-as-a-service platform. And then they go off, they do their testing for a day, or a week, or whatever and then report back to the testers to what the efficiency is and the expected performances.
Leave a comment