Last thing that I want to mention is how to migrate applications to the Cloud. What I mean is, if I'm an enterprise and I've been doing whatever I'm doing like a bank entirely within my premises, and I say, "Well, from the point of view of future evolution of hardware that I want to take advantage of and so on, and probably shrink my IT team. I want to move my application into the Cloud." That way, I don't have to worry about all the details of managing the IT infrastructure itself. Now, what are the things that you have to think about in this migrations to the Cloud? Now, the first thing is, you have certain service parameters for your application, which may be latency. What should be the uptime for my application? What should be the availability? What is the security policies? What are the legal ramifications if my data gets compromised? All of these things are things that are very important for every individual enterprise to think about. If they say, "Well, I want to move it to the Cloud," they have to think in terms of how to architect that application when it is moved to the Cloud. Typically, Cloud-based applications are sometimes called n-tier applications. You've heard this terminal, I'm sure. N-tier meaning that if I have a service, the clients are coming in, and so there is a client facing side of the application, and that is the front-end. Then there is a business logic. Let's say, you go into an Amazon portal and want to order something. There is a business logic that decides this particular product that you want, there is a cost for that. So there is a business logic associated with that. Then the back-end is the database that stores the assets, and some of the business logic is tied to the inventory that is there in the back-end. So all of these are different layers in the software stack of an enterprise application. When I'm constructing the enterprise application entirely within my enterprise, then the things that I worry about are things like, how do I replicate certain aspects of the application? How do I load balance across these different components of the application and the service? Now, when I want to move it to the Cloud, then I have to think, how I'm I going to architect the front-end, the back-end, the business logic, and so on. Of course, the framework that I mentioned right in the beginning gives you all of these tools to do that but one of the things that you have to really worry about is intra-organization firewalls. So if you think about an enterprise. An enterprise, if you take a company like HP, externally you think of it as a single entity. But if you go inside the enterprise, it's actually there's got a marketing unit, there is a research unit, and there is a development unit, and there are firewalls built in between all of these guys. Why? Because the decisions that are being taken in terms of marketing is not something that should be visible to every employee inside the organization. So those intra-organizational firewalls, you can keep it in place if you are inside your own premises. But now if you want to move to the Cloud, then you have to ask the question, what do I move into the Cloud? What parts of it can be put into the cloud and what should not be put in the Cloud? Because if the business logic, for instance, it is exposed to the network, then a competitor can find out my way of doing the pricing and things like that. So from that point of view it is very important to protect what you think are important assets of your company. So those are the things that intra-organizational firewalls take care of. So one of the solutions in building or moving, or migrating your application from your premises into the cloud is to potentially go for hybrid implementation. This is where you may have heard of the term Private Cloud. Private Cloud is saying that it's the same functionality that you expect from the Cloud provider except that it is not in a public Cloud, it is not something that is managed centrally. Samantha has access to it, I have access to it, everybody has access to it. No, private Cloud is internal to a particular organization. There you can put things that you really want to protect as user data or business logic that you don't want to expose to the outside world. So that is the hybrid implementation, and many of these Cloud providers give you ways by which you can decide how you can parcel out what parts of the application should be in the public Cloud versus in the private Cloud. If you're a big enough enterprise, IBM will be happy to work with you and build the solution from ground up on how to do that. Like I said, I use IBM as an example of a company that continuously transform itself over time, and today the biggest revenue for IBM is its service business, is basically providing complete end-to-end IT services to enterprises. So if you take American Express, they're a financial institution. They don't want to deal with all of the IT end of it. So the entire thing can be provided by a company like IBM. That is where they will come and decide how to architect your application in such a way that whatever you think is important and private should be in your private portion of the Cloud. That's also done by IBM. The public is also done by IBM. But the point is that you don't have to worry about it, IBM will do it for you. So these are things that you have to worry about. So if we become app developers, these are all the things that you have to think about. You need a very good model of the cost/benefit of migrating each component. What is it that you get as an advantage by moving it to the Cloud? Is that a component that can benefit from scale out? If it is, then that's a good candidate for moving into the Cloud because then you can elastically grow and shrink the resources that you want.
