Development and General

As a Service: The many faces of the cloud

Lori MacVittie — Thu, 20 Nov 2008 11:12:05 GMT

Last month I happened across this amusing, and ironic, poem describing the dichotomy that exists in trying to define cloud computing. Go ahead and read it, I'll wait, it's worth the time. Seriously.

I am not going to define cloud computing again. I've done that already and the point of this discussion is not what is cloud computing but rather how the cloud is beginning to separate into distinct models, each serving a different set of needs. The common theme between these models is "as a service". Some "thing" traditionally relegated to the local IT data center is being offered in the cloud, as a service. The list is growing, but it appears that we'll likely end up with three service models for the cloud: software, infrastructure, and platforms.

SOFTWARE AS A SERVICE (SaaS)

Software as a Service (SaaS) was pioneered and proven as a successful model by salesforce.com, and has since been duplicated successfully by myriad other vendors. The SaaS model works on the assumption that all enterprises need is the ability to customize and integrate software (which is, for the most part, true of a wide variety of software offerings) and need not (a) reinvent the wheel or (b) worry about the actual implementation/deployment details.

SaaS is a good choice when:

You need software to support common business processes like customer relationship management
You need some customization but it is primarily at the data level and not at the application logic level
The software in question needs to support a geographically diverse pool of employees

PLATFORM AS A SERVICE (PaaS)

Platform as a Service (PaaS) is a somewhat emerging concept that is gaining traction for several reasons. PaaS is based on the premise that you want or need a development and deployment platform in the cloud and are willing to essentially outsource the platform to a cloud computing provider because you want to ultimately deploy the application you are developing in the cloud. PaaS moves the development and deployment platform "into the cloud". For a good example of a PaaS, check out Bungee or Google App Engine.

PaaS is a good choice when:

You want to deploy an application into the cloud but aren't interested in dealing with a virtualized infrastructure
You want to try out an application to test adoption or interest but don't have the budget to invest in the necessary infrastructure
You would otherwise build a departmental level applications that would traditionally be served from an unmanaged server hiding under someone's desk
You're a startup whose offering will be a web based application

INFRASTRUCTURE AS A SERVICE (IaaS)

Lastly, we have Infrastructure as a Service (IaaS). IaaS is what most people think of when they hear the term "cloud computing". This model essentially leases out infrastructure resources on which applications are deployed. The applications are then able to scale up and down as necessary, on-demand, using the provider's infrastructure - saving the organization a lot of capital expenditures and operating expenses in acquiring, deploying, configuring, and managing the infrastructure.

IaaS often takes the form of virtualized computing environments, leveraging virtual images to alleviate the typical problems associated with remote hosting of applications in aligning operating systems, application servers, hardware, and other application specific details with the needs of the customer. Virtualized computing environments allow the customer to configure and deploy the application in a virtual image locally and then execute it within a remote environment without worrying about the underlying server and network infrastructure.

BlueLock and Amazon EC2 are good examples of IaaS providers.

IaaS is a good choice when:

You need a second data center for disaster recovery only but the investment in land, building, and infrastructure is too costly
You have a need for seasonal capacity but the revenue generated during those times would be diluted or erased by investing in the infrastructure to support the rushes
You want to leverage geographical based global load balancing to better serve international visitors but wish to avoid the investment in multiple data centers or hassle of co-locating servers around the globe
You want to use the cloud to host bandwidth or storage intense resources (video, images) and integrate them with your applications to offset the cost of more bandwidth or a new storage infrastructure.

