We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

ebizQ's Business Agility Watch


What's The Best First Use of the Cloud? Talking With iTKO

Vote 0 Votes

Listen to my podcast with John Michelsen, Chief Geek and Founder of iTKO, Inc. John has over 20 years of experience as a technical leader and iTKO recently came out with a big paper on the DevTest Cloud, which we discuss in this podcast.

Listen to or download the 10:20 minute podcast below:

Download file


PS: Now, with this DevTest Cloud, can you tell me what it is versus another type of cloud?

JM: Sure. If you think about platform-as-a-service and infrastructure-as-a-service, a DevTest Cloud is cloud infrastructure that's being used specifically for development and testing of applications under development or test. So the idea is there's production type use of cloud, there's IT-as-a-service, there's all kinds of leveraging cloud type technology out there. DevTest Cloud is specifically targeted for the ramp-up and teardown of development and test labs for use in developing software.

PS: So in this DevTest paper, you make the assertion that this is going to be the best first use of a cloud for an organization. Can you give me a reason why?

JM: Yeah, we do this because we see that if you look at inhibitors to leveraging cloud infrastructure, for production use, we got to get all into the conversations that are really swarming around cloud right now with SLAs, and availability guarantees, and security issues, and who and where are my data, and even platform changes. Because in order to leverage a cloud based data services, I have to switch data engines, and all kinds of complications there.

The DevTest Cloud is by its very nature desensitized; this is pre-production access to systems and test data. Its easy ramp-up and ramp-down, security issues are much lighter, even in most cases performance issues aren't as much of a challenge, SLA is isn't nearly as critical. Of course, we need availability of our lab but we don't have to have five nines even three nines which is huge difference is all possible. So the short story is, Peter, if we want to stick our toe into the cloud, the best way to do it I believe is start building our applications there. Because that way when we roll toward production and as we get these answers, excuse me, questions answered, in production use of the cloud, we'll be already good at it and we'll have infrastructure that can supply us with production quality cloud.

PS: That sounds excellent. Now, what are the key ingredients in a DevTest Cloud?

JM: Yeah, a great question. Because there are some differences between types of cloud and the things you're going to need to make sure are a part of it. The first is we have to have a virtualization engine of some sort, an ability to deliver infrastructure-as-a-service and on-premise that might be VMware servers and Citrix servers, Microsoft, etc. In a public cloud sense, that might be Amazon, or others, Terremark. And then, the second ingredient is you need something that's doing that provisioning, that setup and tear-down activity as I described a minute ago. Essentially, a catalog of all of the different machine images that need to pooled together into a lab so that I can provide a team with the ability to start their lab which might be five machines, tear-down their lab when they no longer need it so that's an infrastructure-as-a-service. A lot of folks would call that virtual lab management on-premise.

And then the third piece is, in order to keep all of the assets in the cloud, we need what we call a virtualization of services solution or a service virtualization offering. This is essentially productizing the stub or mock space because we need the ability to make all of the things we provision in the catalog and deploy into the cloud.

PS: You brought up virtual services; can you elaborate on that a little bit?

JM: Sure. What I mean by a virtual service is essentially think about a typical enterprise application architecture. I got web app location server. I got a message bus. I got some downstream services; I got mainframes, maybe third party applications, maybe a SaaS application that I talked to off my cloud. And you can think of those resources that you can't provision as virtual machines, think of those as wires hanging out of your cloud. Every time my app server has to go off to that off cloud resource, it immediately becomes constrained with regard to the things that made clouds useful to begin with, right.

If there's only one connection to the mainframe, I can't build a dozen labs and provision them on-demand. I am still stuck with my pre-cloud capacity. So when we talk about virtualizing services, we think virtual machines for what is in scope of development or test, virtual services for what is out of scope of development or test. So my app server is a virtual machine, a la VMware or an Amazon machine image. My order management system which is off cloud an a mainframe is actually a virtual service. And again, a virtual service, basically, is a productized, think of it as an intelligent stub or mock.

