The ways that organizations use applications, and the applications themselves, are evolving. Applications nowadays work with increasing amounts of data while suffering from inconsistent loads and use patterns. In short, they're well-suited for cloud computing environments.
In this webcast, Bernard Golden, CEO of cloud consulting firm HyperStratus, describes the key principles of application architectures in a cloud computing environment. He also discusses the limitations of running applications in the cloud, including application integration issues, software licensing and security.
For more from Bernard, check out his piece on choosing an application architecture in the cloud.
Read the full transcript from this video below:
Application architectures for cloud computing environments
Bernard Golden: Hello. Welcome to this webinar, The New Design Paradigm: Application Architectures for Cloud Environments. And I am looking forward to speaking to you today about the topic of how Cloud computing affects application architectures. Let me begin by introducing myself. If we look at the next slide, you will see that I am the CEO of HyperStratus. We are a Cloud computing consulting firm located in Silicon Valley. We provide a range of services around Cloud computing, including strategy, and more crucially, for this particular webinar, architecture design and implementation around Cloud computing applications. We are going to talk about the implications of those things as we go on.
As a foundation for how we get started discussing this topic, let us take a look at the next slide and talk about the changes in the way that applications are being used within organizations today. If you look at this slide, it shows a traditional application architecture, a traditional use pattern. You have customers, partners, and suppliers. They are interacting with employees, but through analog methods. They are making phone calls and sending in letters, pieces of paper. This is the traditional model pre-internet, 10 or 15 years ago. The interaction with the company's computer systems are all by the employee user base, so by definition, that user base is no larger than the number of employees in the company. This is a model where basically, the interface between a company and all of its customers, partners and suppliers, is analog. It is not digital; it is not direct interaction with the company's systems by those groups of customers, partners, and suppliers.
Looking at the next slide we see that it is actually quite different. Today, we still have analog interaction between customers, partners, suppliers, and employees, lots of it: phone calls, emails, faxes, discussions, meetings, physical mail and so forth. In addition to that, we actually have digital interaction from the customers directly into a company's or organization's own computer systems. That may be transactional systems: 'I would like to place an order.' 'I would like to file a complaint.' 'I would like to send in a drawing,' but it may also be collaboration. It may be collaboration among the customers, partners, suppliers among themselves, being hosted by a company, or it may be between those groups, employees in those groups and the employees of the company itself, and there is a very rich set of interactions. We now have direct digital interaction, not just from the employee base using the organization systems, but actually from their customers, suppliers, and so forth, directly into those systems, as well. That has really profound implications for the applications and application architectures we see.
First, let us talk about what the characteristics are of that first type, where it is all of the analog interactions between the end customers and employees of the organization, and then all of the digital interactions between those employees and the company's own systems. If we look at the next slide, what we see is that in the past, we had very predictable user bases; it was, by definition, no larger than the number of employees working for an organization or company, and typically, maybe a subset of them. Very bounded user bases, user populations, and a very a predictable user base, and probably, a very consistent load: Between 8:00 and 5:00 in the morning, a certain number of users and certain kinds of patterns. Because they were transactional systems, there were very consistent ways of interacting: 'I am going to place an order.' 'I am going to do a look-up,' those kinds of things. It had consistent use patterns: 8:00 to 10:00, probably pretty busy. 10:00 to noon, very busy. Not that much going on between noon and 1:00, and then an afternoon set, as well. You never got large usage spikes at 3:00 in the morning because it was really only the employees of the company doing transactional kinds of things. It was typically much easier integration because you had much smaller numbers of applications and what you were integrating was typically very bounded data. It might be an order, invoice, or something of that nature.
Crucially, if an application did not work, the people you were inconveniencing were a company's own employees. If something is not working the employees say, 'That is unfortunate. I will work on something else.' They may be unhappy, but what are they going to do? They are going to wait. They are going to complain but they will wait until the systems come back up. This is symbolized by this picture, where basically you got a lineup of people interacting. There is only one person at a time interacting with this kiosk. Very predictable, very consistent, and very easy to understand.
Now let us turn to that new model of computer interaction where we have got collaboration on the analog basis, between a company's customers, suppliers, and so forth, and the company's own employees. Also, we have got direct interaction between those groups and a company's own computer systems, much different than the old model. There are a lot of different applications --besides just traditional transactional systems, you have got very active collaboration: 'Let us have discussions, do a wiki, send stuff back and forth, or collaborate jointly on a particular design,' or something like that.
What does that mean? Turning to the next slide, applications in today's way, with this graphic of this huge lineup of people, all waiting at the starting line, you have much larger user bases. It is not just the company's own employees; it may be all of the employees of all of the company's customers, or suppliers, probably 10 or 100 times larger user bases. It is a very inconsistent load, because even though your people work 8:00 to 5:00 in your time zone, you may be interacting with customers or suppliers located in different time zones, located halfway around the world. Just when you are sleepy, you have left work, they are on the clock, and they are working hard. They may be coming in and using your system based on their own needs, based on what is going on in their own companies. They may have a big rush of something going on, and they are going to come in and hammer your systems, so there are very inconsistent loads. It may be around the clock, it may be very large numbers dwindling to small numbers, it is hard to say, inconsistent use patterns, same sort of thing. They are very busy during a particular time of the year, when traditionally maybe you were not, or they have got some kind of event driving their use of your computer systems. Maybe they have got a very large bid they have got to do and they have got to do a lot of work, and they need to interact with your systems to get information out of them or work with your people. Then next week, they would have sent that in and there will be little usage of your system, so very inconsistent use patterns, not at all what things were like, traditionally.
Challenging integration: You are going to be, not only integrating among your own systems, but you may very well be integrating among systems with your partner systems or with your suppliers' systems. You may be trying to integrate across an extended supply chain, a much more difficult and much more challenging integration pattern. There is enormously more data in these models, not just because those end users are entering all of their data and maybe storing their own information, there is far richer applications today. People are doing things like joint design work, so they may be having blueprints or design documents that are very, very large. The interaction is much, much richer. People are having conversations, discussions, sending in questions, collaborating on forums, all of these things generate much, much more data. The average company is seeing a growth pattern of data, on the order of 60% a year, just huge amounts of data. Again, that is a challenge that companies have to address.
Very crucially, when a system is not working properly, it no longer just inconveniences a company's own employees; it conveniences their customers, suppliers, or partners. For most companies, maybe it is sad to say, but they are much more concerned about inconveniencing external parties than they are internal parties. Your own employees cannot do their job effectively because the system is not up? That is unfortunate. If a customer cannot enter an order or cannot interact with your employees, that is a disaster. That is something that is very concerning to organization.
This gives you an idea of the changing nature of the way business is being done and what that implies for applications. Because of that, applications today's way, are very well suited for Cloud computing. I would like to describe why that is, and I would like to start by talking about what Cloud computing, itself is.
If we look at the next slide, what we see is the NIST definition of Cloud computing. NIST is the National Institute of Standards and Testing, and that is a U.S. Federal Government agency that is been taking the lead in defining what Cloud computing is, what the characteristics are. The Federal Government, a bit unusually for most technology trends, is actually extremely aggressive in terms of Cloud computing, making a big push into it and really being very aggressive. NIST has been taking the lead in terms of these definitions.
If we look at it, we see that it is On Demand self-service: 'A consumer can unilaterally provision computing capabilities, such as server time and network storage as needed, automatically.' Again, this aligns very well with that pattern of usage that today, companies, customers, users, partners, or whatever, are accessing computing resources directly. This aligns very well with that pattern, this definition of Cloud computing, this aspect or characteristic.
Broad Network Access: 'Capabilities available over the network and access through standard mechanisms that promote use by heterogeneous thin or thick client platforms.' Again, when you move beyond an internal user population, people start accessing your systems through a whole variety of client devices. It is no longer just computers or laptops; it may be mobile phones, tablets, thin clients, all different devices. Again, this characteristic of Cloud computing aligns very well with the way these new applications, the way the new work patterns are occurring.
Resource Pooling: 'The provider's computing resources are pooled to serve multiple consumers, with resources dynamically assigned and reassigned according to consumer demand.' This characteristic of Cloud computing enables it to very easily shift resources back and forth to meet the system load of an application, and then release those resources when they are no longer needed. It aligns very well with the notion of Cloud computing.
Rapid Elasticity: 'Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly release to scale in.' These characteristics support that notion of loads that are very transient, that change rapidly, that are much more dynamic.
Then Measured Service is really more about how this all gets paid for. The attractive part is, essentially, you only pay for what you use, and that can be attractive for these highly variable load applications.
This really looks like Cloud computing maps very well to the traditional model, or to the new model, of what applications are being built, or the kinds of applications a company wants to have available so that they can leverage all kinds of interactions, collaborate with customers, or allow direct interaction with their computer systems. What does that imply for the way you architect applications? This is really the key thing. One of the most important facts is that for this kind of model to support applications that scale dynamically are elastic to take advantage of Cloud computing, they have to be designed differently, so we really want to talk about that next.
One of the aspects, if we look at the next slide, is that you end up with a multi-tier application. Multi-tier applications are nothing new; they have been done traditionally. In this world of high scalability and varying load, your applications have to be able to scale horizontally, which means adding new resources at every different layer of the tier very rapidly, very dynamically, and in fact, automatically. We see that these applications, to support very high loads and very variable loads are typically broken into a number of different tiers.
You are going to have a load balancer because you are going to want to have multiple resources performing every role in every tier. That way, there is no way that the application goes downs if one resource fails within these entire stacks. Remember, that is key because you do not want to inconvenience external users. You have to make sure you have redundancy of resources at every tier, which means you have to have load balancing and the ability for each resource to be able to talk to all of the resources at the layers both above and below it. We can see that we have balancer just so we can spread traffic so that traffic can always get into our application, even if some element of the front-end is down.
We have a Web Server Tier. This is typically the tier that does the most scaling and is most affected by elasticity. You may have applications that go from 3 web servers to 30, and then back down to 5. Again, you want to have multiple resources, for redundancy sake, and you want to have the ability to add and subtract resources according to those highly variable loads brought on by these new profile applications.
Your Application Server Tier, at least two. Should one server go down, you still have something up and running so that the application can continue operating. You may very well have a Caching Tier. One of the things is many of these highly loaded applications, if they attempted to go back and do reads and writes to the database every time a user interacted with them, they would overwhelm the database, so what these applications are designed to do is to cache in memory, data that is regularly accessed, that is accessed with very high frequency. You have a caching tier that is basically operates as just memory. The Application Server Tier and Storage Tier can write to it, and then when an Application Server Tier needs to do a read, its read goes first to the Caching Tier, to see if the data is available. If it is, it brings it and serves it up directly with no need to go and make a disk drive call at the Database or the Storage tier, which speeds up data access enormously. If it is not resident in the Caching Tier, then the request will go through into the Storage Tier where that data will be read and brought into the Caching Tier, so that data is served back up into the Application Tier, but the data is also left in the Caching Tier. If that particular transaction or some other user interaction needs that piece of data, the next time it does a read, it will get it out of the Caching Tier, rather than having to go all the way to the Storage Tier.
This is the model of the new application architecture that supports a very high load variation. They need to have elasticity, and they need to have redundancy so that you do not ever experience failures and inconvenience outside parties. You can see this is a much more complex application architecture.
Let us talk about the things you have to have in place. Looking at the next slide, we have the same figures, the same chart, but we can talk about the characteristics that the application needs to have. One is that you have to recognize failure. In these large Cloud environments, resources fail all the time, servers hang or go down. These are all virtual machines; they all hang or go down. Maybe the underlying hardware crashes. You have to understand that at every layer, you face the likelihood or the possibility, certainly, that a resource will stop working, that there will be failure. You have to recognize that failure is part of your underlying infrastructure, and design your application to be robust in the face of failure. Implement redundancy. Just to reiterate, you need to have multiple resources at every tier, so that if one becomes unavailable because of that failure, the application does not stop operating but can instead shift to those additional resources and continue operating. Redundancy is a key way to deal with failure.
You need to enable elasticity. What that means is your application needs to have the ability so that resources can join and release automatically, so that you do not have to have someone come and configure the ability to put another web server into the architecture, but that in fact, you can have them join when a trigger is hit. Something like: All of the web servers are at 70% load; we need to add another web server instance into this application. The new instance has to be able to come up, identify itself, get its configuration information, configure itself, and then join the application and configure the application so that it starts operating with all the other pieces, all the other elements, or servers within that application. Elasticity has to be enabled, and it has to be automatic.
You have to plan for scale. You have to assume that you are going to have 10 or 100 times more data than you start with, and plan for it to be able to handle that scale. You have to assume that you are going to be doing very large amounts of load, so you have to countenance, 'What if we get 20 or 30 web servers, not just 3?' You have to recognize the environmental limitations. What are the ways that the application operates within the infrastructure? How does the infrastructure affect what the application can do? One very common one is that the network through putting latency in a Cloud environment is not what it would be if it were in your own data center. There are virtualization layers, and it is shared resources; it is probably lower grade equipment than what you have -- it may be a 1Gig network instead of 10Gig. You have to recognize those limitations and design your application to operate in spite of those restrictions. This gives you an idea of what the key architectural principles are. Again, to support this new application architecture with these multiple tiers, the horizontal scalability which, again, take advantage of the Cloud computing characteristic so that you can meet this new type of application where you have got vastly larger numbers of users, that you have got external parties, and so forth.
That sounds great, you might say, 'This is perfect, let me just go forward with applications running under Cloud. Why would I not do that?' It is important, though, to understand that there are limitations, as well. If we look at the next slide, we see handcuffs, and that is really to indicate that there is not complete freedom. By using these new Cloud computing server providers, you gain a lot of benefits: the ability to access large amounts of resources as necessary but you also suffer some restrictions. You have to understand those, so that when you design your application, it can fulfill all those requirements of elasticity, scale, and so forth, but not be stymied by these challenges or constraints.
Let us talk about some of these restraints. One is what we call the 'Skinny Straw.' This is really about bandwidth to and from the Cloud environment. Obviously, if you are having someone sit at a laptop or a desktop, and they interact with an application that is in the data center, you are going to have very high bandwidth between your offices and your data center, in the same building, or whatever. When you go to a Cloud service provider, actually there is far lower bandwidth than what is available in your data center. That is one thing to understand. It has sort of high-ish latency, more so than you would have in your own network environment, which means that it can be very challenging if you have very large data sets to move back and forth. If you have got very high amounts of data that you have to serve up, or load, into your application, or download from your application, that can be very challenging, and to fix it can be very expensive. You have to start really investing in network connectivity and in internet capability. It can end up being very expensive. The skinny straw can be a real challenge, and it is important to understand that there is, generally speaking, less bandwidth available using a Cloud service provider than there would be if you were running an application in your own data center. You need to really understand that and plan for it. It may affect the ability to actually implement an application.
The next one talks about app integration. Applications often have multiple integration points, multiple other systems they need to talk to. It may be that there is no service-oriented architecture available, what we call secret integrations, which is akin to someone who has a particular application and says, 'I need this application to get data from this other application, but I know that that other application is installed on a server at such and thus, an IP address in my data center. I know the username and password for that database. Rather than going through implementing an SOA interface, a very nice thing, what I am going to do is write and read directly from that other application's database because I can get at it.' The problem is if you move your application out to a remote data center, it is not going to be able to do a direct read and write of the database sitting at another server in the data center, because probably those ports will not be open, or there will not be access to those systems, or for security reasons, you will not want them being accessed.
Inter-cloud is much slower. It is integration that makes sense when the two systems are within the same VLAN, or at least within the same data center, may be stymied when, in fact, the bandwidth between one application and another application, one sitting in the data center, one sitting in the Cloud service provider, that network traffic runs much more slowly so it may affect the way you are able to integrate your application. That is the number two constraint, is app integration.
Number three is one we do not hear a ton about, but it is certainly a restriction or a constraint, that is software licensing. Most software licenses around today are written for a physical, perpetual world, meaning the software vendor sells you a license to use an application on an individual physical server on a perpetual basis. Remember, part of the whole thing about Cloud computing is these are virtual resources that shift in and out very quickly. You may have a system up running for an hour, two hours, a day, or three days, certainly not perpetual. The model of how applications are licensed and charged for makes sense in a world where you have got a server, it is permanent, you are going to install this application on it, and it is available 100% of the time. In a transient world, like Cloud computing, these old style licenses really do not map very well. There are often locked to Mac addresses. There is oftentimes a software application has a license that says it needs to be installed on a particular server with a particular Mac address, and if those things change, the application will stop working.
In the world of Cloud computing, virtual machines shift all the time, their Mac addresses change all the time, it can be a real nightmare. Software licenses are typically not set up for metering: I want to use this for so many hours for such a length of time. Remember, that is the number three characteristic, which is use patterns change, and I only pay for what I use. Metering is a fundamental requirement for that model; I only pay for what I use. Most software licenses lack metering; they are set up for that perpetual arrangement. Then you have got unhappy vendors, a lot of software vendors do not like this new world, because they feel like they are going to earn less money, so they are not very supportive of Cloud computing. That is another issue: your application may have software licensing requirements that may have components in it that do not map very well, and so that can be a challenge.
Then number four: Constraint is mission-critical, the 'eggs in one basket.' The old cliché is: It is not a problem to put all your eggs in one basket, but you have got to watch that basket, because if it is really important, if it is mission-critical, you need to really worry about it. For a lot of people, they just do not feel that Cloud is proven enough for real mission-critical application, so that is a constraint on what you might do with Cloud computing. Some people ask, 'Why should I change the most important applications? Let me change all the stuff that is easier to do, that does not have the downside of something not going right.' You may want to focus on less important, or focus on high TCO- type applications, where there is an obvious benefit or an obvious payoff; so really, mission-critical can be a restraint. A lot of folks do not want to put their mission-critical applications up in a Cloud computing environment.
Finally, security: Constraint number five. It is the number one issue, people are concerned about it, they are not really sure what security is or who is responsible. There is not a full knowledge of what their best practices are to implement it as well as possible in a Cloud computing environment. This is another constraint. The notion is if you have an application that you are very concerned about its security, has particular security requirements, or particular compliance requirements, that is really not a very good match for putting an application into a public Cloud. That would be a constraint, as well. 'This has highly sensitive data in it. This is not an application to move into the Cloud. Let us go find a different one.'
Given all of these things, I want to take advantage of the Cloud because it has got all of these great characteristics. By the way, the way I am using apps and interact with my customers, suppliers, and partners is such that it makes sense to use Cloud computing, but now I have all these constraints. How do I sort my way through that? How do I figure out what are the right applications for a Cloud environment?
We have an application migration approach that we can discuss, and it really is a portfolio analysis. It ranks applications along criteria, where number one is low and number three is high. Load stability, remember, what Cloud computing is good for is high load variability, so load stability would be the opposite of that. Load stability means very consistent user population, very consistent transaction interactions, and very consistent loads. If that is high, that is probably not that well-suited for a Cloud, because what you really want is high load variability. Load stability, if that is a very consistent load, that would be a high rating. The notion is that you go through all of these characteristics, which I will go through in just a moment, and you assign a one through three score. The ones that have very high scores are not well suited to being moved into the Cloud. The ones with low scores are well suited from the perspective that they can take advantage of the Cloud environment, and they do not really suffer from the constraints.
Need for internal integration: If I need to be sitting right next to another application so I can get enough data from it, and enough throughput, that is going to be a high score, I need to have a high locality arrangement. Whereas, if I am not very dependent on internal integration, I have low, so I will give it a low score. The same thing with security and privacy, data transfer, mission critical, and software license issues. All of the things that we talked about, in terms of constraints and design needs.
What we do with our clients is that we take these buckets of applications, a certain number, 10, 20, or 100, and we go through and evaluate each application according to these characteristics and assign a score, low to high. We look at the numbers, and the ones that have low scores, we say those are the ones well suited to Cloud computing. We look at the numbers, and the ones that have high are not well suited. We say, 'They should stay where they are at.' Then we rinse and repeat, meaning, you do 20 or 50 applications, then you go to the next set of 20 or 50, it is an iterative process.
If we look graphically at a portfolio analysis example, and this is a scrubbed example of one we have done, you will see that we have got Apps 1, 2, 3 and N, indicating an overall portfolio. You will see down the left-hand side the characteristics that we just talked about: load stability, internal integration need, security and privacy, data transfer, mission-critical, and software license issues. Then we have numbers that we assign to them, and remember, high means it has high load stability. We see that App 1 has medium load stability; it's got a 2. App 2 has very high load stability, it is probably 10 users, the exact same 10, very predictable use pattern, so it gets a very high number. Apps 3 and N actually have pretty low load stability; they are not used very consistently, so they get a low number. For each application, we have gone through and done that for each of these 6 characteristics, and then we sum up the numbers.
We see that App 1 sums to 8 across those characteristics, App 2 is 16, App 3 is 9, App N is 11. The ones that are best suited for Cloud computing are the ones with the lower scores; in this case it would be apps 1 and 3, because they have only an 8 and a 9. Conversely, application 2 is probably the least likely application for Cloud computing, because it has a high score. This gives you an idea of the portfolio analysis example, and this is a way to evaluate applications to ascertain which of them are the best suited, that should be focused on for Cloud environment, and which ones should be left as they are.
In closing, let us turn to the next slide and talk about bringing it all together. The nature of applications is changing; I do not think there is any denying that. We have vastly larger user populations, very heterogeneous user populations. Some are their employees, some are outside companies, and some are outside partners or suppliers. The nature of applications is changing, and the things around load, load variation, so forth and so on, also are really dramatically different. The nature of applications is changing. Cloud computing addresses those app challenges very well. It is fundamental characteristics are being able to scale, very highly, very quickly. The fact that it offers elasticity is a really good match for this new world, these new types of applications. There is no such thing as a free lunch, and while there is great things about Cloud computing, Cloud imposes it is own constraints. There are challenges or issues present that you have to architect your application around.
We advocate applying a portfolio analysis. Not every application is suitable for Cloud computing, you would be foolish to think that. What makes more sense is to make an evaluation: Which ones are best suited, which ones are not. Then really focus the direction toward those that are best suited. If you would like a little bit more information about the portfolio analysis, you can find our portfolio analysis checklist at this link: HyperStratus.com/Portfolio-Analysis. We welcome you to download that. That should help you as you go through your evaluation process.
In conclusion, what I would like to share is that it is a really different world going forward. The application architectures that we have traditionally and historically used, do not support the new ways of using systems that we want to be able to enable. We really have to take up and learn new ways of architecting our applications and new skills so that we can meet this new world of the way we do business.
Thank you very much. I hope you have enjoyed this webinar.