Yes, cloud computing is very much part of the buzzword bingo game today (I failed to win, as you can see, but I'll try harder next time), but there are real benefits and valid reasons for looking into it right now. Don't let the hype surrounding cloud computing distract you from the potential benefits, but don't drink the kool aid too deeply, either, and commit to a model that isn't a good fit for you and your needs.

Technorati Tags: MacVittie,F5,cloud computing,infrastructure,virtualization,Google,Amazon,BlueLock,Bungee,IaaS,SaaS,PaaS,platform,software,models,buzzword bingo,internet,application,web,blog

Cloud Computing: Is your cloud sticky? It should be.

Lori MacVittie — Wed, 19 Nov 2008 11:40:02 GMT

Load balancing an application should, by now, be a fairly routine scaling exercise. But too often when an application is moved into a load balanced architecture it breaks. The reason? Application sessions are often specific to an application server instance. The solution? Persistence, also known as sticky connections.

The use of sessions on application servers to add state to web (HTTP) applications is a common practice. In fact, it's one of the greatest "hacks" in the history of the web. It's an excellent solution to the problem of using a stateless application protocol to build applications for which state is important. But sessions are peculiar to the application server instance on which they were created, and in general are not shared across multiple instances unless you've specifically achitected the application infrastructure to do so. Inserting applications into a load balanced environment often ignores this requirement, as load balancing decisions are often made based on server and application load and not on application specific parameters.

THE PROBLEM

When a client connects the first time, it's directed to Server A and a session is created. Data specific to the application that needs to be persisted over the session of the application, like shopping carts or search parameters, are stored in that session. When a client makes subsequent requests, however, the load balancer doesn't automatically understand this, and may direct the client to Server B, effectively losing the data in the session and hence breaking the application.

This affects cloud computing initiatives because an integral part of cloud computing is load balancing to provide horizontal scalability and integral part of applications is session management. Deploying an application that works properly in a test environment into the cloud may break that application because the load balancing solution utilized by the cloud computing provider isn't aware of the importance of that session to the application and, too often, the session variables are unique to the application and the provider's static network infrastructure isn't capable of adapting to those unique needs.

THE SOLUTION

When choosing a cloud provider, it is imperative that the load balancing solution used by the provider support sticky connections (persistence) so that developers don’t have to rewrite or re-architect applications for cloud deployment. "Sticky connections", or persistence in the networking vernacular, ensure that client requests are load balanced to the appropriate server on which their application session resides. This maintains the availability of the session and means applications don't "break" when deployed into the cloud or inserted into a load balanced environment.

Sticky (persistent) connections are often implemented in load balancers (application delivery controllers) by using application server session IDs to help make the decision on where requests should be sent. This results in consistent behavior and a well behaved application. The most common method of implementing sticky (persistent) connections is the use of cookie persistence. Cookie persistence inserts a cookie into the response that is later used to properly direct requests. The cookie often contains the JSESSIONID or PHPSESSIONID or ASPSESSIONID, but can actually contain any data that would allow the load balancer (application delivery controller) to identify the right application server for any given request.

ACTION ITEMS

If you are deploying applications into the cloud, or planning on doing so, and those applications are session sensitive, it is important that you determine before you deploy into the cloud whether or not your provider's solution supports sticky (persistent) connections, and how that persistence is implemented. Some solutions are not very flexible and will only provide persistence based on a limited array of variables and you will need to instrument your application to support the proper variables. Other solutions provide network-side scripting capabilities that will allow the provider - and you - to support persistence on any variable you deem unique enough to identify the proper application server instance.

Note that server FQDN (fully qualified domain name) or IP address will likely not be adequate in a cloud computing environment as these variables may not be guaranteed to be static. The unique variable should ostensibly be something application specific, as this is likely the only variables you will have control over in the cloud and the only variables guaranteed to be consistent across instances as they are brought on and off-line in response to changes in demand.

If you're currently examining the possibility of deploying applications in the cloud, make sure the cloud you choose is sticky to avoid the possibility that you'll need to rearchitect your application to get it to work properly.

Technorati Tags: MacVittie,F5,cloud computing,infrastructure,architecture,application delivery,application server,session,state,HTTP,cookie,persistence,sticky connections,server affinity,internet,web,blog,load balancing

Why routers should route and switches should switch

Lori MacVittie — Tue, 18 Nov 2008 11:38:21 GMT

Michael Vizard over at eWEEK makes an interesting prediction about the future of application acceleration: "Some day the whole concept of application acceleration will be baked into the core routers and switches we have in place."

I disagree. Routers and switches are packet-based. They focus on getting a single packet from here to there based on layer 2/3 information. Application acceleration solutions require action higher in the stack, usually layer 4 through 7; they are flow or connection based, and are often specific to the application (think CIFS, SAMBA, HTTP, etc..). The information necessary for application acceleration solutions to improve the performance of applications is just not available at the layers of the stack at which routers and switches operate.

While in the case of HTTP it is generally possible that some application acceleration features can be employed, such as manipulation of cache-oriented headers, simply because they are contained within a single packet, routers and switches don't have the awareness of that layer to be acting upon it.

But, you say, Michael is postulating that they will, someday.

Again, I'm going to disagree with that prediction. We've already tried to apply application performance-oriented functionality in routers and switches. The TOS (Terms of Service) bits (which have been redefined in recent years as Differentiated Services Code Point (DSCP)) in an ethernet header can easily carry basic information regarding the quality of service desired for a particular packet. This was initially used by routers (and still is in many implementations of WAN optimization solutions) to determine prioritization and handling of individual packets.

"Coloring TOS bits" was a euphemism used nearly ten years ago to describe the common scenario of prioritizing packets based on customer service level (gold, silver, bronze) by flipping TOS bits in the ethernet header. Problem was that most routers and switches didn't honor TOS bits, and there was no way to enforce the quality of assurance indicated by the TOS bits once the packet hit the Internet. Some routers simply didn't interpret TOS bits and ignored them.

An entire market of products arose out of the need for QoS solutions that actually worked. Bandwidth management products like Sitara and Packeteer rose from obscurity and quickly saw the need for more application specific prioritization and immediately "'moved up the stack" into layer 7 in order to provide that functionality. TOS bits were discarded by the market as a whole for being unable to provide the level of specificity required to manage applications. TOS bits have made a bit of a comeback with the advent of WAN optimization as a hot technology, but I suspect that it, too, will go the same route (sorry, no pun intended) as its forerunners earlier this century in application acceleration.

Application acceleration in a router or switch would require that the router or switch become layer 7 aware, and flow-based. If they were to attempt to apply application acceleration to XML-based data, they would have to go one step further and become a full proxy. They would have to become an application switch rather than an L2/3 device.

This is a bad idea for several reasons. First, there already exist a plethora of application switches that more than ably perform the task of application acceleration. Second, the core packet-processing hardware and software of switches and routers is optimized to pass packets, and would need to be completely reworked in order to provide application acceleration functionality. This would drive the cost of core infrastructure higher and unnecessarily add cost for enterprises who certainly only need application functionality at specific points in their architecture, not in every wiring closet on their campus. Third, the process of packet aggregation required to act upon application data rather than individual packets necessarily adds latency. In many cases it's barely noticeable at any given hop, but when it happens at every point device through which a packet must travel it adds up and will certainly be noticeable to the end-user.

Routers and switches are the core of the network, of the infrastructure that makes networks and the Internet "just work". Adding unnecessary functionality that requires a dramatic change in the architecture of these devices is simply a bad idea, financially and functionally. Routers should route, switches should switch, and application acceleration should be left to solutions specifically engineered to provide such functionality.

Technorati Tags: MacVittie,F5,router,switch,application switch,application acceleration,TOS,DSCP,packet processing,flow-based,application delivery,Sitara,Packeteer,bandwidth management,WAN optimization,WAN acceleration,internet,network,blog,eWeek,Michael Vizard

Important Information Regarding BIG-IP Support

Lori MacVittie — Mon, 17 Nov 2008 13:22:49 GMT

If you're an F5 customer running BIG-IP v4.x it's time to consider migrating to newer platforms. I know, why in the world would you want to upgrade when your BIG-IP has been running just fine for years?

Probably the most important reason is that F5 is ending the life of the 4.x release and will no longer focus resources on improving it. That means all the new improvements and innovation will continue to be put into the 9.x branch and without migrating you'll miss out on a lot of great opportunities to support new protocols, deploy new functionality and features, and take advantage of the benefits of the full proxy architecture of the 9.x release. With the fast pace at which new concepts such as cloud computing and virtualization are emerging, you'll need the most flexible, powerful, intelligent platform to keep up. That platform is 9.x.

If you haven't been considering migration of your 4.x platforms, here's just a few good reasons why you should seriously consider it now:

Improves server efficiency. Features in 9.x like TCP Express and myriad TCP optimizations drastically improve the efficiency of your infrastructure, enabling consolidation that helps with virtualization and Green IT initiatives.
New protocol support. Support for current protocols like XML and SIP is not available on the 4.x platforms, but is in the 9.x release.
Enables agility. iRules were re-architected in the 9.x release, providing greater flexibility and ability to provide unique, innovate solutions that meet the needs of your unique environment and business.
Innovative solutions. New solutions like e-mail and protocol security are available only on the 9.x platform.
Lower TCO. Newer hardware platforms are more efficient and take advantage of multi-core processors to provide even greater performance per watt but these new platforms require the 9.x release.
Broader community support. There are many more community members on DevCentral taking advantage of 9.x than 4.x.

There are many more reasons to upgrade, and you can find them at our 4.x Migration HQ. If you're still not convinced, head on over and check out some of the resources available to you that should help convince you that it's time to migrate to a new version of BIG-IP.

Your applications (and users) will thank you for it.

Technorati Tags: MacVittie,BIG-IP,migration,4.x,9.x,F5 Networks

Cloud Computing: Achieving full interconnectedness

Lori MacVittie — Mon, 17 Nov 2008 12:45:43 GMT

The saying goes that to forget (or in some cases blatantly ignore) the mistakes of the past is to be doomed to repeat them.

ODBC. BPEL. JDBC.

All three are extensible standards in the software industry that cause no end of headaches and increased management overhead for folks attempting to deal with them. None of them are interoperable; you can't use the ODBC driver for Oracle to hook up to a SQL Server database, nor you can use the same BPEL produced by one BPM solution as within another. Because they're "extensible" and that extensibility leads, almost unilaterally, to interoperability issues.

Extensibility ostensibly provides a mechanism through which vendors can offer value-added features and functionality to products making use of these "open" standards. Like SIP (Session Initiation Protocol) for VoIP (Voice over IP) solutions like Skype. Vendors and even providers of VoIP services extend SIP with proprietary, "value added" data that destroys the standard's interoperability with other SIP-enabled products.

It's like trying to shove a square peg into a round hole. You can do it, but not well, and it isn't easy.

Oh, it's great news for folks like F5 that support network-side scripting for a programmable application delivery platform that can ease the pain of trying to get two disparately SIP-enabled products to work together, like a client and the server, but it's bad in general for the industry because it inhibits adoption of standards that could, if actually standardized, become ubiquitous enough to launch new and exciting ways to leverage the technology.

That's one of the reasons when we start talking about Infrastructure 2.0 and coordination and orchestration that we have to be very careful to consider the potential ramifications. While standards are obviously a good thing, standards that result in inoperable products - from infrastructure vendors or third parties - would only make the situation worse. Proprietary extensions to "open" standards result in not only vendor lock in, but inoperable products that only serve to make more complex the already complex web of management we're suffering from today.

As Greg Ness points out in "Static Networks meet Billowing Expectations"

Connectivity intelligence enables real-time tracking and interconnectedness between networks, applications and endpoints. The lack of connectivity intelligence has driven up networking costs and heightened pressures on already tight budgets.

That interconnectedness cannot be achieved without communication first at the people layer, or layer 8 as it is often referred to. And what has to come out of that communication is consensus; consensus that any "extensible" standard must be interoperable at the core, with proprietary extensions being just that: extensions, options, add-ons, but never, never requirements for interoperability or, as Greg puts it, interconnectedness.

But as often as we mention standards at the infrastructure layer, there's another aspect of cloud computing that will eventually require standards: deployment. Even though two cloud computing providers may both be built upon a virtual computing model, that does not mean that the mechanisms used by customers to deploy those virtual images are the same. Web services might be used by one, a Web 2.0 style REST API by another, and a proprietary mechanism by a third. Without some standard for deploying applications into the cloud, customers today risk vendor lock in. Processes must be built around and using those proprietary deployment models, which results in lock-in similar to that experienced by many organizations with EAI (enterprise application integration) solutions before the advent of SOA and the ESB (enterprise service bus).

A standardized method of deploying virtual images into cloud computing environments would have additional benefits to customers if they, too, took advantage of such standards when implementing their own, private cloud computing environment. Leveraging standard methods of deployment internally means a much smoother move into the cloud if it becomes required as well as a more seamless experience when expanding from a purely private implementation to a hybrid architecture employing the use of both internal and external clouds.

And despite the fact that standards often remove vendor lock-in that providers might count on, consider this: providers, if standardized, could not only provide services to those interested in leveraging the cloud to deliver applications and services, but to other providers, as well. Leasing out unused compute cycles in much the same way as large telcos have always leased their core network to local and smaller providers.

It's a win-win-win scenario, in which everyone can benefit if we can gather consensus that it's necessary, communicate with one another to make it happen, and keep them open without proprietary extensions getting in the way.

Technorati Tags: MacVittie,F5,cloud computing infrastructure,cloud computing,virtualization,standards,SIP,ODBC,JDBC,interoperability,infrastructure 2.0,EAI,APIs,deployment,management,internet,web,blog

A client is still a client even when it's on the space station

Lori MacVittie — Fri, 14 Nov 2008 11:08:28 GMT

While I was at SD Best Practices in Boston last month I got to talk to a lot of engineers, developers, and architects about their environments and about what F5 does for application delivery.

One of the developers glibly told me he wasn't sure we could help him out because his environment was the international space station.

Yeah, how cool is that? Now that's cloud computing.

Another architect, who turned out to be a friend of a friend who I've conversed with but never met in person said the same thing, but his environment was nuclear submarines.

The Internet, she is everywhere.

There are certainly challenges with developing and delivering applications for such unique environments, but in the end a client is a client and a network is a network, even if it's over satellite links - which is most certainly the case for locations that cannot be wired or take advantage of wireless technology. What's awesome about application delivery solutions is that they are primarily asymmetric, they are a proxy to the core network that is almost always physically located in a data center somewhere on, well, earth. And on dry land.

An application delivery platform mediates, and it is physically located at the edge of the physical network. If there's a client on the space station or a nuclear submarine or a cruise ship or airplane that can communicate via a network, then an application delivery solution can indeed help the performance, security, and availability of the applications being delivered to those very remote locations.

Asymmetric solutions, of which a reverse proxy is almost always one, do not require deployment of client-side software. They are one sided, hence the use of the term asymmetric. All you need is the application delivery solution to be deployed at the edge of the physical network and voila! You can begin taking advantage of acceleration features like caching, compression, and protocol optimizations. The application delivery platform is aware of the network across which applications must traverse to reach the client, but it doesn't require that it be a certain speed, or a certain type, or anything, really. As long as it's operating on standards-based network protocols like IP, you can take advantage of the features of an application delivery solution for your environment.

In fact, an application delivery solution is perfect for address many of the problems inherent in low speed, high latency links like those used to communicate with uber remote locations like the space station or a nuclear sub because it has the intelligence to understand the network conditions unique to each link and adapt in real-time to provide the best performance possible for users accessing data and applications over that link.

And because the application delivery platform mediates between clients and applications, it can provide availability services to clients regardless of their location. In fact, because most application delivery platforms are full-proxy solutions, they are particularly adept at managing each side of the equation individually, simultaneously improving data center efficiency, reliability, and performance while adjusting proactively to the conditions currently being experienced by the client.

Being contextually aware of the unique environment from which clients access applications over a network is part of the secret sauce of application delivery solutions. By being able to understand and adapt to conditions on a per-request basis it can optimize delivery of applications for everyone - whether they are at home, at the office, on the international space station, or 20,000 leagues under the sea.

Technorati Tags: MacVittie,F5,SD best practices,development,architecture,infrastructure,application delivery,context-aware,network,client,proxy,acceleration,security,internet,satellite,space station,submarine,adapt,performance,blog

Amazing Application Acceleration: Simultaneously improve productivity, efficiency, and performance

Lori MacVittie — Thu, 13 Nov 2008 11:36:17 GMT

As a general rule, we spend far more time worrying about external appearances than we do internal. We are more concerned with our external web applications and how they look - and perform - than we are likely to regarding our intranet or internal only applications.

This blog post was interesting in that rather than encouraging folks to optimize web sites and improve end-user response time for web applications for the sake of the user experience, it focused on the relationship between page load time and impact on Google AdWords quality scores. Which is a bit different than the typical "you'll lose customers if you don't have a fast site" lecture.

By incorporating landing page load time into Quality Score Index calculation, Google is trying to improve user experience and as a by product increase the ppc advertisers conversion rate. They are hopping that because visitors do not abandon the pages because of poor web page load speed advertisers will get a higher return on their investments.

But what about internal web applications? You know, the ones customer service and call center representatives access when some poor hapless customers actually picks up the

phone and calls them? Yeah, those web applications; the ones that invariably seem to be cause of "my computer is slow today" apologies from the other end of the line, leaving the customer to wait ... and wait... and wait.

While it's easy enough to justify improving internal web applications which are indirectly customer facing based on customer satisfaction, it's just as easy to justify improving the performance of those same applications based on more quantifiable metrics: employee productivity.

The performance of employees within a wide variety of organizations who are tasked with customer service roles is almost always based on number of customers served in any given time interval. X per hour, Y per day, Z per week, etc... The efficiency of your call center or customer service departments is directly impacted by the ability of the employees to access customer information via applications, and increasingly that application is web-based. And slow.

If the average page load time of a customer service application is 10 seconds, then you necessarily need to add 10*(number of pages required on a call) to the total call time per customer. If the employee needs to access 5 pages, then you've just added nearly a minute of "wait" time to the time it takes to serve one customer. Given that most call centers like to keep their calls to a few minutes each, there's barely enough time for the customer service representative to greet the customer and ask for their identification before they've already gone over their allotted time.

Employing asymmetric application acceleration technology to improve application response time is a common prescription for performance impaired web sites. That same technology can easily be applied to internal applications, web or otherwise, as well to improve their performance and thus, load time. By leveraging technologies such as intelligent caching and compression, and optimization of the protocols (TCP, HTTP) used to deliver those applications you can simultaneously improve performance of the application, efficiency of the servers serving the application, and the productivity of your employees. Now that's multitasking!

If you can decrease the time it takes to interact with an internal web application you can decrease the amount of time spent with each customer, which leaves more time for employees to interact with more customers, improving their performance on a "customers served per hour/day/week" basis. That's an improvement in productivity as well as your bottom line as it decreases the costs associated with maintaining a customer over time, which is a key performance indicator for most organizations in which customer interaction is required.

So when you're considering improving the performance of your external web site and applications, think twice about how that same application acceleration technology just might benefit your internal web applications as well.

Technorati Tags: MacVittie,F5,application acceleration,asymmetric acceleration,customer satisifaction,efficiency,performance,response time,Google,productivity,server,http,web,internet,blog

Cloud Computing: What's stopping service-oriented clouds?

Lori MacVittie — Wed, 12 Nov 2008 16:52:03 GMT

Whenever there is a shift in architectural thinking about technology, such as is happening right now with cloud computing and virtualization, we start thinking forward, past the now, and into the future about how that technology might be leveraged. We start looking at the impact to architecture from the top of the stack to the bottom. For a company that's focused on application delivery, that means taking a good hard look at how that new technology might impact the architecture of applications.

It's been suggested that perhaps, just maybe, we'll see service-oriented clouds; that the concepts of SOA (service oriented architecture) might be abstracted even further and moved into the cloud. Basically, it's like ripping apart the n-tiered application architecture we've been building on for years and spinning each tier into the cloud; database there, presentation layer here, middleware layer over there. And not just in one place, either, but rather duplicating these "services" to provide failover, availability assurance, and context-aware access that takes into consideration variables like location and response time.

That would certainly be more efficient than current architectures which deploy entire applications as virtual images or packages in the cloud. If the database tier needs more compute resources, then just the database tier expands, rather than the entire application. That's the principle of SOA at work, as well. Decompose business processes and applications into their composite services and deploy. If one service is heavily reused, you can replicate and load balance just that service, not the entire application.

But applying SOA to the cloud may be more difficult than it sounds. While there are often discrete tiers of architecture within an application, even within a SOA-based architecture, it is still somewhat difficult to envision deploying those tiers across multiple clouds. Application infrastructure is certainly just as capable of communicating across the Internet as it is a local network, so the problem isn't so much with technology and its capabilities as it is with actually managing such a dispersed and distributed application infrastructure.

Troubleshooting such an architecture would certainly be problematic. Trying to recreate an issues for troubleshooting has always required replicating the environment as closely as possible, and it may be exceedingly difficult to even get that information in a service-oriented cloud architecture. Which data center, which database instance, which front end, which network? The variables become as overwhelming to manage as calculus appears to a third grade math student.

Further complicating the potential deployment of databases, specifically, into the cloud is the integral web of applications and systems reliant on those databases for day to day operations - both IT and business focused. Data mining, business activity monitoring, business process management, supply chain, and ERP systems are often all tied into databases around the enterprise. Move any single database and you become mired in a dependency chain that is serial, not parallel, in nature with the database being the foremost link in the chain. Access or availability to that database can bring applications - and the business - to a screeching halt.

It's that kind of risk rather than the traditional security risks and concerns surrounding offsite data storage that needs to be addressed before critical infrastructure like databases can be decoupled from the internal control that exists in the local data center. SOA addresses the architectural coupling of data and logic to applications, but it cannot adequately address at this time the need to have tightly coupled control over the availability of that data.

Applying the principles of SOA to the enterprise and the cloud can indeed have benefits in terms of reduced infrastructure costs and the ability to scale on-demand, but it still can't address the vulnerabilities inherently present from our reliance on data.

Data is the lifeblood of an organization. Applications, like the heart, keep that data pumping through the complex network of veins and arteries that are the corporate and Internet infrastructure. But like human beings even though the heart and some of the infrastructure can be outsourced, without blood (data), everything else is irrelevant.

Given our dependency on data and its availability, it's unlikely we'll see fully service-oriented clouds in the ether anytime soon. Not until we have the same guarantees of availability and access and ultimately, control, that we have in the local data center.

Technorati Tags: MacVittie,F5,cloud computing infrastructure,cloud computing,infrastructure,architecture,SOA,services,database,internet,network,application delivery,blog

Why you should not use clustering to scale an application

Lori MacVittie — Tue, 11 Nov 2008 15:05:14 GMT

It is often the case that application server clustering and load-balancing are mistakenly believed to be the same thing. They are not. While server clustering does provide rudimentary load-balancing functionality, it does a better job of providing basic fail-over and availability assurance than it does load-balancing. In fact, load balancing has effectively been overtaken by application delivery, which builds on load balancing but is much, much more than that today.

Clustering essentially turns one instance of an application server into a controlling node, a proxy of sorts, through which requests are funneled and then distributed amongst several instances of application servers. Sounds like load-balancing, on the surface, but digging deeper will reveal there are many reasons why application server clustering will not support long-term scalability and efficiency.

Aside from the obvious hardware accelerated functions provided by an application delivery controller (a.k.a. modern load balancer), there are a number of other reasons to look to options other than application server clustering when you are trying to build out a scalable, efficient application architecture.

Here are the top three reasons you should reconsider (or not consider in the first place) a scalability solution centered around application server clustering technology.

JUST LOAD BALANCING ISN'T EFFICIENT

Simple load balancing is not efficient. It uses industry standard algorithms ultimately derived from network load balancing to distribute requests across a pool (or farm) of servers. Those algorithms don't take into consideration a wide variety of factors that can affect not only capacity of an application but the performance of an application. There is no intelligence, no real awareness of the application in an application server clustering architecture and thus the solution does not utilize resources in a way that squeezes out as much capacity and performance from applications.

Application server clustering also lacks many of the features available in today's application delivery controllers that enhance the efficiency of servers and supporting infrastructure. Optimization of core protocols and reuse of connections can dramatically increase the efficiency and performance of applications and neither option is available in application server clustering solutions. That's because the application server clustering solution relies on the same core protocol stack (TCP/IP) as the application server and operating system, and neither are optimized for scalability.

LACK OF SUPPORT FOR CLOUD COMPUTING and VIRTUALIZED ENVIRONMENTS

Dynamism is the ability of your application and network infrastructure to handle the expansion and contraction of applications in an on-demand environment. If you're considering building your own private cloud computing environment and taking advantage of the latest style of computing, you'll want to consider options other than application server clustering to serve as your '"control node".

Aside from failing to exhibit the four core properties necessary in a cloud computing infrastructure (transparency, scalability, security, and application intelligence), application server clustering itself is not designed to handle a fluid application infrastructure. Like early load balancers, it expects to manage a number of servers in a farm and that the number (and location) will remain the same. Its configuration is static, not dynamic, and it is not well-suited to automatically adjusting to changing infrastructure conditions in the data center.

Virtualization initiatives put similar demands on controlling solutions like application delivery and application server cluster controllers; demands that cannot be met by application server cluster controllers due to their static configuration nature.

IT ISN'T SCALABLE

When it comes down to it there is only one reason you really need to stay away from application server clustering as a mechanism for scaling your applications: application server clustering doesn't scale well.

Think about it this way, you are trying to scale out an application by taking an instance of the application server (the one you need to scale, by the way) and turning it into a controlling node. While the application server clustering functionality is likely capable of supporting twice the number of concurrent connections as a single instance running an application, it isn't likely to be able to handle three or four times that number. You are still limited by the software, by the operating system, and by the hardware capabilities of the server on which the clustering solution is deployed.

The number of web sites that are static and do not involve dynamic components served from application servers of some kind are dwindling. Most sites recognize the impact of Web 2.0 on their customer base and necessarily include dynamic content as the primary source of web site content. That means they're trying to serve a high number of concurrent customers on traditional application server technology solutions. Scaling those applications is an important part of deploying a site today, both to ensure availability and to meet increasingly demanding performance requirements.

Application server clustering technology wasn't designed for this kind of scalability, and there's a reason that folks like Microsoft, Oracle/BEA, and IBM partner with hardware application delivery solution providers: they know that in order to truly scale an application, you're going to need a hardware-based solution. Application server vendors build application servers that are focused on building, deploying, and serving up rich, robust applications. And every one of them has said in the past, "Use a hardware load balancer to scale."

If the recommendation of your application server vendor isn't enough to convince you that application server clustering isn't the right choice for scaling web applications, I don't know what is.

Technorati Tags: MacVittie,F5,clustering,load balancer,load balancing,application delivery,infrastructure,architecture,virtualization,cloud computing infrastructure,ibm,microsoft,application server,oracle,bea,hardware,software,scalability,blog,web,internet

Infrastructure 2.0: Aligning the network with the business (and the rest of IT)

Lori MacVittie — Mon, 10 Nov 2008 16:23:25 GMT

When SOA was the hot topic of the day (not that long ago) everyone was pumped up about the ability finally align IT with the business. Reusability, agility, and risk mitigation were benefits that would enable the business itself to be more agile and react dynamically to the constant maelstrom that is "the market".

But only half of IT saw those benefits; the application half. Even though pundits tried to remind folks that the "A" in SOA stood for "architecture", and that it necessarily included more than just applications, still the primary beneficiary of SOA has been applications and through their newfound agility and reusability, the business.

The network has remained, for many, just as brittle and unchanging (and thus not agile) as it has ever been, mired in its own "hardwired" architectures, unable to flex or extend its abilities to support the applications it is tasked with delivering. And no one seemed to mind, really, because the benefits of SOA were being realized anyway, and no one could really quantify the benefits of also rearchitecting the network infrastructure to be as flexible and agile as the application infrastructure.

But along comes virtualization and cloud computing, and an epiphany was had by many: the network and application delivery infrastructure must be as agile and flexible as the application infrastructure in order to achieve the full measure of benefits from this newest technology. Without an application delivery infrastructure that is as able to adapt dynamically the infrastructure is the wall between a successful deployment and failure.

In order to truly align the network with the business - and the other half of IT - it becomes necessary to dig deeper into the network stack and really take a look at how you're delivering those agile applications and services. It's important to consider the ramifications of a static, brittle delivery infrastructure on the successful deployment and delivery of virtually hosted applications and services. It's necessary to look at the ability of your delivery infrastructure and evaluate its abilities in terms of reusability, scalability, and dynamism.

Analyst and research firm Gartner said is as succinctly as it can be said: You Can't Do Cloud Computing Without the Right Cloud (Network) and the same holds true for virtualization efforts. You can't efficiently deliver virtualized applications without the right network infrastructure.

Until your network and application delivery infrastructure is as agile and reusable as your application infrastructure you won't be able to align all of IT with the business.

Until you have a completely agile architecture that spans all of IT, you're not truly aligned with the business.

Technorati Tags: MacVittie,F5,cloud computing,infrastructure 2.0,SOA,agile,reuse,Gartner,align,network,application delivery infrastructure,application,architecture,network-side,internet,cloud,web,blog