Transcript of a BriefingsDirect webinar with David McFarlane and Adam Markey on the economic and productivity advantages from application modernization.
Listen to the podcast. Download the podcast. Find it on iTunes/iPod and Podcast.com. Learn more. Sponsor: Nexaweb Technologies.
Announcer: Hello, and welcome to a special BriefingsDirect presentation, a podcast created from a recent Nexaweb Technologies Webinar on application modernization.
The webinar examines how enterprises are gaining economic and productivity advantages from modernizing legacy and older client-server applications. The logic, data, and integration patterns' value within these older applications can be effectively extracted and repurposed using tools and methods, including those from Nexaweb. That means the IT and business value from these assets can be reestablished as Web applications on highly efficient platforms.
We'll learn how Nexaweb has worked with a number of companies to attain new value from legacy and client-server applications, while making those assets more easily deployed as rich, agile Web applications and services. Those services can then be better extended across modern and flexible business processes.
On this podcast, we'll hear from Dana Gardner, principal analyst at Interarbor Solutions, as well as David McFarlane, COO at Nexaweb, and then Adam Markey, solution architect at Nexaweb.
First, welcome our initial presenter, BriefingsDirect's Dana Gardner.
Dana Gardner: We're dealing with an awful lot of applications out there in the IT world. It's always astonishing to me, when I go into enterprises and ask them how many applications they have in production, that in many cases they don't know. In the cases where they do know, they're usually off by about 20 or 30 percent, when they go in and do an audit.
In many cases, we're looking at companies that have been around for a while with 10 or 20 years worth of applications. These can be on mainframe. They can be written in COBOL. They could be still running on Unix platforms. In a perfect world we'd have an opportunity to go in and audit these, sunset some, and re-factor others.
Today, however, many organizations are faced with manpower and labor issues. They've got skill sets that they can't bring in, even if they wanted to, for some of these older applications. There is, of course, a whole new set of applications that might not be considered legacy, but that are several years old now. These are N-tier and Java, distributed applications, .NET, COM, DCOM, a whole stew in many organizations.
What I am asking folks to do, now that we're into a situation where economics are probably more prominent than ever -- not that that's not usually the case in IT -- is to take a look at what applications are constraining their business. Not so much to worry about what the technology is that they are running on or what the skill sets are, but to start factoring what new initiatives they need to do and how can they get their top line and bottom line as robust as possible? How do they get IT to be an enabler and not viewed as a cost center?
This is really where we should start thinking about modernizing and transforming IT -- getting application functionality that is essential, but is in someway handicapping what businesses want to do.
We want to exploit new architectures and bring more applications into association with them. It's not just architectures in terms of technology, but approaches and methodologies like service-oriented architecture (SOA), or what some people call Web-oriented architecture (WOA), looking to take advantage of interfaces and speed of innovation so that organizations can start to improve productivity for their internal constituents, in this case usually employees or partners.
Then, increasingly because of the difficulty in bringing about new business during a period of economic downturn, they're reaching out through the Internet, reaching out through the channels that are more productive, less costly and utilizing applications to focus on new business in new ways.
SOA and mobile devices
Increasingly, as I mentioned, this involves SOA, but it also increasingly involves mobile. We need to go out and reach people through their mobile Internet devices, through their iPhone and their BlackBerry, and a host of other devices at the edge. You need to be able to do that with applications and you need to be able to do it fast.
So, the goal is flexibility in terms of which applications and services need to reach new and older constituencies at less cost and, over time, reduce the number of platforms that you are supporting, sunset some apps, bring them into a new age, a new paradigm, and reduce your operating costs as a result.
Information really is the goal here, even though we are, with a handful of applications, starting to focus on the ones that are going to give us the biggest bang for the buck, recognizing that we need to go in and thoughtfully approach these applications, bring them into use with other Web services and Web applications, and think about mashups and Enterprise 2.0 types of activities. That involves expanding the use of these new methodologies.
One of the things that's interesting about companies that are aggressively using SOA is they also happen to be usually aggressive in using newer development platforms and tools. They're using dynamic languages, Web interfaces, and rich Internet application (RIA) interfaces. This is what's allowing them to take their newer applications and bring them into a services orientation reuse. Some of those services can be flexible and agile.
That's not to say you can't do some of those things with the older applications as well. In many cases, tools are being brought about and third-party inputs, in terms of professional services and guidance, are coming around. I'm recommending to people to respond more quickly, to save operational costs, to get agile and reach out through these new edge devices and/or the Internet, and do it in a fairly short order.
It's amazing to me that for those companies that have moved in this direction, they can get applications out the door in weeks rather than months, and in many cases, you can transform and modernize older applications on aging platforms just as quickly.
We want to move faster. We want to recognize that we need a higher payoff, because we also recognize that the line-of-business people, those folks that are tasked with developing new business or maintaining older business, are in a rush, because things are changing so quickly in the world around us. They often need to go at fast-break or breakneck speed with their business activities. They're going to look at IT to be there for them, and not be a handicap or to tell them that they have to wait in line or that this project is going to be six to eight months.
So, we need to get that higher agility and productivity, not just for IT, but for the business goals. Application modernization is an important aspect of doing this.
How does modernization fit in? It's not something that's going to happen on its own, obviously. There are many other activities, approaches, and priorities that IT folks are dealing with. Modernizing, however, fits in quite well. It can be used as a way to rationalize any expenditure around modernization, when you factor in that you can often cut your operating costs significantly over time.
You can also become greener. You can use less electricity, because you're leveraging newer systems and hardware that are multi core and designed to run with better performance in terms of heat reduction. There are more options around cloud computing and accessing some services or, perhaps, just experimenting with application development and testing on someone else's infrastructure.
By moving towards modernization you also set yourself up to be much more ready for SOA or to exploit those investments you have already made in SOA.
Compliance benefits
There are also compliance benefits for those organizations that are facing payment-card industry (PCI) standards in financial or other regulatory environments, freeing up applications in such a way that you can develop reports, share the data, and integrate the data. These are all benefits to your compliance issues as well.
As I mentioned earlier, by moving into a modernization for older applications, you've got the ability to mash up and take advantage of these newer interfaces, reuse, and extended application.
There is a whole host of rationalizations and reasons to do this from an IT perspective. The benefits are much more involved with these business issues and developer satisfaction, recognizing that if you are going to hire developers, you are going to be limited in the skill sets. You want to find ones that are able to work with the tools and present these applications and services in the interfaces that you have chosen.
Keeping operations at a lower cost, again, is an incentive, and that's something they can take out to their operating and financial officers and get that backing for these investments to move forward on application modernization and transformation.
One of the questions I get is, "How do we get started? We've identified applications. We recognized the business agility benefits. Where do we look among those applications to start getting that bang for the buck, where to get modern first?"
Well, you want to look at applications that are orphans in some respect. They're monolithic. They're on their own -- dedicated server, dedicated hardware, and dedicated stack and runtime environment, just for a single application.
Those are good candidates to say, "How can we take that into a virtualized environment?" Are there stacks that can support that same runtime environment on a virtualized server, reduce your hardware and operating costs as a result? Are they brittle?
Are there applications that people have put a literal and figurative wall around saying, "Don't go near that application. If we do anything to it, it might tank and we don't have the documentation or the people around to get it back into operating condition. It's risky and it's dangerous."
Conventional wisdom will say don't go near it. It's better to say, "Listen, if that's important to our business, if it's holding our business back, that's a great target for going in and finding a way to extract the logic, extract the data and present it as something that's much more flexible and easy to work with."
You can also look for labor issues. As I said, if skills have disappeared, why wait for the proverbial crash and then deal with it? It's better to be a little bit proactive.
We also need to look at what functional areas are going to be supporting agility as these business requirements change. If you're an organization where you've got supply chain issues, you need to find redundancy. You need to find new partners quickly. Perhaps some have gone out of business or no longer able to manufacture or supply certain parts. You need to be fleet and agile.
If there are applications that are holding you back from being able to pick and choose in a marketplace more readily, that's a functional area that's a priority for getting out to a Web interface.
Faster, better, cheaper
People are going to be looking to do things faster, better, cheaper. In many cases those innovative companies that are coming to market now are doing it all through the Web, because they are green-field organizations themselves. They are of, for, and by the Web. If you're going to interact with them and take advantage of the cost, innovation, and productivity benefits they offer, your applications need to interrelate, operate, and take advantage of standards and Web services to play with them.
You also need to take a look at where maintenance costs are high. We've certainly seen a number of cases where by modernizing applications you have reduced your cost on maintenance by 20 or 30 percent, sometimes even more. Again, if this is done in the context of some of these larger initiatives around green and virtualization, the savings can be even more dramatic.
I also want to emphasize -- and I can't say it enough -- those SOA activities shouldn't be there for just the newer apps. The more older apps you bring in, the more return on investment you get for your platform modernization investments, as well as saving on the older platform costs, not to mention those productivity and agility benefits.
We also need to think about the data. In some cases, I have seen organizations where they have applications running and aren't really using the application for other than as an application repository for the data. They have a hard time thinking about what to do with the data. The application is being supported at high cost, and it's a glorified proprietary database, taking up app server and rack space.
If you're looking at applications that are more data centric in their usage, why not extract that data, find what bits of the logic might still be relevant or useful, put that into service orientation, and reduce your cost, while extending that data into new processes and new benefits.
It's also important to look at where the technical quality of an app is low. Many companies are working with applications that were never built very well and never performed particularly well, using old kludgy interfaces. People are not as productive and sometimes resist working with them. These are candidates for where to put your wood behind your arrow when it comes to application modernization.
In beginning the process, we need to look at the architecture targets. We need to think about where you're going to put these applications if you are refactoring them and bringing them into the Web standards process.
It's important to have capacity. We want to have enough architecture, systems, and runtime in place. We should think about hosting or collocation, where you can decrease your cost and the risk of capital expenditure, but at the same time, still have a home for these new apps.
You certainly don't want to overextend and build out platforms without the applications being ready. It's a bit of a balancing act -- making sure you have enough capacity, but at the same time performing these modernization transformation tasks. You certainly don't want to transform apps and not have a good home for them.
Also important is an inventory of these critical apps, based on some of the criteria, we have gone through.
Crawl, walk, run
The nice thing about creating the categorization is that once you've got some processes in place on how to go about this, with one application you can extend that to others. The crawl-walk-run approach makes a great deal of sense, but when you've learned to crawl well, extend and reuse that to walk well, and then scale it from there.
This construction, deconstruction, rationalization process should also be vetted and audited in the sense that you can demonstrate paybacks. We don't want to demonstrate cost centers becoming larger cost centers. We want to show, at each step of the way, how this is beneficial in cost as well as productivity. Then, we need to focus continually on these business requirements, to make a difference and enhance these business processes.
There are some traps. It's easier said than done. It's complicated. You need to extract data carefully. If you start losing logic and access to data that are part of important business processes, then you're going to lose the trust and confidence, and some of your future important cost benefit activities might be in jeopardy.
It's important to understand the code. You don't want to go and start monkeying around with and extracting code, unless you really know what you're doing. If you don't, it's important to get outside help.
There are people who are not doing this for the first time. They've done it many times. They're familiar with certain application types and platforms. It's better to let them come in, than for you to be a guinea pig yourself or take trials and tests as your first step. That's not a good idea when you're starting to deal with critical and important application.
Stick to processes and methods that do work. Don't recreate the wheel, unless you need to, and once you have got a good wheel creation method, repeat and verify.
You need to be rigorous, be systemic, and verify results, as we have said. That's what's going to get you those transformational benefits, rather than piecemeal benefits. You're going to see how application modernization fits into the context of these other activities, You're going to be well on the way to satisfying your constituencies, getting the funding you need, and then seeing more of your budget going to innovation and productivity and not to maintenance and upkeep.
There are a lot of great reasons to modernize, and we have mentioned a number of them. There are backwards and forwards compatibility issues. There are big payoffs in cost and agility, and now it's time to look at some of the examples of how this has been put into place.
Announcer: Thanks Dana. Now, we'll hear from David McFarlane, COO at Nexaweb, on some use-case scenarios for adopting and benefiting from these application modernization opportunities. Here is David McFarlane.
Understanding value
David McFarlane: We're going to go a little bit deeper and actually take a look at a case study of one of our clients, one of our successful implementations, and see the value that came out of it.
To really understand what value is, we have to understand how we're going to quantify it in the first place. We're probably all in IT here, and we're probably all IT heads, but we have to take a step back, take a top-down approach, and understand how we define that value in the business.
As Dana said earlier, application modernization impacts all areas of your business, and the three areas that it really impacts are business, operations, and IT. So, you have to step outside your role. You have to see what value the business would see out of it, what operations would see out of it, and also for yourself in IT, what gains and benefits you would get out of that. When you add them all together, you get the overall value for that application modernization.
Let's take a look at a real case study as an example. Just to set some background, we have a legacy system, a customer relationship management (CRM) call center application for one of our clients. They have about five call centers, with around 50 employees, and they're on a C++ client-server application.
The important thing to note about this is that, in legacy systems, there are usually multiple instances of this application. Since it's a client-server app, we have to remember that it's also deployed and managed on each individual desktop. Each individual employee has their own installation on their desktop, which is sometimes a nightmare to manage for most IT shops.
We took that system and built a modernized system with it. We had a J2EE architecture with desktop browser look and feel, as Dana talked about earlier. You get that real performance out of the installed client-server application, but it's delivered over the Web via zero client install.
You don't have to do anything besides update your Web server, and everybody automatically has the new application, the new look and feel, the new business logic, and access to whatever data you've hooked it up to on the backend.
Also important is the ability of our system that we modernized to be deployed as an open standard. We used J2EE architecture, and that means we're able to integrate with anything that you have on your back end via open Java application programming interfaces (APIs).
There is a vast array of open source products out there waiting to be used, to be integrated, and to modernize systems. There's also a large workforce that will be able to understand a Java application as opposed to a custom C++ application or even a COBOL application. We also consolidated it to one distributed instance, since we can now manage it centrally from one data center.
ROI analysis
When you're doing a modernization, you're probably going to have to do some sort of return on investmment (ROI) analysis to understand exactly what you're going to get out of this application, and that's going to take some time.
If you're coming from an IT perspective, you might have most of the benefits already in your head: "I'll have people using Java instead of COBOL. I'll have all the developers focused on one development language, instead of multiple development languages. I'm going to be able to decrease by deployment time, etc."
But, when justifying something like this, you need to take a step back, and as we said before, look at the factors in these three areas that are most affected by application modernization. As Dana pointed out, it's business operations in IT. So, we go ahead and look at the business.
We have to ask a few questions here: "Who are my users? How long does each transaction take?" Say I'm a call center and it takes few minutes for a user to get through a transaction, if I can cut that to one-and-a-half minutes or even one minute, I'm able to increase productivity significantly.
The next part is operations. How is that productivity increased, but also what does it mean to have a modern application infrastructure? If previously I had to come in to work and sit down at my desktop, because that's the only place that application was installed, maybe I don't even need to come in to work anymore. Maybe I can work from home. Maybe I can work from India, if I want to, as long as I have VPN access into that sort of an application. You can begin to see the operational flexibility that you get out of that.
Then, as we look into the IT benefits that we have here, how long did it take to make a change to my legacy system? One of the biggest benefits that we're seeing is when coming from legacy C++ PowerBuilder applications, where you really have to code each and every aspect of the user interface (UI), the business logic, and the specific data interaction, because we don't have SOA to leverage, and we don't have hooks into services that we've built or are planning to build in our application.
Also, we have to think of what the developer actually had to do to make that change. In older technologies, they might not have a way to prototype the UI and show the business users feedback before they are able to get sign off on what they're going to build. They might have to program each and every element of the user interface, all the way down to writing SQL stored procedures that are application-specific to a database.
Going to a modern architecture, you're going to have services and you're going to have your object-relational management capabilities. You're going to have some great middle-tier applications like Spring and Struts to enhance the development. Obviously, with Nexaweb technologies, you have that ability to create the declarative user interfaces, which speeds up UI development time significantly.
Also we have what hardware and software do the application run on, and what licenses am I paying for? As Dana pointed out earlier, you'll have a significant opportunity for maintenance savings, when you go to a modern architecture.
Productivity gains
We asked all these questions, and we found some significant areas of value in our CRM modernization case. In the business we actually saw a 15 percent gain in end-user productivity, which impacted our clients by about $1.5 million a year. In these times, you're actually able to slim down or trim your workflow if you have a more productive application. In this case, which are the productivities that are able to do more calls quicker, service customers quicker? Ultimately, that ends up in end user satisfaction and dollars saved as well.
Next, you have the operational value. What we had here was a decrease in audit time. We found that their auditors were going around to each individual desktop and seeing exactly which applications were installed on their computer. They had to look at each of the five instances in each call center for auditing, instead of looking at one consolidated instance, with just one database and book of record for all the operation there. So, that saved a lot of auditing time for them, which is really great.
Another thing was that it improved the performance of another help desk. This was a help desk for customer support, but the internal IT help desk actually saw huge improvement. Because the application was centrally managed, all people had to do was go to a Website or click a link to access that application, instead of having to install software. As you know, when you install software, a ton of things can happen. You actually have to do a lot of testing for that software as well. All that has been reduced, and we're saving about $15K there.
When you look at the IT benefits, we have that IT developer productivity gain that we talked about. We eliminated some hardware and software for those five instances and some of that maintenance cost. So, that's and $85K impact. There are the deployment benefits of a RIA, when you're going from deploying applications on 250 computers to zero computers. You're going to see an immediate impact there, and that was around $250K for the time to do that, the software that it took to push that out, and for the support that it needed to run.
Because of the change management benefits from RIAs, the development productivity, and the ability to go from requirements to design, to testing, to production much more quickly than a client-server application, we're able to see a 90 percent gain there, which had a $200K impact.
When you look at it in total, the yearly bottom line improvement was about $2.23 million for this one instance, with one time improvement of $85K for the hardware and the software that we got rid of. It was only a one-time investment of about $800K.
I say "only," but if you look at the business, operational, and the IT impacts together, you get payback in the first full year. If you were only coming from that IT perspective, you would have seen that the payback is actually a little bit longer than a year.
If you add all those numbers up, you get something a little less than $800K, about $700K, I believe. That will be about 14- or 15-month payback instead of about a 5- or 6-month payback. When you're trying to make a case for modernization, this is exactly what your CFO or your CEO needs to know -- how it affects your bottom line from all areas of the business, not just IT.
Let's not forget the intangibles that come with application modernization. It's always about the bottom line. There are some great things that you get out of a modern application infrastructure, and the first thing you get, when you look at the business, is improved response time.
Happier CSRs
The number one thing I could think of is that your customer service representatives (CSRs) are going to be happier, because once they click a button, it's not going to take two seconds to respond like the old application. It's going to be fast. It's going to be rich. You're not going to have any installation issues when you do an upgrade. It's going to be smooth.
You're going to have happier CSRs. Having happier CSRs means that you're going to have improved customer service, and a customer satisfaction level, when people get calls through quicker, and when people talk to happy customer service representative.
Also, when you're doing application modernization, you have a good opportunity to automate manual portions of the business process. You can go in and say, "This person is cutting and pasting something into an Excel spreadsheet, and emailing this to somebody else as a report after they're done." Maybe there's an opportunity there to have that done automatically. So, it saves them time again. That's where you can really find your increased productivity.
When we look at operations, we actually enabled real estate consolidation. I didn't put those numbers in the ROI, because they were probably going to do that anyway, but it was an enabler. Having a technology to go from five call centers to one call center with distributed agents across the country and across the world saves the business a lot of money on the real estate, the power, and the infrastructure needed to have five call centers up and running.
Again, you get the workforce flexibility, because I can work from home, work from India, or come and work from the office. I could do this job from anywhere, if I have access to this application. Obviously, we're able to bring outsourced call centers online on-demand with that.
Then, we move on to IT. As I said before, it's short release cycles with more functionality. When release cycles are shorter, you can incrementally build in more features to your application, make people more productive, and make the application do more in less time, which is obviously what we want to do.
We have a standardized J2EE architecture, which means the people that you're going to look for to maintain the application are going to be out there. There is a huge number of Java developers out there waiting and ready to come in to maintain your application.
We're built on open standards to ensure that the application is ready for the future. There are a lot of RIA technologies that try to lock you in to one runtime and one development methodology. We use open standards as much as we can to push your application out the door as fast as possible, and be as maintainable as possible, and as ready for the future as possible.
Announcer: Thanks, David. Now, we'll hear from Adam Markey, solution architect at Nexaweb, on specific deployment examples of application modernization projects. Here, then, is Adam.
Enterprise-wide value
Adam Markey: As we look at these different customer examples, we really want to see how they've had an impact of value across the enterprise, and see, from a business point of view, the ability to be able to increase market reach, improve user productivity, decrease the time to market, increase customer engagement and loyalty, and sustain, if not build upon, that competitive advantage.
We also want to look at the operations as well and understand how this new architecture has actually realized benefits in terms of a reduced real estate, greater utilization of global workforce, reduction in energy, moving to green architectures, and improving the overall vendor management.
For those closely responsible for the organization and who deliver this capability, we want to look at IT and how this process helps deal with the rapidly changing demographics in the IT skills market. As the baby boomers move on and out of or off the job market, many of the legacy skills that we relied on so heavily through the years are becoming very rare and hard to find within the organization.
We'll take a look at that process efficiency, and generally how we can improve the overall efficiency and cost in terms of licenses and the use of open source. So, let's take a closer look at a few examples to help illustrate that. There's nothing wrong with your screens here. This first example is actually an example of the modernization of a Japanese phone exchange trading platform.
In this case, this was a trading platform built by Enfour, Bank of Tokyo-Mitsubishi (BTM). The challenge that BTM had was that, once they were capable of satisfying their large corporate customers with their on-premises foreign exchange trading platforms, the small- and medium-sized enterprises (SMEs) were quite different in terms of what they required.
They needed a UI and an application that was much simpler for them to adopt. They didn't have the necessary IT infrastructure to be able to establish the complex on-premises systems. They needed something that had no IT barriers to adoption.
What we did for BTM with our partner Hitachi was to help modernize and transform the entire trading platform to the Web. Just to stress, this isn't simply an information portal, this is a fully functioning trading platform. There are over 500 screens. It's integrated to a 120 different data sources with very stringent service-level requirements to the deployment of the application.
We needed to be able to display any fluctuations and exchange right from the Reuters feed in 200 milliseconds or less. We needed to be able to complete a close loop transaction in two seconds or less.
So, this is a fully functioning trading platform. What's it's meant for BTM is that they've been able to dramatically increase the adoption and penetration into the SME market. Fundamentally, these SME or institutional traders don't need any architecture whatsoever, just a browser. There is no client installation. They're able to self-serve, which means they can simply enter the URL, log in, and get started. This has been a tremendous cost reduction and also revenue growth for this product line in penetrating this new market segment.
In the same field of foreign exchange trading, we were able to help a number of Japanese banks take their products and services global. Traditionally, the market had been very service-intensive through a call center. You dialed in and placed your trade with the trader over the phone. By being able to move this entire platform to the Web, we allowed them to go global and go 24/7.
Now, we have over 30,000 institutional traders using this trading platform and application to self-serve through operations, not just in Tokyo, but in Singapore, London, New York, Frankfurt, literally around the world.
New capabilities
Not only has it extended the product line with very little additional operational cost to the banks, but it's also allowed them to provide new capabilities to those customers. One, for example, is the ability to be able to run continuous global book.
In the traditional implementations of trading platforms, each one would be an on-premises installation, which meant that each region would actually have to close their books and close out their operations at the end of their working day. Because it's now managed and provisioned in system, it can actually run globally, and allows them to maintain those books, and maintain common alerts across entities that themselves have a global footprint.
Not only were we getting them to a new market, but we were also allowing them to introduce new functionality. It allowed them to interact more closely with the customers, providing real-time chat facilities, and allowing the traders in Japan to interact directly with a trader as they exhibited certain behavior. It allowed them to offer custom contracts and has significantly increased the close rate of those applications.
So, a big impact in terms of market reach for the banks in Japan is one example. Let's take a look here at how we've been able to dramatically improve user productivity and dramatically reduce the business process time for large organizations.
This is a representation for one of the largest telecommunications groups in Europe. The challenge that they were facing is that they had a request for proposal (RFP) process that was very complicated. They had to be able to provide quotations for countrywide mobile platforms, a very large, complex design process, which was performed through one application, one legacy application as a product configurator.
Then, they would go to another application for doing the parts costing and bill of material assessment, another application for the pricing, and finally, an overall RFP approval process for these large $100 million-plus projects running over 10 years.
The whole process was taking them anywhere up to four weeks. It was fragmented. It was error prone. There were spreadsheets, and the files were flying around the globe, trying to complete this process.
What we were able to do for this organization was to streamline the process and present it as a single-branded Web-based workflow that brought all the different elements together, and, most importantly, ran on top of a SAP NetWeaver infrastructure. In fact, the workflow was designed to have an SAP look and feel.
End users didn't know when they were in or outside of SAP. They didn't care and they didn't need to, because as an end-to-end process, SAP acts as the overall system of record, providing a much higher degree of control, accuracy, and a dramatic reduction in errors.
The great result, from a user productivity point of view, is that they've been able to go from a process that took four weeks to a process that now takes four hours or even less -- a dramatic reduction. More important was the ability to increase the accuracy of these processes.
Desktop-like experience
These Web applications, I should stress, are really a desktop-like experience for the end user. We think of them and talk about them as a desktop in a browser. Everything that you could do as a desktop application with all the user navigation and productivity in very intense data environments, you can do in a browser-based application as deployed in this solution.
Let's take another look at another example where Web architecture and rich Web interfaces allowed us to dramatically improve customer loyalty and customer engagement.
You maybe familiar with the concept of the extended enterprise, whereby more and more organizations need to be able to open up traditionally back-office processes, and back-office systems still managed on the sort of green screen UIs in the bowels of the company. In order to be able to truly engage their customers and improve the process flow, more and more of those systems are being opened up and presented to their customers through rich, engaging Web applications.
This is an example of that. This is a company in the Netherlands called Waterdrinker, which is actually the largest flower distributor in Europe, a very significant business for them. We were helping them to create a Web-based, self-service ordering process that dramatically reduces the dependency on the use of customer service reps. It was similar to the scenario for the foreign-exchange trading platform. We were actually migrating customer interaction to the self-served Web platforms without the need for human intervention and costly CSRs.
But, it's much more than that. We're providing a much richer experience for the user, a much more engaging experience for the user, where they're able to more dynamically navigate through the catalog and determine the optimal order for them with all kinds of what-if calculations and analysis that are provided for them in real time at their own discretion.
The net result has been a significant increase in customer satisfaction, engagement, loyalty, We're yet to see it, because it's still relatively new, but just based on the amount of response reaction and conversion that we have seen through these Web-based interfaces, loyalty benefits will follow soon after. In addition, with a Web-based UI, you're able to easily and effectively customize the user interface with different users and communities.
In this case, they're able to provide a custom UI solution that integrates their catalog ordering process into their partners' processes. They distribute through local partners and local Websites, and they're able to provide this architecture as a white-label capability and then brand it according to the local distributor, delivering a rich branded experience through their partner.
Let's talk generally about competitive advantage. Obviously, all those things that we have talked about and shown with regard to different customers, and Dana has talked about in aggregate, offer all kinds of competitive advantage.
But, there's a certain element to competitive advantage that I would like to emphasize in this transformation process. Organizations, through the years, have basically instantiated and codified their best practices in the workflows within those legacy systems. Those business rules represent years of intelligence and competitive intelligence, and often the point at which you can realize tremendous competitive advantage.
Razor-thin margins
This is never truer than in the razor-thin margins of the consumer packaged goods (CPG) business, where a lot of the margin for a customer can actually be determined through the appropriate inventory, logistics, and pricing management, literally as goods are on route. What we've done for customers like these is to enable them to quickly and effectively extract the business rules that are buried in the legacy systems.
Frankly, nobody knows how they work anymore. They're not really very well documented at best, but we have allowed them to extract those business rules that represent the competitive advantage and consolidate them into a set of corporate-wide rules that can be more effectively managed.
One issue in a traditional legacy environment is that, as you establish business rules in terms of the legacy implementation, each one is monolithic. They start to create their own derivatives, as people program, tweak, and modify. At the end of a 10-year process, the rules barely resemble each other in each of the iterations.
In our transformed architecture, we're able to provide an environment, in which you can centrally manage, control, and modify those business rules and have them consistently and immediately applied across all the necessary touch points. Through this process, we can dramatically reduce human error.
This architecture allows us to provide support tools and business rules in a form that's readily accessible to the end user. You might say, "Wait a minute. It's a Web-based application, and when I'm sitting face to face with my customers, I'm not going to have access to the Web."
As you would expect in these solutions, we're able to architect them, so that the same application can be deployed as a Web application, or used as standalone. A great example of that is Aflac, where we created their premium calculation solution that is basically used across all the customer touch points, 38,000 users. And, 6,000 of those are agents who go door-to-door.
Part of the architecture and part of the challenge was to deliver that insurance calculation solution in such a way that when the agent is sitting across the kitchen table from their customer, they could still perform a level of custom quotation. They could produce the necessary documentation to be able to close the customer there and then as a standalone laptop with a local printer right across the kitchen table. That's all part of bringing those business rules that represent the years of competitive advantage successfully to the Web.
Let's take a look at how some of these capabilities impact the operations themselves. Here, we'll take an example of a call-center application. This was a transformation for the Pepsi bottling group of their customer-equipment tracking system It was a PowerBuilder application, maybe 10 years old, that we successfully moved to the Web.
The real business value in this is that by doing this, by creating a Web-based environment that could be deployed in any call center, we provide the flexibility and the agility for organizations to better utilize those call centers and better utilize that real estate, often consolidating from a large number of call centers to a smaller set of agile call centers, where they can put a lot of different processes through the same infrastructure.
Cost-management advantage
This has tremendous advantages, as you can imagine, in terms of cost management for those customers. We're even able to take that to the next step with the advent of voice-based telephony. It's now possible to engage home-office operators through a voice over Internet protocol (VoIP) infrastructure.
Those operators can not only have the benefit of the call center application as a Web based application accessible through their home broadband, but actually can have the same level of computer telephony integration (CTI) that they would have had, if they sat in the call center, by virtue of a series of VoIP based CTI technology that's available.
This is offering tremendous operating improvements in terms of, for example, real-estate consolidation. Also, looking at operations and the ability to optimize the use of the workforce, we have a situation here where we deploy a very complex laboratory information-management solution for the AmeriPath, now part of Quest Diagnostics. This is part of a pathology services process that requires very experienced technicians to participate.
The joy of being able to deploy this as a Web-based application means that you get great skills mobility, which means that technicians from anywhere, provided they have Web access, can actually participate in a diagnostic process, without the need to move the sensitive Health Insurance Portability and Accountability Act (HIPAA) data. So, HIPAA data that has to be stored in one place, can be made accessible to technicians through any location who can participate then in a process 24/7.
The value to IT is manifold. We'll take a quick look at some of those before we jump into the value equation itself. This is an example with SunGard Shareholder Systems, where they wanted to modernize their commercial product line, a 401k management application. I'm sure they're pretty busy these days.
It was originally deployed as an IBM-Oracle mainframe solution with a C++ front end. We modernized it through a pure Web application, but, from an IT development point of view, the benefits of being in that Web architecture are manifold. First and foremost, they were able to manage this entire development process with one person in the US, and a whole development team offshore in India, dramatically reducing the time and cost.
In this new architecture, the ability to respond to program change requests is tremendously different. We're able to program and change requests in one-tenth of the time and, by virtue of being a Web architecture, actually deploy those in now what are weekly release cycles, instead of six-monthly cycles that you would typically see as a point solution.
As we're running a little long here, I won't go into all of these, but there are many different ways in which the modern architecture really played into creating significant additional IT value.
We provide a process we call Nexaweb Advance, which is an end-to-end transformation process that allows us to dramatically reduce the time, risk, and costs of this overall implementation. It starts with a capture phase that is able to go in and interrogate legacy systems and dramatically reduce the amount of time and effort to document the code that typically is not well documented.
Then it goes through a model transformation process that dramatically reduces the amount of actual code that has to be written. In this example, it was a 65 percent reduction in the amount of code in the three million lines of application. The net result of that is through a typical designer development cycle, we were able to realize 50 percent or more reduction in the development time.
Having done that as a Web based application, there is no kind installation, no on-site provisioning. It's all centrally managed, so dramatic reductions in operating costs recognized by customers. In the example that we shared with you a little bit earlier, where, because we're in a modern object-oriented architecture with all the inheritance benefits that that brings, we're actually able to modify and execute change requests quite often in one-tenth of the time and then deploy them immediately and effectively as Web applications.
Announcer: Thanks, Adam. With that we conclude our podcast. You have been listening to a sponsored BriefingsDirect presentation taken from a recent Nexaweb webinar on application modernization. Please find more information on these solutions at Nexaweb.com. Thanks for listening and come back next time.
Listen to the podcast. Download the podcast. Find it on iTunes/iPod and Podcast.com. Learn more. Sponsor: Nexaweb Technologies.
Transcript of a BriefingsDirect webinar with David McFarlane and Adam Markey on the economic and productivity advantages from application modernization. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
Showing posts with label guerilla soa. Show all posts
Showing posts with label guerilla soa. Show all posts
Sunday, March 22, 2009
Saturday, February 14, 2009
Effective Enterprise Security Begins and Ends With Architectural Best Practices Approach
Transcript of a podcast on security as architectural best practices, recorded at the first Security Practitioners Conference at The Open Group's 21st Enterprise Architecture Conference in San Diego, February 2009.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, we welcome our listeners to a sponsored podcast discussion coming to you from The Open Group's first Security Practitioners Conference in San Diego, the week of Feb. 2, 2009.
Our topic for this podcast, part of a series of events and coverage at this conference, centers on enterprise security and the intersection with enterprise architecture (EA). The goal is to bring a security understanding across more planning- and architectural-level activities, to make security pervasive -- and certainly not an afterthought.
The issue of security has become more important over time. As enterprises engage in more complex activities, particularly with a boundaryless environment -- which The Open Group upholds and tries to support in terms of management and planning -- security again becomes a paramount issue.
To help us understand more about security in the context of enterprise architecture, we're joined by Chenxi Wang, principal analyst for security and risk management at Forrester Research; Kristin Lovejoy, director of corporate security strategy at IBM; Nils Puhlmann, chief security officer and vice president of risk management of Qualys, and Jim Hietala, vice president of security for The Open Group.
Let's start with you, Jim. Security now intersects with more elements of what information technology (IT) does, and there are more people responsible for it. From the perspective of The Open Group, why has it been a transition or a progression in terms of bringing security into architecture? Why wasn't it always part of architecture?
Jim Hietala: That's a good question, but probably predates my involvement with The Open Group. In TOGAF 9, the latest iteration of TOGAF that we announced this week, there is a whole chapter devoted to security, trying to get to the idea of building it in upfront, as opposed to tacking it on after the fact.
You've seen movement, certainly within The Open Group, in terms of TOGAF, and our enterprise architecture groups try to make that happen. It's a constant struggle that we've had in security -- the idea that functionality precedes security, and security has to be tacked on after the fact. We end up where we are today with the kind of security threats and environment that we have.
Gardner: Chenxi, we've seen security officer emerge as a role in the past several years. Shouldn't everyone have, in a sense, the role of security officer as part of their job description?
Chenxi Wang: Everyone in the organization or every organization? My view is slightly different. I think that in the architecture group there should be somebody who is versed in security, and the security side of the house should have an active involvement in architecture design, which is what we are seeing as an emerging trend in a lot of organizations today.
Gardner: We're also facing a substantial economic downturn globally. Often, this accelerates issues around risk, change management, large numbers of people entering and leaving organizations, mergers and acquisitions, and provisioning of people off of applications and systems.
Kristin, perhaps you can give us a sense of why security might be more important in a downturn than when we were in a boom cycle?
New technologies
Kristin Lovejoy: There are a couple of things to think about. First of all, in a down economy, like we have today, a lot of organizations are adopting new technologies, such as Web 2.0, service-oriented architecture (SOA) style applications, and virtualization.
Why are they doing it? They are doing it because of the economy of scale that you can get from those technologies. The problem is that these new technologies don't necessarily have the same security constructs built in.
Take Web 2.0 and SOA-style composite applications, for example. The problem with composite applications is that, as we're building these composite applications, we don't know the source of the widget. We don't know whether these applications have been built with good secured design. In the long-term, that becomes problematic for the organizations that use them.
It's the same with virtualization. There hasn't been a lot of thought put to what it means to secure a virtual system. There are not a lot of best practices out there. There are not a lot of industry standards we can adhere to. The IT general control frameworks don't even point to what you need to do from a virtualization perspective.
In a down economy, it's not simply the fact we have to worry about privileged users and our employees, blah, blah, blah. We also have to worry about these new technologies that we're adapting to become more agile as a business.
Gardner: Nils, how do you view the intersection of what an enterprise architect needs to consider as they are planning and thinking about a more organized approach to IT and bringing security into that process?
Nils Puhlmann: Enterprise architecture is the cornerstone of making security simpler and therefore more effective. The more you can plan, simplify structures, and build in security from the get-go, the more bang you get for the buck.
It's just like building a house. If you don't think about security, you have to add it later, and that will be very expensive. If it's part of the original design, then the things you need to do to secure it at the end will be very minimal. Plus, any changes down the road will also be easier from a security point of view, because you built for it, designed for it, and most important, you're aware of what you have.
Most large enterprises today struggle even to know what architecture they have. In many cases, they don't even know what they have. The trend we see here with architecture and security moving closer together is a trend we have seen in software development as well. It was always an afterthought, and eventually somebody made a calculation and said, "This is really expensive, and we need to build it in."
Things like security and the software development lifecycle came up, and we are doing this now for architecture. Hopefully, we'll eventually do this for complex systems. Kristin mentioned Web 2.0. It's the same thing there. We have wonderful applications, and companies are moving towards Facebook en masse, but it's a small company. The question is, was security built in, has anyone vetted that, or are we not just repeating the same mistake we did so many times before?
A matter of process
Gardner: We see with security that it's not so much an issue of technology but really about process, follow through, policy determination and enforcement, and the means to do that.
Chenxi, when it comes to bringing security into a regulated provision, policy-driven process, it starts to sound like SOA. You'd have a repository, you'd have governance, and the ways in which services would be used or managed and policies applied to them. Is there actually an intersection between some of the concepts of architecture, SOA, and this larger strategic approach to security?
Wang: There is definitely some intersection. If you look at classic SOA architecture, there is a certain interface, and you can specify what the API is like. If you think about a virtual approach to security, it's also a set of policies you need to specify upfront, hopefully, and then a set of procedures in which you adhere to these policies.
It's very much like understanding the API and the parameters that go into using these APIs. I hadn't actually thought about this really nicely laid out analogy, Dana, but I think that's a quite good one.
Gardner: I think we're talking about lifecycles and managing lifecycles and services. I keep seeing more solutions, shared services, and then actual business and IT services, all being managed in a similar way nowadays with repository and architecture.
Jim, this is your first security conference at The Open Group. It's also coinciding with a cloud computing conference. Is there an element now, with the "boundarylessness" of organizations and what your architectures have tried to provide in terms of managing those permeable boundaries and this added layer, or a model for the cloud? More succinctly, how do the cloud and security come together?
Hietala: That's one of the things we hope to figure out this week. There's a whole set of security issues related to cloud computing -- things like compliance regulation, for example. If you're an organization that is subject to things like the payment card industry data security standard (PCI DSS) or some of the banking regulations in the United States, are there certain applications and certain kinds of data that you will be able to put in a cloud? Maybe. Are there ones that you probably can't put in the cloud today, because you can't get visibility into the control environment that the cloud service provider has? Probably.
There's a whole set of issues related to security compliance and risk management that have to do with cloud services. The session this week with a number of cloud service providers, we think, will bring a lot of those questions to the surface.
Gardner: Clearly, those on the naysaying side of the cloud argument often have a problem with the data leaving their premises. As we've heard from other speakers at the conference, having data or transactions that are separate from your organization or that happen at someone else's data center is actually quite common, and is sort of a cultural shift in thinking.
Nils, what do you think needs to happen from this cultural perspective in order for people to feel secure about using cloud models?
A shift in thinking
Puhlmann: We need to shift the way we think about cloud computing. There is a lot of fear out there. It reminds me of 10 years back, when we talked about remote access into companies, VPN, and things like that. People were very fearful and said, "No way. We won't allow this." Now is the time for us to think about cloud computing. If it's done right and by a provider doing all the right things around security, would it be better or worse than it is today?
I'd argue it would be better, because you deal with somebody whose business relies on doing the right thing, versus a lot of processes and a lot of system issues. A lot of corporations today are understaffed, or there is a lot of transition, and a lot of changes there. Simply, things are not in order or not the way they should or could be.
Then, we have the data issue. Let's face it, we already outsource so much work to other places. If ever my data is in a certain place, where I have audited and vetted that provider, or somebody from a remote country as a DBA is accessing my data in-house, is there really a difference when it comes to risk? In my mind, not really, because if you do both well, then it's a good thing.
There's too much fear going into this, and hopefully the security community will have learned from the past and will do a good job in addressing what we don't have today, like best practices, and how vendors and customers strive for that.
Gardner: Kristin, I read a quote recently where someone said that the person or persons that manage the firewall are the most important people in the IT organization. Given what we are dealing with in terms of security, and also trying to bail ourselves of some of these hybrid models, do you agree with that, and if so, why?
Lovejoy: That's a leading question. Is the firewall administrator important? Obviously, yes. More important than ever. In a world with no boundaries, it becomes very hard to suggest that that is accurate.
What we're seeing from a macro perspective is that the IT function within large enterprises is changing. It's undergoing this radical transformation, where the CSO/CISO is becoming a consultant to the business. The CSO/CISO is recognizing, from an operational risk perspective, what could potentially happen to the business, then designing the policies, the processes, and the architectural principles that need to be baked in, pushing them into the operational organization.
From an IT perspective, it's the individuals who are managing the software development release process, the people that are managing the changing configuration management process. Those are the guys that really now hold the keys to the kingdom, so to speak.
Particularly when you are talking about enterprise cloud, they become even more important, because you have to recognize -- and Nils was mentioning this or inferred this -- that cloud provides a vision of simplicity. If you think about cloud and the way it's architected, a cloud could be much simpler than the traditional enterprise. If you think about who's managing that change and managing those systems, it becomes those folks that are key.
Gardner: Why is the cloud simpler? Is it because you're dealing now at a services and API level and you're not concerned necessarily with the rest of the equation?
Lovejoy: That's correct.
Gardner: Is that good for security or bad?
Aligning security and operations
Lovejoy: We've been dancing around the subject, but my hope is that security and operations become much more aligned. It's hard to distinguish today between operations and security. So many of the functions overlap. I'll ask you again, changing configuration management, software development and release, why is that not security? From my perspective, I'd like to see those two functions melding.
Gardner: So, security concerns and approaches and best practices really need to be pervasive throughout IT?
Lovejoy: Exactly. They need to come from the top, they need to move to the bottom, and they need to be risk based.
Gardner: Now, when it comes to the economics behind making security more pervasive, the return on investment (ROI) for security is one of the easier stories. Not being secure is very expensive. Being publicly not secure is even more expensive. Let's go back to Chenxi, the economics of security, isn't this something that people should get easy funding for in an IT organization?
Wang: The economics of security. This issue has been in research for a long time. Ross Anderson, who is a professor at University of Cambridge, runs this economics of security workshop since 1996, or something like that. There is some very interesting research coming out of that workshop, and people have done case studies. But, I'm not sure how much of that has been adopted in practice.
I've yet to find an organization that takes a very extensive economics-based approach to security, but what Kristin said earlier and what you just said is happening. We're seeing the IT security team in many organizations now have a somewhat diminished role, in the sense that some of the traditional security tasks are now moving into IT operations or moving into risk and compliance.
We're even seeing that security teams sometimes have dotted reporting responsibility to the legal team. Some of the functions are moving out of the security team, but at the same time, IT security now has an expanded impact on the entire organization, which is the positive direction.
Gardner: If there is a relationship between doing your architecture well, making systemic security, thought, vision, and implementation part and parcel with how you do IT, then it seems to me that the ROI for security becomes a very strong rationale for good architecture. Would you agree with that, Jim?
Hietala: I would. Organizations want, at all costs, to avoid plowing ahead with architectures, not considering security upfront, and dealing with the consequence of that. You could probably point to some of the recent breaches and draw the conclusion that maybe that's what happened. So, I would agree with that statement.
Gardner: We did have quite a few high profile breaches, and of course, we're seeing a lot more activity in the financial sector. Actually, we could fairly call it a restructuring of the entire financial sector. Do you expect to see more of these high-profile breaches and issues in 2009?
Same song - second verse
Hietala: I'll be interested to hear everyone else's opinion on this as well, but my perspective would be yes. It's been interesting to me that 2009 has started out with what I would call "same song, second verse." We've had a massive worm that propagated through a number of means, but one of which is removable storage media. That takes me back to 1986 or 1988, when viruses propagated through floppy disk.
We've had the Heartland breach, which may be as many as 100 million credit cards exposed. Those kinds of things, unfortunately, are going to be with us for some time.
Gardner: Let's get the perspective of others. Kristin, is this going to be a very bad year for security?
Lovejoy: The more states that pass privacy disclosure requirements that mandate that you actually disclose a breach, the more we're going to hear. Does this mean that there haven't always been breaches? There have always been breaches, but we just haven't been talking about them. They're becoming much more public today.
Do I see a trend, where there are employees terminated or worried employees who are perpetrating harm on the business? The answer is yes. That is becoming a much more of an issue.
The second issue that we're seeing, and this is one of those quasi-security, quasi-operational issues, is that, because of the resource restrictions within organizations today, people are so resource starved, particularly around the changing configuration management process.
We're beginning to see where there are critical outages, particularly in infrastructure systems like those associated with nuclear power and heavy industry, where the folks are making changes outside the change process simply because they are so overloaded. They're not necessarily following policy. They're not necessarily following process.
So, we are seeing outages associated with individuals who are simply doing a job that they are ill-informed to do or overwhelmed and not able to do it effectively.
Gardner: Or perhaps cutting corners as a result of a number of other diminished resources.
Lovejoy: That's exactly right.
Gardner: Nils, do you have any recommendations for how to come into 2009 and not fall into some of these pitfalls, if you are an enterprise and you are looking at your security risk portfolio?
Security part of quality
Puhlmann: Security to me is always a part of quality. When the quality falls down in IT operations, you normally see security issues popping up. We have to realize that the malicious potential and the effort put in by some of the groups behind these recent breaches are going up. It has to do with resources becoming cheaper, with the knowledge being freely available in the market. This is now on a large scale.
In order to keep up with this we need at least minimum best practices. Somebody mentioned earlier, the worm outbreak, which really was enabled by a vulnerability that was quite old. That just points out that a lot of companies are not doing what they could do easily.
I'm not talking about the tip of the iceberg. I'm talking about the middle. As Kristin said, we've got to pay attention to these things and we need to make sure that people are trained and the resources are there at least to keep the minimum security within the company.
Gardner: As we pointed out a little earlier, security isn't necessarily an upfront capital cost. You don't download and install security. It's process and organizational and management centric. It sounds like you simply need a level of discipline, which isn't necessarily expensive, but requires intent.
Puhlmann: Yes, and that is actually similar to architecture. Architecture also is discipline. You need to sit down early and plan, and it's the same for security. A lot of things, a lot of low hanging fruit, you can do without expensive technology. It's policies, process, just assigning responsibility, and also changing security so it's a service of a business.
The business has no interest in either a breach or anything that would negatively affect the outcome of a business, for example, business continuity.
We talked earlier about how IT security might change. My feeling is that security will more and more become a partner of the business and help the business achieve its goals. At some point, nobody will talk about ROI anymore, because it's just something that will be planned in.
Gardner: Jim, what about this issue of intent? Is this something that we can bring into the architectural framework, elevate the need, and focus on intent for security?
Hietala: I believe so. Most system architects are going to be looking at trying to do the right things with respect to security and to ensure that it's thought about upfront, not later on in the cycle.
Gardner: Chenxi, in the market among suppliers that are focused on security, how are they adapting to 2009, which many of us expect to be a difficult year? We mentioned that it's about intent, but there are also products and technologies. Is there any top-of-mind importance from your perspective?
Slight increase in spending
Wang: We haven't seen a severe cut of IT security budget yet from organizations we surveyed, perhaps because some of those budgets were set before the economic downturn happened.
For some of them, we actually saw a slight increase, because just as Lehman Brothers is now Barclays, you have to merge the two IT systems. Now, you have to spend money on merging the two systems, as well as security. So, there is some actually increase in budget due to the economic situation.
A lot of vendors are taking advantages of that, and we are seeing an increased marketing effort on helping to meet security regulations and compliance. Most of us anticipate an increase of regulatory pressure coming down the pipeline, maybe in 2009, maybe in 2010. My belief is that we'll see a little bit more security spending there, because of the increased regulatory pressure.
Gardner: Kristin, we've discussed process and architecture, but are there any particular technologies that you think will be prominent in the coming year or two?
Lovejoy: Interestingly enough, identity and access management (IAM) is likely to be one of the more significant acquisitions that most businesses make.
This goes back to the business value point of security that we have been making, if you think about what's happening in the world with all of these folks wanting to access the network via smart devices. How are they going to do that? Well, they are going to do that using some sort of authentication mechanism that allows them to securely connect back.
Most organizations want to be able to access the new customer, the new consumer, via smart devices. They want to be able to allow their employees access to the network via smart devices or via any kind of other mobile device, which allows them to do things like telecommute.
IAM, as an example, is a technology that enables the business to offer a service to the employee or to that new consumer. What we're seeing is that organizations are purchasing IAM, not necessarily for security, but for the delivery of a secure service. That's one area where we are seeing uplift.
Gardner: Let's just unpack that a little bit. How is this is different from directory provisioning or some of the traditional approaches? These folks wouldn't be in the directories at that point?
Identity managements
Lovejoy: What we're seeing is much more of a focus on federated identity management and single sign-on. In fact, we're beginning to see this trend in our customer base, and a lot of organizations have been talking about this issue of mobile endpoint management. It's very hard in the new world to secure these mobile devices. What organizations are saying to us is, "Why can't we just use single sign-on and federated identity management?"
Single sign-on, in particular, has the capacity, if you think about it in the right way, to uncouple the device from the individual who is using the device, define the policy, apply the policy to the role, and then based on the role, secure the endpoint or isolate the endpoint. It's a very interesting way in which organizations are beginning to think about how they can use this technology as an alternative to traditional secure mobile endpoint management.
Gardner: It also sounds, while pertinent to mobile, that they would have a role in cloud or hybrid boundaryless types of activities.
Lovejoy: That's absolutely correct.
Gardner: Does anyone have anything to offer on this IAM in the cloud.
Puhlmann: Kristin is right. We've tried IAM for many years, and there have been many expensive failed projects in large corporations. Perhaps, we need the cloud to give us this little push to really solve it once and for all in a very federated model. I'd very much like to see that. Based on past experience, though, I'm a little cautious how quickly it will happen.
I think what we will see is a simplification of security, because it has gotten to a point where it's just too complex to handle with too many moving parts, and that makes it hard to work with and also expensive.
Also, we'll see a more realistic approach to security. What really matters? Do we really need to secure everything, or do we need to focus on certain types of data, and where is that really? Do we have to close off every little door, or can we leave some doors open and go closer to where our assets are. How much do they really mean to us?
Gardner: Great. We've been discussing security and some of the pressures of the modern age, this particular economic downturn period, but also in the context of process and architecture.
I want to thank our panelists. We were joined by Chenxi Wang, principal analyst for security and risk management at Forrester Research; Kristin Lovejoy, director of corporate security strategy at IBM; Nils Puhlmann, chief security officer and vice president of risk management of Qualys, and Jim Hietala, vice president of security for The Open Group.
Thanks to you all. Our conversation comes to you through the support of The Open Group, from the first Security Practitioners Conference here in San Diego in February, 2009.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Transcript of a podcast on security as architectural best practices, recorded at the first Security Practitioners Conference at The Open Group's 21st Enterprise Architecture Conference in San Diego, February 2009. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
View more podcasts and resources from The Open Group's recent conferences and TOGAF 9 launch:
The Open Group's CEO Allen Brown interview
Live panel discussion on enterprise architecture trends
Deep dive into TOGAF 9 use benefits
Reporting on the TOGAF 9 launch
Panel discussion on cloud computing and enterprise architecture
Access the conference proceedings
General TOGAF 9 information
Introduction to TOGAF 9 whitepaper
Whitepaper on migrating from TOGAF 8.1.1 to version 9
TOGAF 9 certification information
TOGAF 9 Commercial Licensing program information
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, we welcome our listeners to a sponsored podcast discussion coming to you from The Open Group's first Security Practitioners Conference in San Diego, the week of Feb. 2, 2009.
Our topic for this podcast, part of a series of events and coverage at this conference, centers on enterprise security and the intersection with enterprise architecture (EA). The goal is to bring a security understanding across more planning- and architectural-level activities, to make security pervasive -- and certainly not an afterthought.
The issue of security has become more important over time. As enterprises engage in more complex activities, particularly with a boundaryless environment -- which The Open Group upholds and tries to support in terms of management and planning -- security again becomes a paramount issue.
To help us understand more about security in the context of enterprise architecture, we're joined by Chenxi Wang, principal analyst for security and risk management at Forrester Research; Kristin Lovejoy, director of corporate security strategy at IBM; Nils Puhlmann, chief security officer and vice president of risk management of Qualys, and Jim Hietala, vice president of security for The Open Group.
Let's start with you, Jim. Security now intersects with more elements of what information technology (IT) does, and there are more people responsible for it. From the perspective of The Open Group, why has it been a transition or a progression in terms of bringing security into architecture? Why wasn't it always part of architecture?
Jim Hietala: That's a good question, but probably predates my involvement with The Open Group. In TOGAF 9, the latest iteration of TOGAF that we announced this week, there is a whole chapter devoted to security, trying to get to the idea of building it in upfront, as opposed to tacking it on after the fact.
You've seen movement, certainly within The Open Group, in terms of TOGAF, and our enterprise architecture groups try to make that happen. It's a constant struggle that we've had in security -- the idea that functionality precedes security, and security has to be tacked on after the fact. We end up where we are today with the kind of security threats and environment that we have.
Gardner: Chenxi, we've seen security officer emerge as a role in the past several years. Shouldn't everyone have, in a sense, the role of security officer as part of their job description?
Chenxi Wang: Everyone in the organization or every organization? My view is slightly different. I think that in the architecture group there should be somebody who is versed in security, and the security side of the house should have an active involvement in architecture design, which is what we are seeing as an emerging trend in a lot of organizations today.
Gardner: We're also facing a substantial economic downturn globally. Often, this accelerates issues around risk, change management, large numbers of people entering and leaving organizations, mergers and acquisitions, and provisioning of people off of applications and systems.
Kristin, perhaps you can give us a sense of why security might be more important in a downturn than when we were in a boom cycle?
New technologies
Kristin Lovejoy: There are a couple of things to think about. First of all, in a down economy, like we have today, a lot of organizations are adopting new technologies, such as Web 2.0, service-oriented architecture (SOA) style applications, and virtualization.
Why are they doing it? They are doing it because of the economy of scale that you can get from those technologies. The problem is that these new technologies don't necessarily have the same security constructs built in.
Take Web 2.0 and SOA-style composite applications, for example. The problem with composite applications is that, as we're building these composite applications, we don't know the source of the widget. We don't know whether these applications have been built with good secured design. In the long-term, that becomes problematic for the organizations that use them.
It's the same with virtualization. There hasn't been a lot of thought put to what it means to secure a virtual system. There are not a lot of best practices out there. There are not a lot of industry standards we can adhere to. The IT general control frameworks don't even point to what you need to do from a virtualization perspective.
In a down economy, it's not simply the fact we have to worry about privileged users and our employees, blah, blah, blah. We also have to worry about these new technologies that we're adapting to become more agile as a business.
Gardner: Nils, how do you view the intersection of what an enterprise architect needs to consider as they are planning and thinking about a more organized approach to IT and bringing security into that process?
Nils Puhlmann: Enterprise architecture is the cornerstone of making security simpler and therefore more effective. The more you can plan, simplify structures, and build in security from the get-go, the more bang you get for the buck.
It's just like building a house. If you don't think about security, you have to add it later, and that will be very expensive. If it's part of the original design, then the things you need to do to secure it at the end will be very minimal. Plus, any changes down the road will also be easier from a security point of view, because you built for it, designed for it, and most important, you're aware of what you have.
Most large enterprises today struggle even to know what architecture they have. In many cases, they don't even know what they have. The trend we see here with architecture and security moving closer together is a trend we have seen in software development as well. It was always an afterthought, and eventually somebody made a calculation and said, "This is really expensive, and we need to build it in."
Things like security and the software development lifecycle came up, and we are doing this now for architecture. Hopefully, we'll eventually do this for complex systems. Kristin mentioned Web 2.0. It's the same thing there. We have wonderful applications, and companies are moving towards Facebook en masse, but it's a small company. The question is, was security built in, has anyone vetted that, or are we not just repeating the same mistake we did so many times before?
A matter of process
Gardner: We see with security that it's not so much an issue of technology but really about process, follow through, policy determination and enforcement, and the means to do that.
Chenxi, when it comes to bringing security into a regulated provision, policy-driven process, it starts to sound like SOA. You'd have a repository, you'd have governance, and the ways in which services would be used or managed and policies applied to them. Is there actually an intersection between some of the concepts of architecture, SOA, and this larger strategic approach to security?
Wang: There is definitely some intersection. If you look at classic SOA architecture, there is a certain interface, and you can specify what the API is like. If you think about a virtual approach to security, it's also a set of policies you need to specify upfront, hopefully, and then a set of procedures in which you adhere to these policies.
It's very much like understanding the API and the parameters that go into using these APIs. I hadn't actually thought about this really nicely laid out analogy, Dana, but I think that's a quite good one.
Gardner: I think we're talking about lifecycles and managing lifecycles and services. I keep seeing more solutions, shared services, and then actual business and IT services, all being managed in a similar way nowadays with repository and architecture.
Jim, this is your first security conference at The Open Group. It's also coinciding with a cloud computing conference. Is there an element now, with the "boundarylessness" of organizations and what your architectures have tried to provide in terms of managing those permeable boundaries and this added layer, or a model for the cloud? More succinctly, how do the cloud and security come together?
Hietala: That's one of the things we hope to figure out this week. There's a whole set of security issues related to cloud computing -- things like compliance regulation, for example. If you're an organization that is subject to things like the payment card industry data security standard (PCI DSS) or some of the banking regulations in the United States, are there certain applications and certain kinds of data that you will be able to put in a cloud? Maybe. Are there ones that you probably can't put in the cloud today, because you can't get visibility into the control environment that the cloud service provider has? Probably.
There's a whole set of issues related to security compliance and risk management that have to do with cloud services. The session this week with a number of cloud service providers, we think, will bring a lot of those questions to the surface.
Gardner: Clearly, those on the naysaying side of the cloud argument often have a problem with the data leaving their premises. As we've heard from other speakers at the conference, having data or transactions that are separate from your organization or that happen at someone else's data center is actually quite common, and is sort of a cultural shift in thinking.
Nils, what do you think needs to happen from this cultural perspective in order for people to feel secure about using cloud models?
A shift in thinking
Puhlmann: We need to shift the way we think about cloud computing. There is a lot of fear out there. It reminds me of 10 years back, when we talked about remote access into companies, VPN, and things like that. People were very fearful and said, "No way. We won't allow this." Now is the time for us to think about cloud computing. If it's done right and by a provider doing all the right things around security, would it be better or worse than it is today?
I'd argue it would be better, because you deal with somebody whose business relies on doing the right thing, versus a lot of processes and a lot of system issues. A lot of corporations today are understaffed, or there is a lot of transition, and a lot of changes there. Simply, things are not in order or not the way they should or could be.
Then, we have the data issue. Let's face it, we already outsource so much work to other places. If ever my data is in a certain place, where I have audited and vetted that provider, or somebody from a remote country as a DBA is accessing my data in-house, is there really a difference when it comes to risk? In my mind, not really, because if you do both well, then it's a good thing.
There's too much fear going into this, and hopefully the security community will have learned from the past and will do a good job in addressing what we don't have today, like best practices, and how vendors and customers strive for that.
Gardner: Kristin, I read a quote recently where someone said that the person or persons that manage the firewall are the most important people in the IT organization. Given what we are dealing with in terms of security, and also trying to bail ourselves of some of these hybrid models, do you agree with that, and if so, why?
Lovejoy: That's a leading question. Is the firewall administrator important? Obviously, yes. More important than ever. In a world with no boundaries, it becomes very hard to suggest that that is accurate.
What we're seeing from a macro perspective is that the IT function within large enterprises is changing. It's undergoing this radical transformation, where the CSO/CISO is becoming a consultant to the business. The CSO/CISO is recognizing, from an operational risk perspective, what could potentially happen to the business, then designing the policies, the processes, and the architectural principles that need to be baked in, pushing them into the operational organization.
From an IT perspective, it's the individuals who are managing the software development release process, the people that are managing the changing configuration management process. Those are the guys that really now hold the keys to the kingdom, so to speak.
Particularly when you are talking about enterprise cloud, they become even more important, because you have to recognize -- and Nils was mentioning this or inferred this -- that cloud provides a vision of simplicity. If you think about cloud and the way it's architected, a cloud could be much simpler than the traditional enterprise. If you think about who's managing that change and managing those systems, it becomes those folks that are key.
Gardner: Why is the cloud simpler? Is it because you're dealing now at a services and API level and you're not concerned necessarily with the rest of the equation?
Lovejoy: That's correct.
Gardner: Is that good for security or bad?
Aligning security and operations
Lovejoy: We've been dancing around the subject, but my hope is that security and operations become much more aligned. It's hard to distinguish today between operations and security. So many of the functions overlap. I'll ask you again, changing configuration management, software development and release, why is that not security? From my perspective, I'd like to see those two functions melding.
Gardner: So, security concerns and approaches and best practices really need to be pervasive throughout IT?
Lovejoy: Exactly. They need to come from the top, they need to move to the bottom, and they need to be risk based.
Gardner: Now, when it comes to the economics behind making security more pervasive, the return on investment (ROI) for security is one of the easier stories. Not being secure is very expensive. Being publicly not secure is even more expensive. Let's go back to Chenxi, the economics of security, isn't this something that people should get easy funding for in an IT organization?
Wang: The economics of security. This issue has been in research for a long time. Ross Anderson, who is a professor at University of Cambridge, runs this economics of security workshop since 1996, or something like that. There is some very interesting research coming out of that workshop, and people have done case studies. But, I'm not sure how much of that has been adopted in practice.
I've yet to find an organization that takes a very extensive economics-based approach to security, but what Kristin said earlier and what you just said is happening. We're seeing the IT security team in many organizations now have a somewhat diminished role, in the sense that some of the traditional security tasks are now moving into IT operations or moving into risk and compliance.
We're even seeing that security teams sometimes have dotted reporting responsibility to the legal team. Some of the functions are moving out of the security team, but at the same time, IT security now has an expanded impact on the entire organization, which is the positive direction.
Gardner: If there is a relationship between doing your architecture well, making systemic security, thought, vision, and implementation part and parcel with how you do IT, then it seems to me that the ROI for security becomes a very strong rationale for good architecture. Would you agree with that, Jim?
Hietala: I would. Organizations want, at all costs, to avoid plowing ahead with architectures, not considering security upfront, and dealing with the consequence of that. You could probably point to some of the recent breaches and draw the conclusion that maybe that's what happened. So, I would agree with that statement.
Gardner: We did have quite a few high profile breaches, and of course, we're seeing a lot more activity in the financial sector. Actually, we could fairly call it a restructuring of the entire financial sector. Do you expect to see more of these high-profile breaches and issues in 2009?
Same song - second verse
Hietala: I'll be interested to hear everyone else's opinion on this as well, but my perspective would be yes. It's been interesting to me that 2009 has started out with what I would call "same song, second verse." We've had a massive worm that propagated through a number of means, but one of which is removable storage media. That takes me back to 1986 or 1988, when viruses propagated through floppy disk.
We've had the Heartland breach, which may be as many as 100 million credit cards exposed. Those kinds of things, unfortunately, are going to be with us for some time.
Gardner: Let's get the perspective of others. Kristin, is this going to be a very bad year for security?
Lovejoy: The more states that pass privacy disclosure requirements that mandate that you actually disclose a breach, the more we're going to hear. Does this mean that there haven't always been breaches? There have always been breaches, but we just haven't been talking about them. They're becoming much more public today.
Do I see a trend, where there are employees terminated or worried employees who are perpetrating harm on the business? The answer is yes. That is becoming a much more of an issue.
The second issue that we're seeing, and this is one of those quasi-security, quasi-operational issues, is that, because of the resource restrictions within organizations today, people are so resource starved, particularly around the changing configuration management process.
We're beginning to see where there are critical outages, particularly in infrastructure systems like those associated with nuclear power and heavy industry, where the folks are making changes outside the change process simply because they are so overloaded. They're not necessarily following policy. They're not necessarily following process.
So, we are seeing outages associated with individuals who are simply doing a job that they are ill-informed to do or overwhelmed and not able to do it effectively.
Gardner: Or perhaps cutting corners as a result of a number of other diminished resources.
Lovejoy: That's exactly right.
Gardner: Nils, do you have any recommendations for how to come into 2009 and not fall into some of these pitfalls, if you are an enterprise and you are looking at your security risk portfolio?
Security part of quality
Puhlmann: Security to me is always a part of quality. When the quality falls down in IT operations, you normally see security issues popping up. We have to realize that the malicious potential and the effort put in by some of the groups behind these recent breaches are going up. It has to do with resources becoming cheaper, with the knowledge being freely available in the market. This is now on a large scale.
In order to keep up with this we need at least minimum best practices. Somebody mentioned earlier, the worm outbreak, which really was enabled by a vulnerability that was quite old. That just points out that a lot of companies are not doing what they could do easily.
I'm not talking about the tip of the iceberg. I'm talking about the middle. As Kristin said, we've got to pay attention to these things and we need to make sure that people are trained and the resources are there at least to keep the minimum security within the company.
Gardner: As we pointed out a little earlier, security isn't necessarily an upfront capital cost. You don't download and install security. It's process and organizational and management centric. It sounds like you simply need a level of discipline, which isn't necessarily expensive, but requires intent.
Puhlmann: Yes, and that is actually similar to architecture. Architecture also is discipline. You need to sit down early and plan, and it's the same for security. A lot of things, a lot of low hanging fruit, you can do without expensive technology. It's policies, process, just assigning responsibility, and also changing security so it's a service of a business.
The business has no interest in either a breach or anything that would negatively affect the outcome of a business, for example, business continuity.
We talked earlier about how IT security might change. My feeling is that security will more and more become a partner of the business and help the business achieve its goals. At some point, nobody will talk about ROI anymore, because it's just something that will be planned in.
Gardner: Jim, what about this issue of intent? Is this something that we can bring into the architectural framework, elevate the need, and focus on intent for security?
Hietala: I believe so. Most system architects are going to be looking at trying to do the right things with respect to security and to ensure that it's thought about upfront, not later on in the cycle.
Gardner: Chenxi, in the market among suppliers that are focused on security, how are they adapting to 2009, which many of us expect to be a difficult year? We mentioned that it's about intent, but there are also products and technologies. Is there any top-of-mind importance from your perspective?
Slight increase in spending
Wang: We haven't seen a severe cut of IT security budget yet from organizations we surveyed, perhaps because some of those budgets were set before the economic downturn happened.
For some of them, we actually saw a slight increase, because just as Lehman Brothers is now Barclays, you have to merge the two IT systems. Now, you have to spend money on merging the two systems, as well as security. So, there is some actually increase in budget due to the economic situation.
A lot of vendors are taking advantages of that, and we are seeing an increased marketing effort on helping to meet security regulations and compliance. Most of us anticipate an increase of regulatory pressure coming down the pipeline, maybe in 2009, maybe in 2010. My belief is that we'll see a little bit more security spending there, because of the increased regulatory pressure.
Gardner: Kristin, we've discussed process and architecture, but are there any particular technologies that you think will be prominent in the coming year or two?
Lovejoy: Interestingly enough, identity and access management (IAM) is likely to be one of the more significant acquisitions that most businesses make.
This goes back to the business value point of security that we have been making, if you think about what's happening in the world with all of these folks wanting to access the network via smart devices. How are they going to do that? Well, they are going to do that using some sort of authentication mechanism that allows them to securely connect back.
Most organizations want to be able to access the new customer, the new consumer, via smart devices. They want to be able to allow their employees access to the network via smart devices or via any kind of other mobile device, which allows them to do things like telecommute.
IAM, as an example, is a technology that enables the business to offer a service to the employee or to that new consumer. What we're seeing is that organizations are purchasing IAM, not necessarily for security, but for the delivery of a secure service. That's one area where we are seeing uplift.
Gardner: Let's just unpack that a little bit. How is this is different from directory provisioning or some of the traditional approaches? These folks wouldn't be in the directories at that point?
Identity managements
Lovejoy: What we're seeing is much more of a focus on federated identity management and single sign-on. In fact, we're beginning to see this trend in our customer base, and a lot of organizations have been talking about this issue of mobile endpoint management. It's very hard in the new world to secure these mobile devices. What organizations are saying to us is, "Why can't we just use single sign-on and federated identity management?"
Single sign-on, in particular, has the capacity, if you think about it in the right way, to uncouple the device from the individual who is using the device, define the policy, apply the policy to the role, and then based on the role, secure the endpoint or isolate the endpoint. It's a very interesting way in which organizations are beginning to think about how they can use this technology as an alternative to traditional secure mobile endpoint management.
Gardner: It also sounds, while pertinent to mobile, that they would have a role in cloud or hybrid boundaryless types of activities.
Lovejoy: That's absolutely correct.
Gardner: Does anyone have anything to offer on this IAM in the cloud.
Puhlmann: Kristin is right. We've tried IAM for many years, and there have been many expensive failed projects in large corporations. Perhaps, we need the cloud to give us this little push to really solve it once and for all in a very federated model. I'd very much like to see that. Based on past experience, though, I'm a little cautious how quickly it will happen.
I think what we will see is a simplification of security, because it has gotten to a point where it's just too complex to handle with too many moving parts, and that makes it hard to work with and also expensive.
Also, we'll see a more realistic approach to security. What really matters? Do we really need to secure everything, or do we need to focus on certain types of data, and where is that really? Do we have to close off every little door, or can we leave some doors open and go closer to where our assets are. How much do they really mean to us?
Gardner: Great. We've been discussing security and some of the pressures of the modern age, this particular economic downturn period, but also in the context of process and architecture.
I want to thank our panelists. We were joined by Chenxi Wang, principal analyst for security and risk management at Forrester Research; Kristin Lovejoy, director of corporate security strategy at IBM; Nils Puhlmann, chief security officer and vice president of risk management of Qualys, and Jim Hietala, vice president of security for The Open Group.
Thanks to you all. Our conversation comes to you through the support of The Open Group, from the first Security Practitioners Conference here in San Diego in February, 2009.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Transcript of a podcast on security as architectural best practices, recorded at the first Security Practitioners Conference at The Open Group's 21st Enterprise Architecture Conference in San Diego, February 2009. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
View more podcasts and resources from The Open Group's recent conferences and TOGAF 9 launch:
The Open Group's CEO Allen Brown interview
Live panel discussion on enterprise architecture trends
Deep dive into TOGAF 9 use benefits
Reporting on the TOGAF 9 launch
Panel discussion on cloud computing and enterprise architecture
Access the conference proceedings
General TOGAF 9 information
Introduction to TOGAF 9 whitepaper
Whitepaper on migrating from TOGAF 8.1.1 to version 9
TOGAF 9 certification information
TOGAF 9 Commercial Licensing program information
Friday, November 14, 2008
Interview: rPath’s Billy Marshall on How Enterprises Can Follow a Practical Path to Virtualized Applications
Transcript of BriefingsDirect podcast on virtualized applications development and deployment strategies as on-ramp to cloud computing.
Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: rPath.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.
Today, we present a sponsored podcast discussion on proper on-ramps to cloud computing, and how enterprises can best prepare to bring applications into a virtual development and deployment environment.
While much has been said about cloud computing in 2008, the use of virtualization is ramping up rapidly. Moreover, enterprises are moving from infrastructure virtualization to application-level virtualization.
We're going to look at how definition and enforcement of policies helps ensure conformance and consistency for virtual applications across their lifecycle. Managing virtualized applications holistically is an essential ingredient in making cloud-computing approaches as productive as possible while avoiding risk and onerous complexity.
To provide the full story on virtual applications lifecycle, methods and benefits, I'm joined by Billy Marshall, the founder of rPath, as well as their chief strategy officer. Welcome to the show, Billy.
Billy Marshall: Thanks, Dana, great to be here.
Gardner: There is a great deal going on with technology trends, the ramp up of virtualization, cloud computing, services-oriented architecture (SOA), use of new tools, light-weight development environments, and so forth. We're also faced unfortunately with a tough economic climate, as a global recession appears to be developing.
What’s been interesting for me is that this whole technological trend-shift and this economic imperative really form a catalyst to a transformative IT phase that we are entering. That is to say, the opportunity to do more with less is really right on the top of the list for IT decision-makers and architects.
Tell me, if you would, how some of these technology benefits and the need to heighten productivity fit and come together.
Marshall: Dana, we've seen this before, and specifically I have seen it before. I inherited the North America sales role at Red Hat in April of 2001, and of course shortly thereafter, in September of 2001, we had the terrible 9/11 situation that changed a lot of the thinking.
The dot-com bubble burst, and it turned out to be a catalyst for driving Linux into a lot of enterprises that previously weren't thinking about it before. They began to question their assumptions about how much they were willing to pay for certain types of technologies, and in this case it happened to be the Unix technology. In most cases they were buying from Sun and that became subject of a great deal of scrutiny. Much of it was replaced in the period from 2001to 2003 and into 2004 with Linux technology.
We're once again facing a similar situation now, where people, enterprises specifically, are taking a very tough look at their data center expenditures and expansions that they're planning for the data center. I don't think there's any doubt in people's mind that they are getting good value out of doing things with IT, and a lot of these businesses are driven by information technology.
At the same time, this credit crunch is going to have folks look very hard at large-scale outlays of capital for data centers. I believe that will be a catalyst for folks to consider a variable-cost approach to using infrastructures or service, perhaps platform as a service (PaaS). All these things roll up under the notion of cloud, as it relates to being able to get it when you need it, get it at variable cost, and get it on demand.
Gardner: Obviously, there's a tremendous amount of economic value to be had in cloud computing, but some significant risks as well. As we look at how virtualization increases utilization of servers and provide the dynamic ability to fire up platform and instances of run-time and actual applications with a stack beneath them, it really allows companies to increase their applications with a lower capital expenditure upfront and also cut their operating costs. Then, we can have administrators and architects managing many more applications, if it's automated and governed properly. So let's get into this notion of doing it right.
When we have more and more applications and services, there is, on one side, a complexity problem. There is also this huge utilization benefit. What's the first step in getting this right in terms of a lifecycle and a governance mentality?
Marshall: Let's talk first about why utilization was a problem without virtualization. Let's talk about old architecture for a minute, and then we can talk about, what might be the benefits of a new architecture if done correctly.
Historically, in the enterprise you would get somewhere between 15 and 18 percent utilization for server applications. So, there are lots of cycles available on a machine and you may have two machines running side-by-side, running two very different workloads, whose cycles are very different. Yet, people wouldn't run multiple applications on the same server setup in most cases, because of the lack of isolation when you are sharing processes in the operating system on the server. Very often, these things would conflict with one another.
During maintenance, maintenance required for one would conflict with the other. It's just a very challenging architecture to try to run multiple things on the same physical, logical host. Virtualization provides isolation for applications running their own logical server, their own virtual server.
So, you could put multiples of them on the same physical host and you get much higher utilization. You'll see folks getting on the order of 50, 70, or 80 percent utilization without any of the worries about the conflicts that used to arise when you tried to run multiple applications sharing processes on the same physical host with an operating system.
That's the architecture we're evolving towards, but if you think about it, Dana, what virtualization gives you from a business perspective, other than utilization is an opportunity to decouple the definition of the application from the system that it runs on.
Historically, you would install an application onto the physical host with the operating system on it. Then, you would work with it and massage it to get it right for that application. Now, you can do all that work independent of the physical host, and then, at run-time, you can decide where you have capacity that best meets needs of the profile of this application.
Most folks have simply gone down the road of creating a virtual machine (VM) with their typical, physical-host approach, and then doing a snapshot, saying, "Okay, now I worry about where to deploy this."
In many cases, they get locked into the hypervisor or the type of virtualization they may have done for that application. If they were to back up one or two steps and say, “Boy, this really does give me an opportunity to define this application in a way that if I wanted to run it on Amazon's EC2, I probably could, but I could also run it my own data center.”
Now, I can begin sourcing infrastructure a little more dynamically, based upon the load that I see. Maybe I can spend less on the capital associated with my own datacenter, because with my application defined as this independent unit, separate from the physical infrastructure I'll be able to buy infrastructure on demand from Amazon, Rackspace, GoGrid, these folks who are now offering up these virtualized clouds of servers.
Gardner: I see. So, we need to rethink the application, so that we can run that application on a variety of these new sourcing options that have arisen, be they on premises, off premises, or perhaps with a hybrid.
Marshall: I think it will be a hybrid, Dana. I think for very small companies, who don't even have the capital option of putting up a data center, they will go straight to an on-demand cloud-type approach. But, for the enterprise that is going to be invested in the data center anyway at some level, they simply get an opportunity to right-size that infrastructure, based upon the profile of applications that really need to be run internally, whether for security, latency, data-sensitivity, or whatever reason.
But, they'll have the option for things that are portable, as it relates to their security, performance, profile, as it relates to the nature of the workload, to make them portable. We saw this very same thing with Linux adoption post 9/11. The things that could be moved off of Solaris easily were moved off. Some things were hard to move, and they didn't move them. It didn't make sense to move them, because it cost too much to move them.
I think we're going to see the same sort of hybrid approach take hold. Enterprise folks will say, “Look, why do I need to own the servers associated with doing the monthly analysis of the log files associated with access to this database for a compliance reason. And, then the rest of the month, that server just sits idle. "Why do I want to do that for that type of workload? Why do I want to own the capacity and have it be captive for that type of workload?"
That would be a perfect example of a workload where it says, I am going to crunch those logs once a month up on Amazon or Rackspace or some place like that, and I am going to pay for a day-and-a-half of capacity and then I am going to turn it off.
Gardner: So, there's going to be a decision process inside each organization, probably quite specific to each organization, about which applications should be hosted in which ways. That might include internal and external sourcing options. But, to be able to do that you have to approach these applications thoughtfully, and you also have to create your new applications. With this multi-dimensional hosting possibility set, if you will, it might. What steps need to be taken at the application level for both the existing and the newer apps?
Marshall: For the existing applications, you don't want to face a situation, in terms of looking at the cloud you might use, that you have to rewrite your code. This is a challenge that the folks that are facing with things such as Google's App Engine or even Saleforce's Force.com. With that approach, it's really a platform, as opposed to an on-demand infrastructure. By a platform I mean there is a set of development tools and a set of application-language expectations that you use in order to take advantage of that platform.
For legacy applications, there's not going to be much opportunity. For those folks, I really don't believe they'll consider, "Gee, I'll get so much benefit out of Salesforce, I'll get so much benefit out of Google, that I'm going to rewrite this code in order to run it on those platforms.
They may actually consider them for new applications that would get some level of benefit by being close to other services that perhaps Google, or for that matter, Salesforce.com might offer. But, for their existing applications, which are mostly what we are talking about here, they won't have of an opportunity to consider those. Instead, they'll look at things such as Amazon's Elastic Compute Cloud, and things that would be offered by a GoGrid or Rackspace, folks in that sort of space.
The considerations for them are going to be, number one, right now the easiest way to run these things in those environments is that it has to be an x86 architecture. There is no PA-RISC or SPARC or IBM's Power architecture there. They don't exist there, so A, it's got to be x86.
And B, the most prevalent cases of applications running in these spaces are run on Linux. The biggest communities of use and biggest communities of support are going to be around Linux. There have been some new enhancements around Microsoft on Amazon. Some of these folks, such as GoGrid, Rackspace, and others, have offered Windows hosting. But here's the challenge with those approaches.
For example, if I were to use Microsoft on Amazon, what I'm doing is booting a Microsoft Amazon Machine Image (AMI), an operating system AMI on Amazon. Then I'm installing my application up there in some fashion. I'm configuring it to make it work for me, and then I'm saving it up there.
The challenge with that is that all that work you just went through to get that application tested, embedded, and running up there on Amazon in the Microsoft configuration that Amazon is supporting is only useful on Amazon.
So, a real consideration for all these folks who are looking at potentially using cloud are saying, "How is it that I can define my application as a working unit, and then be able to choose between Amazon or my internal architecture that perhaps has a VMware basis, or a Rackspace, GoGrid, or BlueLock offering?" You're not going to be able to do that, if you define your cloud application as running on Windows and Amazon, because that Amazon AMI is not portable to any of these other places.
Gardner: Portability is a huge part of what people are looking for.
Marshall: Yes. A big consideration is: are you comfortable with Linux technology or other related open-source infrastructure, which has a licensing approach that's going to enable it to truly be portable for you. And, by the way, you don't really want to spend the money for a perpetual license to Windows, for example, even if you could take your Windows up to Amazon.
Taking your own copy of Windows up there isn't possible now. It may be possible in the future, and I think Microsoft will eventually have a business, whereby they license, in an on-demand fashion, the operating system as a hosting unit to be bound to an application, instead of an infrastructure, but they don't do that now.
So, another big consideration for these enterprises now is do I have workloads that I'm comfortable running on Linux right now, so that I can take a step forward and bind Linux to the workload in order to take it to where I want it to go.
Gardner: Tell us a little bit about what rPath brings to the equation?
Marshall: rPath brings a capability around defining applications as virtual machines (VMs), going through a process whereby you release those VMs to run on whichever cloud of your choosing, whether a hypervisor virtualized cloud of machines, such as what's provided by Amazon, or what you can build internally using Citrix XenSource or something like VMware's virtual infrastructure.
It then provides an infrastructure for managing those VMs through their lifecycle for things such as updates for backup and for configuration of certain services on the machines in a way that's optimized to run a virtualized cloud of systems. We specialize in optimizing applications to run as VMs on a cloud or virtualized infrastructure.
Gardner: It seems to me that that management is essential in order not to just spin out of control and become too complex with too many instances, and with difficulty in managing the virtual environments, even more so than the physical one.
Marshall: It's the lack of friction in being able to quickly deploy a virtualized environment, versus the amount of friction you have in deploying a physical environment. When I say "friction," I mean literally. With a physical environment somebody is going to go grab a server, slam it in a rack, hook up power networking, and allocate it to your account somehow. There is just a lot of friction in procuring, acquiring, and making that capacity available.
In the virtualized world, if someone has already deployed the capital, the physical capital, they can give you access to the virtual capital, the VM, very, very quickly. It's a very quick step to give you that access, but that's a double-edged sword. The reason I say it's a double-edged sword is because if it's really easy to get, people might take more. They might need more already, and they've been constrained by the friction in the process. But, taking more also means you've got to manage more.
You run the risk, if you're not careful. If you make it easy, low friction and low cost, for people to get machines, they will acquire the machine capacity, they will deploy the machine capacity, they will use the machine capacity, but then they will be faced with managing a much larger set of machine capacity than maybe they were comfortable with.
If you don't think about how to make these VMs more manageable than the physical machines to begin with, that friction can be the beginning of a very slippery slop toward a lack of manageability and risk associated with security issues that you can't get your arms around, just because of how broadly these things are deployed.
It can lead to a lot of excess spending, because you are deploying machines that you thought would be temporary, but you never take them back down because, perhaps, it was too difficult to get them configured correctly the first time. So, there are lots of challenges that this lack of friction brings into play that the physical world sort of kept a damper on, because there was only so much capacity you could get.
Gardner: It seems that having a set policy at some level of automation needs to be brought to the table here, and something that will cross between applications and operations in management and something that they can both understand. The old system of just handing things off, without really any kind of a lifecycle approach, simply won't hold up.
Marshall: There are a couple of considerations here. With these things being available as services outside of the IT organization, the IT organization has to be very careful that they find a way to embrace this with their lines of business. If they don't, if they say no to the line-of-business guys, the line-of-business guys are just going to go swipe a credit card on Amazon and say, "I'll show you what no looks like. I will go get my own capacity, I don't need you anymore."
We actually saw some of this with software as a service (SaaS), and it was a very tense negotiation for some time. With SaaS it typically began with the head of sales, who went into the CEO's office, and said, "You know what? I've had it with the CIO, who is telling me I can't have the sales-force automation that I need, because we don't have the capacity or it's going to take years, when I know, I can go turn it on with Salesforce.com right now."
And do you know what the CEO said? The CEO said, “Yes, go turn it on.” And he told the CIO, "Sit down. You're going have to figure out a way to integrate what's going on with Salesforce.com with what we're doing internally, because I am not going to have my sales force constrained."
You're going to see the same thing with the line-of-business guys as it relates to these services being provided. Some smart guy inside Goldman Sachs is going to say, "Look, if I could run 200 Monte Carlo simulation servers over the next two days, we'd have an opportunity to trade in the commodities market. And, I'm being told that I can't have the capacity from IT. Well, that capacity on Amazon is only going to cost me $1,000. I'm taking it, I'm trading, and we're going to make some money for the firm."
What's the CEO going to say? The CEO isn't going to say no. So, the folks in the IT organization have to embrace this and say, "I'll tell you what. If you are going to do this, let me help you do it in a way that takes risk out for the organization. Let me give you an approach that allows you to have this friction-free access, the infrastructure, while also preserving some of the risk, mitigation practices and some of the control practices that we have. Let me help you to find how you are going to use it."
There really is an opportunity for the CIO to say, "Yes, we're going to give you a way to do this, but we are going to do it in a way that it's optimized to take advantage of some of the things we have learned about governance and best practices in terms of deploying applications to an operational IT facility."
Gardner: So, with policy and management, in essence, the control point for the relationship between the applications, perhaps even the relationship between the line-of-business people and the IT folks, needs to be considered with the applications themselves. It seems to me that you need to build them for this new type of management, policy, and governance capability?
Marshall: The IT organization is going to need to take a look at what they've historically done with this air-gap between applications and operations. I describe it as an air-gap, because typically you had this approach, where an application was unit-test complete. Then, it went through a testing matrix -- a gauntlet, if you will -- to go from Dev/Test/QA to production.
There was a set of policies that were largely ingrained in the mind of the release engineers, the build masters, and the folks who were responsible for running it through its paces to get it there. Sometimes, there was some sort of exception process for using certain features that maybe hadn't been approved in production yet. There's an opportunity now to have that process become streamlined by using a system. We've built one, and we've got one that they can codify and put these processes into, if you will, a build system for VMs and have the policies be enforced at the build time so that you are constructing for compliance.
With our technology, we enforce a set of policies that we learned were best practices during our days at Red Hat when constructing an operating system. We've got some 50 to 60 policies that get enforced at build time, when you are building the VM. They're things like don't allow any dangling symlinks, and closing the dependency loop around all of the binary packages to get included. There could be other more corporate-specific policies that need to be included, and you would write those policies into the build system in order to build these VMs.
It's very similar to the way you put policies into your application lifecycle management (ALM) build system when you were building the application binary. You would enforce policy at build time to build the binary. We're simply suggesting that you extend that discipline of ALM to include policies associated with building VMs. There's a real opportunity here to close the gap between applications and operations by having much of what is typically been done in installing an application and taking it through Dev, QA and Test, and having that be part of an automated build system for creating VMs.
Gardner: All right. So, we're really talking about enterprise application's virtualization, but doing it properly, doing it with a lifecycle. This provides an on- ramp to cloud computing and the ability to pick and choose the right hosting and and/or hybrid approaches as these become available.
But we still come back to this tension between the application and the virtual machine. The application traditionally is on the update side and the virtual machine traditionally on the operations, the runtime, and the deployment side.
So we're really talking about trying to get a peanut-butter cup here. It's Halloween, so we can get some candy talk in. We've got peanut butter and chocolate. How do we bring them together?
Marshall: Dana, what you just described exists because people are still thinking about the operating system as something that they bind to the infrastructure. In this case, they're binding the operating system to the hypervisor and then installing the application on top of it. If the hypervisor is now this bottom layer, and if it provides all the management utilities associated with managing the physical infrastructure, you now get an opportunity to rethink the operating system as something that you bind to the application.
Marshall: I'll give you a story from the financial services industry. I met with an architect who had set up a capability for their lines of business to acquire VMs as part of a provisioning process that allows them to go to a Web page, put in an account number for their line of business, request an environment -- a Linux/Java environment or a Microsoft .NET environment -- and within an hour or so they will get an e-mail back saying, "Your environment or your VMs are available. Here are the host names."
They can then log on to those machines, and a decentralized IT service charges the lines of business based upon the days, weeks, or months they used the machine.
I said, "Well, that's very clever. That's a great step in the right direction." Then, I asked, and “How many of these do you have deployed?" And he said, “Oh, we've got about 1,500 virtual machines deployed over the first nine months.” I said, “Why did you do this to begin with?”
And, he said, “We did it to begin with, because people always requested more than they needed, because they knew they would have to grow. So, they go ahead and procure the machines well ahead of their actual need for the processing power of the machine. We did this so that we feel confident that they could procure extra capacity on-demand, as needed by the group.”
I said, “Well, you know, I'd be interested in this statistic around the other side of that challenge. You want them to procure only what they need, but you want them to give back what they don't need as well.” He kind of looked at me funny, and I said, “Well, what do the statistics look back on the getbacks? I mean, how many machines have you ever gotten back?”
And, he said, “Not a one ever. We've never gotten a single machine back ever.” I said, “Why do you think that it is?” He said, “I don't know and I don't care. I charge them for what they're using.”
I said, “Did you ever stop to think that maybe the reason they're not giving them back is because of the time from when you give them the machine to the time that it's actually operational for them? In other words, what it takes them to install the application, to configure all the system services, to make the application sort of tuned and productive on that host -- that sort of generic host that you gave them. Did you ever think that maybe the reason they are not giving it back is because if they had to go through that again, that would be real pain in the neck?"
So, I asked him, I said, “What's the primary application you are running here anyway?” He said, “Well, 900 of these systems are tick data, Reuters' Ticker Tape data." I said, “That's not even useful on the weekends. Why don't they just give them all back on the weekends and you shut down a big hunk of the datacenter and save on power and cooling?” He said, “I haven’t even thought about it and I don't care, because it's not my problem.”
Gardner: Well it's something of an awfully wasteful approach, where supply and demand are in no way aligned. The days of being able to overlook those wasteful practices are pretty much over, right?
Marshall: There's an opportunity now, if they would think about this problem and say, “Hey. Why am I giving them this, let's say, this Linux Java environment and then having them run through a gauntlet to make it work for every machine, instead of them taking an approach where they define, based upon a system and some policies I have given them, they actually attach the operating system and they configure all of this stuff independent of the production environment. Then, at run-time these things get deployed and are actually productive in a matter or minutes, instead of hours, days, and months.
In that way, they feel comfortable giving me the capacity back, when they are not using it, because they know that they can quickly get the application up and running in the manner it should be configured to run very, very quickly in a very scalable way, in a very elastic way.
That elasticity benefit has been overlooked to date, but it's a benefit that's going to become very important as people do exactly what you just described, which is become sensitive to the notion that a VM idling out there and consuming space is just as bad as a physical machine idling out there and consuming space.
Gardner: I certainly appreciate the problem, the solution set, and the opportunity for significant savings and agility. That's to say, you can move your applications, get them up fast, but you will also, in the long-term, be able to cut your overall cost because of the utilization and using the elasticity to match your supply and demand as closely as possible. The question then is how to get started. How do you move to take advantage of these? Tell us a little bit more about the role that rPath plays in facilitating that.
Marshall: The first thing to do, Dana, is to profile your applications and determine which ones have sort of lumpy demand, because you don't want to work on something that needs to be available all the time and has pretty even demand. Let's go for something that really has lumpy demand, so that we can do the scale-up and give back and get some real value out of it.
So, the first thing to do is an inventory of your applications and say, “What do I have out here that has lumpy demand?” Pick a couple of candidates. Ideally, it's going to be hard to do this without running Linux. It needs to be a workload that will run on Linux, whether you have run it on Linux historically or not. Probably, it needs to be something written in Java, C, C++, Python, Perl, or Ruby -- something that you can move to a Linux platform -- something, that has lumpy demand.
The first step that we get involved in is packaging that application as an application that's optimized to be a VM and to run in a VM. One of rPath’s values here is that the operating system becomes optimized to the application, and the footprint of the operating system and therefore it's management burden, shrinks by about 90 percent.
When you bind an operating system to an application, you're able to eliminate anything that is not relevant to that application. Typically, we see a surface area shrinking to about 10 percent of what is typically deployed as a standard operating system. So, the first thing is to package the application in a way that is optimized to run in a VM. We offer a product called rBuilder that enables just that functionality.
The second, is to determine whether you're going to run this internally on some sort of virtualized infrastructure that you've have made available in my infrastructure through VMware, Xen, or even Microsoft Hyper-V for that matter, or are you going to use an external provider?”
We suggest that when you get started with this set, as soon as possible, you should begin experimenting with an external provider. The reason for that is so that you don't put in place a bunch of crutches that are only going to be relevant to your environment and will prevent the application from ever going external. You can never drop the crutches that are associated with your own hand-holding processes that can only happen inside of your organization.
We strongly suggest that one of the first things you do, as you do this proof of concept, is actually do it on Amazon or another provider that offers a virtualized infrastructure. Use an external provider, so that you can prove to yourself that you can define an application and have it be ready to run on an infrastructure that you don't control, because that means that you defined the application truly independent of the infrastructure.
Gardner: And, that puts you in a position where eventually you could run that application on your local cloud or virtualized environment and then, for those lumpy periods when you need that exterior scale and capacity, you might just look to that cloud provider to support that application in that fashion.
Marshall: That's exactly right, whereas, if you prove all this out internally only, you may come across a huge "oops" that you didn't even think about, as you try to move it externally. You may find that you've driven yourself down in architectural box canyon that you just can't get out of.
So, we strongly suggest to folks that you experiment with this proof of concept, using an external, and then bring it back internally and prove that you can run it internally, after you've proven that you can run it externally.
Gardner: Your capital cost for that are pretty meager or nothing, and then your operating cost will benefit in the long run, because you will have those hybrid options.
Marshall: Another benefit of starting external for one of these things is that the cost at the margin for doing this is so cheap. It's between 10 and 50 cents per CPU hour to set up the Amazon environment and to run it, and if you run it for an hour you pay the 10 cents, it's not like you have to commit to some pre-buy or some amount of infrastructure. It's truly on demand. What you really use is what you pay for. So, there's no reason from a cost perspective not to look at running your first instance, of an on-demand, virtualized application externally.
Gardner: And, if you do it in this fashion, you're able to have that portability. You can take it in, and you can put it out. You've built it for that and there is no hurdle you have to overcome for that portability.
Marshall: If you prove to yourself that you can do it, that you can run it in both places, you've architected correctly. There's a trap here. If you become dependent on something associated with a particular infrastructure set or a particular hypervisor, you preclude any use in the future of things that don't have that hypervisor involved.
Gardner: Another thing that people like about the idea of virtualizing applications is that you get a single image of the application. You can patch it, manage it, upgrade it, and that is done once, and it doesn't have to be delivered out to a myriad of machines, with configuration issues and so forth. Is that the case in this hybrid environment, as well, or you can have this single image for the amount of capacity you need locally, and then for that extra capacity at those peak times, from an external cloud?
Marshall: I think you've got to be careful here, because I don't believe that one approach is going to work in every case. I'll give you an example. I was meeting with a different financial services firm who said, “Look, of our biggest application, we've got -- I think it was 1,500 or 2,000 -- instances of that application running." And he said, “I'm not going to flood the network with 1,500 new machines, when I have to make changes to that.” So, we are going to upgrade those VMs in place.
We're going to have each one of them access some sort of lifecycle management capability. That's another benefit we provide and we provide benefits in two ways. One, we've got a very elegant system for delivering maintenance and updates to a running system. And two, since you've only got 10 percent of the operating system there you're patching one-tenth as often, because operating system is typically the catalyst for most of the patching associated with security issues and other things.
I think there are going to be two things happening here. People are going to maintain these releases of applications as VMs, which you may want to think of as a repository of available application VMs that are in a known good state, and that are up-to-date and things like that.
And in some cases whenever new demand needs to come on line the known good state is going to be deployed and they won't deploy it and then patch it after they deploy it. It will be deployed and it won't need patching. But at the same time, there will be deployed units that are running that they will want to patch, and they need to be able to do that without having to distribute, dump the data, backup the data, kill the image, bring a new image up and then reload the data.
In many cases, you're going to want to see these folks actually be able to patch in place as well. The beauty of it is, you don't have to choose. They can be both. It doesn't have to be one or the other.
Gardner: So that brings us back to the notion of good management, policies, governance, and automation, because of this lifecycle. It's not simply a matter of putting that application up, and getting some productivity from utilization, but it's considering this entire sunrise-to-sunset approach as well.
Marshall: Right, and that also involves having the ability to do some high-quality scaling on-demand to be able to call an API to add a new system and to be able to do that elegantly, without someone having to log into the system and thrash around configuring it to make it aware of the environment that it's supposed to be supporting.
There are quite a few considerations here, when you're defining applications as VMs, and you are defining them independent of where they run, you are not going to use any crutches associated with your internal infrastructure to be able to elastically scale up and scale back.
There are some interesting new problems that come up here that also are new opportunities to do things better. This whole notion of architecting in a way that is A, optimized for virtualization. In other words, if you are going to make it easy to get extra machines, you'd better make machines easy to manage, and you'd better make them manageable on the hypervisor that they are running on. And B, you need to have a way to add capacity in an elegant way that doesn't require folks logging in and doing a lot of manual work in order to be able to scale these things up.
Gardner: And then, in order to adopt a path to cloud benefits, you just start thinking about the steps across virtualization, thinking a bit more holistically about the virtualized environment and applications as being one and the same. The level of experimentation gives you the benefits, and ultimately you'll be building a real fabric and a governed best methods approach to cloud computing.
Marshall: The real opportunity here is to separate the application-virtualization approach from the actual virtualization technology to avoid the lock-in, the lack of choice, and the lack of the elasticity that cloud computing promises. If you do it right, and if you think about application virtualization as an approach that frees your application from the infrastructure, there is a ton of benefit in terms of dynamic business capability that is going to be available to your organization.
Gardner: Well, great. I just want to make sure that we covered that entire stepping process into adoption and use. Did we leave anything out?
Marshall: What we didn't talk about was what should be possible at the end of the day.
Gardner: What's that gold ring out there that you want to be chasing after?
Marshall: Nirvana would look like something that we call a "hyper cloud concept," where you are actually sourcing demand by the day or hour, based upon service level experience, performance experience, and security experience with some sort of intelligent system analyzing the state of your applications and the demand for those applications and autonomically acquiring capacity and putting that capacity in place for your applications across multiple different providers.
Again, it's based upon the set of experiences that you cataloged around what's the security profile that these guys provide? What's the performance profile that they provide? And, what's the price profile that they provide.
Ultimately, you should have a handful of providers out there that you are sourcing your applications against and sourcing them day-by-day, based upon the needs of your organization and the evolving capabilities of these providers. And, that's going to be a while.
In the near term, people will choose one or two cloud providers and they will develop a rapport on a comfortable level. If they do this right, over time they will be able to get the best price and the best performance, because they will never be in a situation where they can't bring it back and put it somewhere else. That's what we call the hyper cloud approach. It's a ways off, it's going to take some time, but I think it's possible.
Gardner: The nice thing about it is that your business outcomes are your start and your finish point. In many cases today, your business outcomes are, in some ways, hostage to whatever the platform in IT requirements are, and then that's become a problem.
Marshall: Right. It can be.
Gardner: Well, terrific. We've been talking about cloud computing and proper on-ramps to approach and use clouds, and also how enterprises can best prepare to bring their applications into a virtual development and deployment environment.
We've been joined by Billy Marshall, a founder and chief strategy officer at rPath. I certainly appreciate your time, Billy.
Marshall: Dana, it's been a pleasure, thanks for the conversation.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect podcast. Thanks, and come back next time.
Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: rPath.
Transcript of BriefingsDirect podcast on virtualized applications development and deployment strategies as on-ramp to cloud computing. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.
Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: rPath.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.
Today, we present a sponsored podcast discussion on proper on-ramps to cloud computing, and how enterprises can best prepare to bring applications into a virtual development and deployment environment.
While much has been said about cloud computing in 2008, the use of virtualization is ramping up rapidly. Moreover, enterprises are moving from infrastructure virtualization to application-level virtualization.
We're going to look at how definition and enforcement of policies helps ensure conformance and consistency for virtual applications across their lifecycle. Managing virtualized applications holistically is an essential ingredient in making cloud-computing approaches as productive as possible while avoiding risk and onerous complexity.
To provide the full story on virtual applications lifecycle, methods and benefits, I'm joined by Billy Marshall, the founder of rPath, as well as their chief strategy officer. Welcome to the show, Billy.
Billy Marshall: Thanks, Dana, great to be here.
Gardner: There is a great deal going on with technology trends, the ramp up of virtualization, cloud computing, services-oriented architecture (SOA), use of new tools, light-weight development environments, and so forth. We're also faced unfortunately with a tough economic climate, as a global recession appears to be developing.
What’s been interesting for me is that this whole technological trend-shift and this economic imperative really form a catalyst to a transformative IT phase that we are entering. That is to say, the opportunity to do more with less is really right on the top of the list for IT decision-makers and architects.
Tell me, if you would, how some of these technology benefits and the need to heighten productivity fit and come together.
Marshall: Dana, we've seen this before, and specifically I have seen it before. I inherited the North America sales role at Red Hat in April of 2001, and of course shortly thereafter, in September of 2001, we had the terrible 9/11 situation that changed a lot of the thinking.
The dot-com bubble burst, and it turned out to be a catalyst for driving Linux into a lot of enterprises that previously weren't thinking about it before. They began to question their assumptions about how much they were willing to pay for certain types of technologies, and in this case it happened to be the Unix technology. In most cases they were buying from Sun and that became subject of a great deal of scrutiny. Much of it was replaced in the period from 2001to 2003 and into 2004 with Linux technology.
We're once again facing a similar situation now, where people, enterprises specifically, are taking a very tough look at their data center expenditures and expansions that they're planning for the data center. I don't think there's any doubt in people's mind that they are getting good value out of doing things with IT, and a lot of these businesses are driven by information technology.
At the same time, this credit crunch is going to have folks look very hard at large-scale outlays of capital for data centers. I believe that will be a catalyst for folks to consider a variable-cost approach to using infrastructures or service, perhaps platform as a service (PaaS). All these things roll up under the notion of cloud, as it relates to being able to get it when you need it, get it at variable cost, and get it on demand.
Gardner: Obviously, there's a tremendous amount of economic value to be had in cloud computing, but some significant risks as well. As we look at how virtualization increases utilization of servers and provide the dynamic ability to fire up platform and instances of run-time and actual applications with a stack beneath them, it really allows companies to increase their applications with a lower capital expenditure upfront and also cut their operating costs. Then, we can have administrators and architects managing many more applications, if it's automated and governed properly. So let's get into this notion of doing it right.
When we have more and more applications and services, there is, on one side, a complexity problem. There is also this huge utilization benefit. What's the first step in getting this right in terms of a lifecycle and a governance mentality?
Marshall: Let's talk first about why utilization was a problem without virtualization. Let's talk about old architecture for a minute, and then we can talk about, what might be the benefits of a new architecture if done correctly.
Historically, in the enterprise you would get somewhere between 15 and 18 percent utilization for server applications. So, there are lots of cycles available on a machine and you may have two machines running side-by-side, running two very different workloads, whose cycles are very different. Yet, people wouldn't run multiple applications on the same server setup in most cases, because of the lack of isolation when you are sharing processes in the operating system on the server. Very often, these things would conflict with one another.
During maintenance, maintenance required for one would conflict with the other. It's just a very challenging architecture to try to run multiple things on the same physical, logical host. Virtualization provides isolation for applications running their own logical server, their own virtual server.
So, you could put multiples of them on the same physical host and you get much higher utilization. You'll see folks getting on the order of 50, 70, or 80 percent utilization without any of the worries about the conflicts that used to arise when you tried to run multiple applications sharing processes on the same physical host with an operating system.
That's the architecture we're evolving towards, but if you think about it, Dana, what virtualization gives you from a business perspective, other than utilization is an opportunity to decouple the definition of the application from the system that it runs on.
Historically, you would install an application onto the physical host with the operating system on it. Then, you would work with it and massage it to get it right for that application. Now, you can do all that work independent of the physical host, and then, at run-time, you can decide where you have capacity that best meets needs of the profile of this application.
Most folks have simply gone down the road of creating a virtual machine (VM) with their typical, physical-host approach, and then doing a snapshot, saying, "Okay, now I worry about where to deploy this."
In many cases, they get locked into the hypervisor or the type of virtualization they may have done for that application. If they were to back up one or two steps and say, “Boy, this really does give me an opportunity to define this application in a way that if I wanted to run it on Amazon's EC2, I probably could, but I could also run it my own data center.”
Now, I can begin sourcing infrastructure a little more dynamically, based upon the load that I see. Maybe I can spend less on the capital associated with my own datacenter, because with my application defined as this independent unit, separate from the physical infrastructure I'll be able to buy infrastructure on demand from Amazon, Rackspace, GoGrid, these folks who are now offering up these virtualized clouds of servers.
Gardner: I see. So, we need to rethink the application, so that we can run that application on a variety of these new sourcing options that have arisen, be they on premises, off premises, or perhaps with a hybrid.
Marshall: I think it will be a hybrid, Dana. I think for very small companies, who don't even have the capital option of putting up a data center, they will go straight to an on-demand cloud-type approach. But, for the enterprise that is going to be invested in the data center anyway at some level, they simply get an opportunity to right-size that infrastructure, based upon the profile of applications that really need to be run internally, whether for security, latency, data-sensitivity, or whatever reason.
But, they'll have the option for things that are portable, as it relates to their security, performance, profile, as it relates to the nature of the workload, to make them portable. We saw this very same thing with Linux adoption post 9/11. The things that could be moved off of Solaris easily were moved off. Some things were hard to move, and they didn't move them. It didn't make sense to move them, because it cost too much to move them.
I think we're going to see the same sort of hybrid approach take hold. Enterprise folks will say, “Look, why do I need to own the servers associated with doing the monthly analysis of the log files associated with access to this database for a compliance reason. And, then the rest of the month, that server just sits idle. "Why do I want to do that for that type of workload? Why do I want to own the capacity and have it be captive for that type of workload?"
That would be a perfect example of a workload where it says, I am going to crunch those logs once a month up on Amazon or Rackspace or some place like that, and I am going to pay for a day-and-a-half of capacity and then I am going to turn it off.
Gardner: So, there's going to be a decision process inside each organization, probably quite specific to each organization, about which applications should be hosted in which ways. That might include internal and external sourcing options. But, to be able to do that you have to approach these applications thoughtfully, and you also have to create your new applications. With this multi-dimensional hosting possibility set, if you will, it might. What steps need to be taken at the application level for both the existing and the newer apps?
Marshall: For the existing applications, you don't want to face a situation, in terms of looking at the cloud you might use, that you have to rewrite your code. This is a challenge that the folks that are facing with things such as Google's App Engine or even Saleforce's Force.com. With that approach, it's really a platform, as opposed to an on-demand infrastructure. By a platform I mean there is a set of development tools and a set of application-language expectations that you use in order to take advantage of that platform.
For legacy applications, there's not going to be much opportunity. For those folks, I really don't believe they'll consider, "Gee, I'll get so much benefit out of Salesforce, I'll get so much benefit out of Google, that I'm going to rewrite this code in order to run it on those platforms.
They may actually consider them for new applications that would get some level of benefit by being close to other services that perhaps Google, or for that matter, Salesforce.com might offer. But, for their existing applications, which are mostly what we are talking about here, they won't have of an opportunity to consider those. Instead, they'll look at things such as Amazon's Elastic Compute Cloud, and things that would be offered by a GoGrid or Rackspace, folks in that sort of space.
The considerations for them are going to be, number one, right now the easiest way to run these things in those environments is that it has to be an x86 architecture. There is no PA-RISC or SPARC or IBM's Power architecture there. They don't exist there, so A, it's got to be x86.
And B, the most prevalent cases of applications running in these spaces are run on Linux. The biggest communities of use and biggest communities of support are going to be around Linux. There have been some new enhancements around Microsoft on Amazon. Some of these folks, such as GoGrid, Rackspace, and others, have offered Windows hosting. But here's the challenge with those approaches.
For example, if I were to use Microsoft on Amazon, what I'm doing is booting a Microsoft Amazon Machine Image (AMI), an operating system AMI on Amazon. Then I'm installing my application up there in some fashion. I'm configuring it to make it work for me, and then I'm saving it up there.
The challenge with that is that all that work you just went through to get that application tested, embedded, and running up there on Amazon in the Microsoft configuration that Amazon is supporting is only useful on Amazon.
So, a real consideration for all these folks who are looking at potentially using cloud are saying, "How is it that I can define my application as a working unit, and then be able to choose between Amazon or my internal architecture that perhaps has a VMware basis, or a Rackspace, GoGrid, or BlueLock offering?" You're not going to be able to do that, if you define your cloud application as running on Windows and Amazon, because that Amazon AMI is not portable to any of these other places.
Gardner: Portability is a huge part of what people are looking for.
Marshall: Yes. A big consideration is: are you comfortable with Linux technology or other related open-source infrastructure, which has a licensing approach that's going to enable it to truly be portable for you. And, by the way, you don't really want to spend the money for a perpetual license to Windows, for example, even if you could take your Windows up to Amazon.
Taking your own copy of Windows up there isn't possible now. It may be possible in the future, and I think Microsoft will eventually have a business, whereby they license, in an on-demand fashion, the operating system as a hosting unit to be bound to an application, instead of an infrastructure, but they don't do that now.
So, another big consideration for these enterprises now is do I have workloads that I'm comfortable running on Linux right now, so that I can take a step forward and bind Linux to the workload in order to take it to where I want it to go.
Gardner: Tell us a little bit about what rPath brings to the equation?
Marshall: rPath brings a capability around defining applications as virtual machines (VMs), going through a process whereby you release those VMs to run on whichever cloud of your choosing, whether a hypervisor virtualized cloud of machines, such as what's provided by Amazon, or what you can build internally using Citrix XenSource or something like VMware's virtual infrastructure.
It then provides an infrastructure for managing those VMs through their lifecycle for things such as updates for backup and for configuration of certain services on the machines in a way that's optimized to run a virtualized cloud of systems. We specialize in optimizing applications to run as VMs on a cloud or virtualized infrastructure.
Gardner: It seems to me that that management is essential in order not to just spin out of control and become too complex with too many instances, and with difficulty in managing the virtual environments, even more so than the physical one.
Marshall: It's the lack of friction in being able to quickly deploy a virtualized environment, versus the amount of friction you have in deploying a physical environment. When I say "friction," I mean literally. With a physical environment somebody is going to go grab a server, slam it in a rack, hook up power networking, and allocate it to your account somehow. There is just a lot of friction in procuring, acquiring, and making that capacity available.
In the virtualized world, if someone has already deployed the capital, the physical capital, they can give you access to the virtual capital, the VM, very, very quickly. It's a very quick step to give you that access, but that's a double-edged sword. The reason I say it's a double-edged sword is because if it's really easy to get, people might take more. They might need more already, and they've been constrained by the friction in the process. But, taking more also means you've got to manage more.
You run the risk, if you're not careful. If you make it easy, low friction and low cost, for people to get machines, they will acquire the machine capacity, they will deploy the machine capacity, they will use the machine capacity, but then they will be faced with managing a much larger set of machine capacity than maybe they were comfortable with.
If you don't think about how to make these VMs more manageable than the physical machines to begin with, that friction can be the beginning of a very slippery slop toward a lack of manageability and risk associated with security issues that you can't get your arms around, just because of how broadly these things are deployed.
It can lead to a lot of excess spending, because you are deploying machines that you thought would be temporary, but you never take them back down because, perhaps, it was too difficult to get them configured correctly the first time. So, there are lots of challenges that this lack of friction brings into play that the physical world sort of kept a damper on, because there was only so much capacity you could get.
Gardner: It seems that having a set policy at some level of automation needs to be brought to the table here, and something that will cross between applications and operations in management and something that they can both understand. The old system of just handing things off, without really any kind of a lifecycle approach, simply won't hold up.
Marshall: There are a couple of considerations here. With these things being available as services outside of the IT organization, the IT organization has to be very careful that they find a way to embrace this with their lines of business. If they don't, if they say no to the line-of-business guys, the line-of-business guys are just going to go swipe a credit card on Amazon and say, "I'll show you what no looks like. I will go get my own capacity, I don't need you anymore."
We actually saw some of this with software as a service (SaaS), and it was a very tense negotiation for some time. With SaaS it typically began with the head of sales, who went into the CEO's office, and said, "You know what? I've had it with the CIO, who is telling me I can't have the sales-force automation that I need, because we don't have the capacity or it's going to take years, when I know, I can go turn it on with Salesforce.com right now."
And do you know what the CEO said? The CEO said, “Yes, go turn it on.” And he told the CIO, "Sit down. You're going have to figure out a way to integrate what's going on with Salesforce.com with what we're doing internally, because I am not going to have my sales force constrained."
You're going to see the same thing with the line-of-business guys as it relates to these services being provided. Some smart guy inside Goldman Sachs is going to say, "Look, if I could run 200 Monte Carlo simulation servers over the next two days, we'd have an opportunity to trade in the commodities market. And, I'm being told that I can't have the capacity from IT. Well, that capacity on Amazon is only going to cost me $1,000. I'm taking it, I'm trading, and we're going to make some money for the firm."
What's the CEO going to say? The CEO isn't going to say no. So, the folks in the IT organization have to embrace this and say, "I'll tell you what. If you are going to do this, let me help you do it in a way that takes risk out for the organization. Let me give you an approach that allows you to have this friction-free access, the infrastructure, while also preserving some of the risk, mitigation practices and some of the control practices that we have. Let me help you to find how you are going to use it."
There really is an opportunity for the CIO to say, "Yes, we're going to give you a way to do this, but we are going to do it in a way that it's optimized to take advantage of some of the things we have learned about governance and best practices in terms of deploying applications to an operational IT facility."
Gardner: So, with policy and management, in essence, the control point for the relationship between the applications, perhaps even the relationship between the line-of-business people and the IT folks, needs to be considered with the applications themselves. It seems to me that you need to build them for this new type of management, policy, and governance capability?
Marshall: The IT organization is going to need to take a look at what they've historically done with this air-gap between applications and operations. I describe it as an air-gap, because typically you had this approach, where an application was unit-test complete. Then, it went through a testing matrix -- a gauntlet, if you will -- to go from Dev/Test/QA to production.
There was a set of policies that were largely ingrained in the mind of the release engineers, the build masters, and the folks who were responsible for running it through its paces to get it there. Sometimes, there was some sort of exception process for using certain features that maybe hadn't been approved in production yet. There's an opportunity now to have that process become streamlined by using a system. We've built one, and we've got one that they can codify and put these processes into, if you will, a build system for VMs and have the policies be enforced at the build time so that you are constructing for compliance.
With our technology, we enforce a set of policies that we learned were best practices during our days at Red Hat when constructing an operating system. We've got some 50 to 60 policies that get enforced at build time, when you are building the VM. They're things like don't allow any dangling symlinks, and closing the dependency loop around all of the binary packages to get included. There could be other more corporate-specific policies that need to be included, and you would write those policies into the build system in order to build these VMs.
It's very similar to the way you put policies into your application lifecycle management (ALM) build system when you were building the application binary. You would enforce policy at build time to build the binary. We're simply suggesting that you extend that discipline of ALM to include policies associated with building VMs. There's a real opportunity here to close the gap between applications and operations by having much of what is typically been done in installing an application and taking it through Dev, QA and Test, and having that be part of an automated build system for creating VMs.
Gardner: All right. So, we're really talking about enterprise application's virtualization, but doing it properly, doing it with a lifecycle. This provides an on- ramp to cloud computing and the ability to pick and choose the right hosting and and/or hybrid approaches as these become available.
But we still come back to this tension between the application and the virtual machine. The application traditionally is on the update side and the virtual machine traditionally on the operations, the runtime, and the deployment side.
So we're really talking about trying to get a peanut-butter cup here. It's Halloween, so we can get some candy talk in. We've got peanut butter and chocolate. How do we bring them together?
Marshall: Dana, what you just described exists because people are still thinking about the operating system as something that they bind to the infrastructure. In this case, they're binding the operating system to the hypervisor and then installing the application on top of it. If the hypervisor is now this bottom layer, and if it provides all the management utilities associated with managing the physical infrastructure, you now get an opportunity to rethink the operating system as something that you bind to the application.
Marshall: I'll give you a story from the financial services industry. I met with an architect who had set up a capability for their lines of business to acquire VMs as part of a provisioning process that allows them to go to a Web page, put in an account number for their line of business, request an environment -- a Linux/Java environment or a Microsoft .NET environment -- and within an hour or so they will get an e-mail back saying, "Your environment or your VMs are available. Here are the host names."
They can then log on to those machines, and a decentralized IT service charges the lines of business based upon the days, weeks, or months they used the machine.
I said, "Well, that's very clever. That's a great step in the right direction." Then, I asked, and “How many of these do you have deployed?" And he said, “Oh, we've got about 1,500 virtual machines deployed over the first nine months.” I said, “Why did you do this to begin with?”
And, he said, “We did it to begin with, because people always requested more than they needed, because they knew they would have to grow. So, they go ahead and procure the machines well ahead of their actual need for the processing power of the machine. We did this so that we feel confident that they could procure extra capacity on-demand, as needed by the group.”
I said, “Well, you know, I'd be interested in this statistic around the other side of that challenge. You want them to procure only what they need, but you want them to give back what they don't need as well.” He kind of looked at me funny, and I said, “Well, what do the statistics look back on the getbacks? I mean, how many machines have you ever gotten back?”
And, he said, “Not a one ever. We've never gotten a single machine back ever.” I said, “Why do you think that it is?” He said, “I don't know and I don't care. I charge them for what they're using.”
I said, “Did you ever stop to think that maybe the reason they're not giving them back is because of the time from when you give them the machine to the time that it's actually operational for them? In other words, what it takes them to install the application, to configure all the system services, to make the application sort of tuned and productive on that host -- that sort of generic host that you gave them. Did you ever think that maybe the reason they are not giving it back is because if they had to go through that again, that would be real pain in the neck?"
So, I asked him, I said, “What's the primary application you are running here anyway?” He said, “Well, 900 of these systems are tick data, Reuters' Ticker Tape data." I said, “That's not even useful on the weekends. Why don't they just give them all back on the weekends and you shut down a big hunk of the datacenter and save on power and cooling?” He said, “I haven’t even thought about it and I don't care, because it's not my problem.”
Gardner: Well it's something of an awfully wasteful approach, where supply and demand are in no way aligned. The days of being able to overlook those wasteful practices are pretty much over, right?
Marshall: There's an opportunity now, if they would think about this problem and say, “Hey. Why am I giving them this, let's say, this Linux Java environment and then having them run through a gauntlet to make it work for every machine, instead of them taking an approach where they define, based upon a system and some policies I have given them, they actually attach the operating system and they configure all of this stuff independent of the production environment. Then, at run-time these things get deployed and are actually productive in a matter or minutes, instead of hours, days, and months.
In that way, they feel comfortable giving me the capacity back, when they are not using it, because they know that they can quickly get the application up and running in the manner it should be configured to run very, very quickly in a very scalable way, in a very elastic way.
That elasticity benefit has been overlooked to date, but it's a benefit that's going to become very important as people do exactly what you just described, which is become sensitive to the notion that a VM idling out there and consuming space is just as bad as a physical machine idling out there and consuming space.
Gardner: I certainly appreciate the problem, the solution set, and the opportunity for significant savings and agility. That's to say, you can move your applications, get them up fast, but you will also, in the long-term, be able to cut your overall cost because of the utilization and using the elasticity to match your supply and demand as closely as possible. The question then is how to get started. How do you move to take advantage of these? Tell us a little bit more about the role that rPath plays in facilitating that.
Marshall: The first thing to do, Dana, is to profile your applications and determine which ones have sort of lumpy demand, because you don't want to work on something that needs to be available all the time and has pretty even demand. Let's go for something that really has lumpy demand, so that we can do the scale-up and give back and get some real value out of it.
So, the first thing to do is an inventory of your applications and say, “What do I have out here that has lumpy demand?” Pick a couple of candidates. Ideally, it's going to be hard to do this without running Linux. It needs to be a workload that will run on Linux, whether you have run it on Linux historically or not. Probably, it needs to be something written in Java, C, C++, Python, Perl, or Ruby -- something that you can move to a Linux platform -- something, that has lumpy demand.
The first step that we get involved in is packaging that application as an application that's optimized to be a VM and to run in a VM. One of rPath’s values here is that the operating system becomes optimized to the application, and the footprint of the operating system and therefore it's management burden, shrinks by about 90 percent.
When you bind an operating system to an application, you're able to eliminate anything that is not relevant to that application. Typically, we see a surface area shrinking to about 10 percent of what is typically deployed as a standard operating system. So, the first thing is to package the application in a way that is optimized to run in a VM. We offer a product called rBuilder that enables just that functionality.
The second, is to determine whether you're going to run this internally on some sort of virtualized infrastructure that you've have made available in my infrastructure through VMware, Xen, or even Microsoft Hyper-V for that matter, or are you going to use an external provider?”
We suggest that when you get started with this set, as soon as possible, you should begin experimenting with an external provider. The reason for that is so that you don't put in place a bunch of crutches that are only going to be relevant to your environment and will prevent the application from ever going external. You can never drop the crutches that are associated with your own hand-holding processes that can only happen inside of your organization.
We strongly suggest that one of the first things you do, as you do this proof of concept, is actually do it on Amazon or another provider that offers a virtualized infrastructure. Use an external provider, so that you can prove to yourself that you can define an application and have it be ready to run on an infrastructure that you don't control, because that means that you defined the application truly independent of the infrastructure.
Gardner: And, that puts you in a position where eventually you could run that application on your local cloud or virtualized environment and then, for those lumpy periods when you need that exterior scale and capacity, you might just look to that cloud provider to support that application in that fashion.
Marshall: That's exactly right, whereas, if you prove all this out internally only, you may come across a huge "oops" that you didn't even think about, as you try to move it externally. You may find that you've driven yourself down in architectural box canyon that you just can't get out of.
So, we strongly suggest to folks that you experiment with this proof of concept, using an external, and then bring it back internally and prove that you can run it internally, after you've proven that you can run it externally.
Gardner: Your capital cost for that are pretty meager or nothing, and then your operating cost will benefit in the long run, because you will have those hybrid options.
Marshall: Another benefit of starting external for one of these things is that the cost at the margin for doing this is so cheap. It's between 10 and 50 cents per CPU hour to set up the Amazon environment and to run it, and if you run it for an hour you pay the 10 cents, it's not like you have to commit to some pre-buy or some amount of infrastructure. It's truly on demand. What you really use is what you pay for. So, there's no reason from a cost perspective not to look at running your first instance, of an on-demand, virtualized application externally.
Gardner: And, if you do it in this fashion, you're able to have that portability. You can take it in, and you can put it out. You've built it for that and there is no hurdle you have to overcome for that portability.
Marshall: If you prove to yourself that you can do it, that you can run it in both places, you've architected correctly. There's a trap here. If you become dependent on something associated with a particular infrastructure set or a particular hypervisor, you preclude any use in the future of things that don't have that hypervisor involved.
Gardner: Another thing that people like about the idea of virtualizing applications is that you get a single image of the application. You can patch it, manage it, upgrade it, and that is done once, and it doesn't have to be delivered out to a myriad of machines, with configuration issues and so forth. Is that the case in this hybrid environment, as well, or you can have this single image for the amount of capacity you need locally, and then for that extra capacity at those peak times, from an external cloud?
Marshall: I think you've got to be careful here, because I don't believe that one approach is going to work in every case. I'll give you an example. I was meeting with a different financial services firm who said, “Look, of our biggest application, we've got -- I think it was 1,500 or 2,000 -- instances of that application running." And he said, “I'm not going to flood the network with 1,500 new machines, when I have to make changes to that.” So, we are going to upgrade those VMs in place.
We're going to have each one of them access some sort of lifecycle management capability. That's another benefit we provide and we provide benefits in two ways. One, we've got a very elegant system for delivering maintenance and updates to a running system. And two, since you've only got 10 percent of the operating system there you're patching one-tenth as often, because operating system is typically the catalyst for most of the patching associated with security issues and other things.
I think there are going to be two things happening here. People are going to maintain these releases of applications as VMs, which you may want to think of as a repository of available application VMs that are in a known good state, and that are up-to-date and things like that.
And in some cases whenever new demand needs to come on line the known good state is going to be deployed and they won't deploy it and then patch it after they deploy it. It will be deployed and it won't need patching. But at the same time, there will be deployed units that are running that they will want to patch, and they need to be able to do that without having to distribute, dump the data, backup the data, kill the image, bring a new image up and then reload the data.
In many cases, you're going to want to see these folks actually be able to patch in place as well. The beauty of it is, you don't have to choose. They can be both. It doesn't have to be one or the other.
Gardner: So that brings us back to the notion of good management, policies, governance, and automation, because of this lifecycle. It's not simply a matter of putting that application up, and getting some productivity from utilization, but it's considering this entire sunrise-to-sunset approach as well.
Marshall: Right, and that also involves having the ability to do some high-quality scaling on-demand to be able to call an API to add a new system and to be able to do that elegantly, without someone having to log into the system and thrash around configuring it to make it aware of the environment that it's supposed to be supporting.
There are quite a few considerations here, when you're defining applications as VMs, and you are defining them independent of where they run, you are not going to use any crutches associated with your internal infrastructure to be able to elastically scale up and scale back.
There are some interesting new problems that come up here that also are new opportunities to do things better. This whole notion of architecting in a way that is A, optimized for virtualization. In other words, if you are going to make it easy to get extra machines, you'd better make machines easy to manage, and you'd better make them manageable on the hypervisor that they are running on. And B, you need to have a way to add capacity in an elegant way that doesn't require folks logging in and doing a lot of manual work in order to be able to scale these things up.
Gardner: And then, in order to adopt a path to cloud benefits, you just start thinking about the steps across virtualization, thinking a bit more holistically about the virtualized environment and applications as being one and the same. The level of experimentation gives you the benefits, and ultimately you'll be building a real fabric and a governed best methods approach to cloud computing.
Marshall: The real opportunity here is to separate the application-virtualization approach from the actual virtualization technology to avoid the lock-in, the lack of choice, and the lack of the elasticity that cloud computing promises. If you do it right, and if you think about application virtualization as an approach that frees your application from the infrastructure, there is a ton of benefit in terms of dynamic business capability that is going to be available to your organization.
Gardner: Well, great. I just want to make sure that we covered that entire stepping process into adoption and use. Did we leave anything out?
Marshall: What we didn't talk about was what should be possible at the end of the day.
Gardner: What's that gold ring out there that you want to be chasing after?
Marshall: Nirvana would look like something that we call a "hyper cloud concept," where you are actually sourcing demand by the day or hour, based upon service level experience, performance experience, and security experience with some sort of intelligent system analyzing the state of your applications and the demand for those applications and autonomically acquiring capacity and putting that capacity in place for your applications across multiple different providers.
Again, it's based upon the set of experiences that you cataloged around what's the security profile that these guys provide? What's the performance profile that they provide? And, what's the price profile that they provide.
Ultimately, you should have a handful of providers out there that you are sourcing your applications against and sourcing them day-by-day, based upon the needs of your organization and the evolving capabilities of these providers. And, that's going to be a while.
In the near term, people will choose one or two cloud providers and they will develop a rapport on a comfortable level. If they do this right, over time they will be able to get the best price and the best performance, because they will never be in a situation where they can't bring it back and put it somewhere else. That's what we call the hyper cloud approach. It's a ways off, it's going to take some time, but I think it's possible.
Gardner: The nice thing about it is that your business outcomes are your start and your finish point. In many cases today, your business outcomes are, in some ways, hostage to whatever the platform in IT requirements are, and then that's become a problem.
Marshall: Right. It can be.
Gardner: Well, terrific. We've been talking about cloud computing and proper on-ramps to approach and use clouds, and also how enterprises can best prepare to bring their applications into a virtual development and deployment environment.
We've been joined by Billy Marshall, a founder and chief strategy officer at rPath. I certainly appreciate your time, Billy.
Marshall: Dana, it's been a pleasure, thanks for the conversation.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect podcast. Thanks, and come back next time.
Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: rPath.
Transcript of BriefingsDirect podcast on virtualized applications development and deployment strategies as on-ramp to cloud computing. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.
Subscribe to:
Posts (Atom)