PS: Great. Now, to bring this into the real world, what are some of the companies actually using the DevTest Cloud?

JM: Sure. Well, unfortunately, most of our customers like to remain anonymous but a couple let us use their names, folks like Allstate and Bank of America. And then it's very common for us to see that about, oh, I'd say 20 or 30% of our customers have already embarked on cloud initiatives, pre-production for Dev and Test. And I really am excited about this because I think there's all kinds of others that are going that way.

The DoD, by the way, is also one of those customers of ours going all the way with Dev and Test Cloud. And so we're seeing the business case around rapid provisioning instead of hours, weeks, even months for the DoD in some cases. They're provisioning their environments in minutes instead of the allocate on a project basis and then hold that investment forever. Its instead of a CapEx, its now an OpEx type cost. So there's a whole new economy brewing, if you will, around how these development projects are getting priced and costed and that is caused by the appearance of this DevTest Cloud.

PS: Right. Now, to go on a different subject, what are your thoughts on the public versus private cloud debate that's been going on?

JM: Yeah, great question. And frankly, maybe much ado about nothing. I think that larger organizations by and large we've seen our starting on-premise or private cloud. By the way, there's one of the big airlines that actually thought they would go private and in fact, could not cost justify a private cloud infrastructure versus a public cloud infrastructure. Most will start private. These guys actually started public because when they did the math, they decided it was better. In the long run Peter, I think that we're going have plenty of infrastructure on-premise with the same kind of provisioning environment that can handle both on-premise infrastructure and accounts on public infrastructure and it won't be just one.

So I think the whole debate around private versus public will actually end up --there are a variety of public infrastructures that I can purchase consumption time on and there is also private. And they'll be more than one private. You don't think about it. Large organizations, many division, they may even centralize a cloud within the company that looks like a private cloud. It could even be the size of many of the smaller players in public cloud. So I think we just need to get away from the notion of do I do I private or do I do public. Well, most of these start private and then leverage public as the cloud technology matures and is able to bridge that seamlessly for you. And just go hybrid; it's going to end up hybrid, start private most of the time. If you don't have infrastructure right now, start public. Most of you will start private though.

PS: Gotcha and that makes a lot of sense. Now, give me a scope of what's ahead for iTKO in regards to the cloud.

JM: Thanks for asking. We have a -- there's a lot to do. When you think about it, I imagine it's fair to say that most software vendors are thinking, okay, let's just make sure our stuff runs in the cloud, kind of as baseline, you definitely have to do that. But every vendor product that you use for application development really needs to embrace the cloud as a way to provide additional capabilities not just yes, it can run from a virtual machine hosted on a VMware server privately or in a Amazon machine image publically, that's the simple stuff, you could do without the vendor making any changes.

What about the ability to access this unlimited capacity; what can that do for more parallelizing development, and compile times, and build activities, and test execution, and all kinds of thing? What about the load testing space? That's such a constrained engineering discipline these days that can be completely upended because of the ability to access enormous capacity on-demand and on a consumption basis, not a pre-allocated huge check that the CIO won't sign. So just start to think about all of the different ways that all of the technologies you use for development and testing can be enhanced with this ability to rapidly provision access computing capacity on-demand.

Let it go so that it's not an extremely costly things, and then you can imagine that for our space we do the virtualization of services, we do the validation of composite applications, we do automated testing, and we do pre-production, basically, performance and functional monitoring. These areas can all benefit from the availability of this kind of cloud infrastructure so our software is going through lots of changes to support those, some already out in product, and delivery, and others coming in the next three to nine months.

ebizQ’s expert blog team covers a broad range of BPM, business integration, business analytics/monitoring, collaboration, content and related issues.

Peter Schooff

Peter Schooff is Contributing Editor at ebizQ, and manager of the ebizQ Forum. Contact him at pschooff@techtarget.com

Recently Commented On

Monthly Archives