iControl

The death of SOA has been greatly exaggerated

Lori MacVittie — Fri, 21 Nov 2008 11:09:37 GMT

Amidst the hype of cloud computing and virtualization have been the publication of several research notes regarding SOA. Adoption, they say, is slowing.

Oh noes! Break out the generators, stock up on water and canned food!

An article from JavaWorld quotes research firm Gartner as saying:

The number of organizations planning to adopt SOA for the first time decreased to 25 percent; it had been 53 percent in last year's survey. Also, the number of organizations with no plans to adopt SOA doubled from 7 percent in 2007 to 16 percent in 2008. This dramatic falloff has been happening since the beginning of 2008, Gartner said.

Some have reacted with much drama to the news, as if the reports indicate that SOA has lost its shine and is disappearing into the realm of legacy technology along with COBOL and fat-clients and CORBA.

Not true at all.

The reports indicate a drop in adoption of SOA, not the use of SOA. That should be unsurprising. At some point the number of organizations who have implemented SOA should reach critical mass, and the number of new organizations adopting the technology will slow down simply because there are fewer of them than there are folks who have already adopted SOA.

As Don pointed out when this discussion came up, the economy is factoring in heavily for IT and technology, and the percentages cited by Gartner are not nearly as bad as they look when applied to real numbers. For example, if you ask 100 organizations about their plans for SOA and 16 say "we're not doing anything with it next year" that doesn't sound nearly as impressive as 16%, especially considering that means that 84% are going to be doing something with SOA next year.

As with most surveys and polls, it's all about how the numbers are presented. Statistics are the devil's playground.

It is also true that most organizations don't consider that by adopting or piloting cloud computing in the next year that they will likely be taking advantage of SOA. Whether it's because their public cloud computing provider requires the use of Web Services (SOA) to deploy and manage applications in the cloud or they are building a private cloud environment and will utilize service-enabled APIs and SOA to integrate virtualization technology with application delivery solutions, SOA remains an integral part of the IT equation.

SOA simply isn't the paradigm shift it was five years ago. Organizations who've implemented SOA are still using it, it's still growing in their organizations as they continue to build new functionality and features for their applications, as they integrate new partners and distributors and applications from inside and outside the data center. As organizations continue to get comfortable with SOA and their implementations, they will inevitably look to governance and management and delivery solutions with which to better manage the architecture.

SOA is not dead yet; it's merely reached the beginning of its productive life and if the benefits of SOA are real (and they are) then organizations are likely to start truly realizing the return on their investments.

Technorati Tags: MacVittie,F5,SOA,cloud computing,virtualization,integration,Gartner,JavaWorld,web services,architecture,application delivery,application,blog

Automating scalability and high availability services

Lori MacVittie — Wed, 15 Oct 2008 12:37:16 GMT

There are a lot of SOA governance solutions out there that fall into two distinct categories of purpose: one is to catalog services and associated security policies and the other is to provide run-time management for services, including enforcement of security and performance-focused policies.

Vendors providing a full "SOA Stack" of functionality across the service lifecycle (design, development, testing, production) often integrate their disparate product sets for a more automated (and thus manageable) SOA infrastructure. But very few integrate those same products and functionality with the underlying network and application delivery infrastructure required to provide high-availability and scalability for those services.

The question should (and must) be asked: why is that?

Today's application delivery infrastructure, a.k.a. application delivery controllers and load-balancers, are generally capable of integration via standards-based APIs. These APIs provide complete control over the configuration and management of these platforms, making the integration of application delivery platforms with the rest of the SOA eco-system a definite reality.

Most registry/repository solutions today offer the ability of external applications to subscribe to events. The events vary from platform to platform, but generally include some commonalities such as "artifact published" or "item changed". This means a listening application can subscribe to these events and take appropriate action when an event occurs.

1. A new WSDL describing a service interface (hosted in the service application infrastructure) is published.

2. The listening application is notified of the event and retrieves the new or modified WSDL.

3. The application parses the WSDL and determines the appropriate endpoint information, then automatically configures the application delivery controller to (a) virtualize the service and (b) load balance requests across applicable servers.

4. The application delivery controller begins automatically load-balancing service requests and providing high-availability and scalability services.

There's some information missing that has to be supplied either via discovery, policy, or manual configuration. That's beyond the scope of this post, but would certainly be a part of the controlling application.

Conceptually, as long as you have (a) a service-enabled application delivery controller and (b) an application capable of listening for events in the SOA registry/repository, you can automate the process of provisioning high-availability and scalability services for those SOA services.

If you combine this with the ability to integrate application delivery control into the application itself, you can provide an even more agile, dynamic application delivery infrastructure than if you just used one concept or the other. And when you get right down to it, this doesn't just work for SOA, it could easily work just as well for any application framework, given the right integration.

There already exist some integration of application delivery infrastructure with SOA governance solutions, like AmberPoint, but there could be more. There could be custom solutions for your unique architecture as well, given that the technology exists to build it.

The question is, why aren't folks leveraging this integration capability to support initiatives like SOA and cloud computing that require a high level of agility and extensibility and upon which the ROI depends at least partially on the ability to reduce management costs and length of deployment cycles through automation?

It's true that there seems to be an increasing awareness of the importance of application delivery infrastructure to architecting a scalable, highly available cloud computing environment. But we never really managed to focus on the importance of an agile, reusable, intelligent application delivery infrastructure to the success of SOA.

Maybe it's time we backtrack a bit and do so, because many of the same architectural and performance issues that will arise in the cloud due to poor choices in application delivery infrastructure are the same as those that adversely impact SOA implementations.

Governance in the Cloud

Reliability does not come from SOA Governance

Building a Cloudbursting Capable Infrastructure

The Next Tech Boom: Infrastructure 2.0

Technorati Tags: MacVittie,F5,SOA,cloud computing,governance,iControl,automation,virtualization,application delivery,web services,internet,web,infrastructure

How to instrument your Java EE applications for a virtualized environment

Lori MacVittie — Tue, 30 Sep 2008 11:49:11 GMT

If you're excited about the automation capabilities of cloud computing and virtualization, you are going to love this solution. In a virtualized environment where applications can ostensibly be popping up all over, and applications are no longer tied to specific servers, there is a need to automatically manage these application instances in a high-availability (load balanced) environment. What you need is the ability to automagically add and remove application instances from the application delivery controller (load balancer) so you don't have to worry about tying those applications down, which could reduce the benefits typically associated with virtualization.

If you aren't going to a fully virtualized and automated data center, you might be happy to know that you can still reap the benefits of this automated solution. Not only is this solution perfect for a virtualized environment, it's also just as great for a non-virtualized environment for automating availability of applications. Truth be told, the application and the solution doesn't care (nor should it) whether it's running in a virtual image or not; it merely "is".

In a nutshell, when an application initializes, it adds itself to the appropriate application pool on the application delivery controller. When the application is destroyed, it removes itself. This means no matter where the application instance is living - in a virtual image, in a different servlet container, on a new server - it will automatically be "discovered" and immediately become part of the high availability pool of servers.

iControl, F5's service-enabled API providing configuration and management control of its solutions, can be used from within your Java EE application to enable automation of pool management on a BIG-IP application delivery controller.

This solution uses the Java Servlet 2.3 ServletContextListener interface. The ServletContextListener interface can be used to listen and react to a variety of servlet events, including application lifecycle. In order to automate the addition and removal of an application from the appropriate BIG-IP pool, we'll be listening for two events: contextInitialized and contextDestroyed. In the former, we'll add the application to the appropriate pool and in the latter, we'll remove it automatically.

This proactive approach to managing applications managed by BIG-IP LTM (Local Traffic Manager) also ensures that requests are not caught in between a monitor's health check interval, which can result in either an error or a second connection as part of a retry event within an iRule. This improves performance by ensuring that only active applications receive requests, and reduces connection attempts that can improve the efficiency of high-volume applications.

This is also an excellent method of automating availability for applications for which synthetic monitors are problematic.

You can read about the full solution with code in this article. Yes, they actually let me code from time to time.

Happy coding!

Technorati Tags: MacVittie,Java,Servlet,iControl,F5,BIG-IP,context,iRules,development,architecture,automation,management,cloud computing infrastructure,virtualization

iControl and Web 2.0

Lori MacVittie — Tue, 13 May 2008 12:05:01 GMT

There's a lot of things that BIG-IP can do to improve the reliability, scalability, and performance of Web 2.0 applications. But there are always two sides to every story, and so it is with BIG-IP and Web 2.0, or specifically, AJAX.

This latest article, Getting Started with iControl and AJAX, offers advice and code to get you started building a custom AJAX-based dashboard for BIG-IP.

Imbibing: Coffee

Technorati Tags: MacVittie,development,iControl,BIG-IP,F5,AJAX,Web 2.0

iControl and PHP: Updated

Lori MacVittie — Fri, 09 May 2008 20:05:13 GMT

I'm working on something else that's sort of related to this subject and noticed that rpaan polished the PHP code for this article on using PHP and iControl. It's nice. Great stuff, rpaan, and THANKS!

Imbibing: Water

Technorati Tags: MacVittie,iControl,PHP,development

What is iControl? And more importantly, what can I do with it?

Lori MacVittie — Tue, 19 Feb 2008 17:42:49 GMT

Over the past three weeks Don and I have had a lot of time to chat whilst making the trek back and forth between home and the hospital where the newest member of our family was keeping residence. Mostly we talked about our new son and speculating as to when he might be allowed to come home (Feb 17), but as is our wont we often ended up talking about work. That's one of the benefits of working "together" and in the same field, at least we think so.

One of those discussions revolved around iControl and the fact that it's really not as well known as iRules. iRules is, of course, incredibly cool and because it's a dynamic, programmatic mechanism for manipulating traffic it's more, well, in your face than iControl.

iControl is also a dynamic, programmatic mechanism - it's just focused on management of F5's BIG-IP. iControl is a Web Services, a.k.a. SOA, enabled API that allows developers and admins control over their BIG-IP. Because it's SOA, there's no limitation on the programming - or scripting - language you can use to create your own customized management programs for a BIG-IP. PERL, Java, .NET, C/C++, Python, PHP. The power of web services means that iControl can be utilized via just about any language you're comfortable with.

Just knowing that iControl is a management API for BIG-IP is helpful, but the real question is almost always "but what can I do with it?" Well, if you want to see real examples, you can check out the iControl CodeShare here on DevCentral. If you're just looking for ideas, well, that's hard primarily because there's so many options and ideas are limited only by your own imagination.

You can create virtual servers, real servers, and pools of servers. You can change the status of a pool - enable or disable it - at will. You can write a script that automatically moves traffic from one server to another based on recurring maintenance windows. You can create iRules on the fly and apply them, or change the way traffic is handled with the click of a button. You can write a script that can be incorporated into a web dashboard to automatically monitor the status of objects such as virtual and real servers. You can build a real-time graphic chart of current connections and throughput rates. You can do just about anything you can think of.

There's more to iControl than just management in the sense that you can use it to integrate your BIG-IP with applications and even other devices. Using iControl you can integrate BIG-IP with your application and make decisions based on real-time conditions that are application or process specific. Need an example? Well, say your application processes things. And let's say that you've got a service level agreement - or customer guarantee - that says you will process a thing in a specified period of time. You know that some things require longer to process than others, so you want to make sure that if a single server is handling one of those things that it doesn't try to process another thing until it's done. You could certainly write an iRule to recognize the situation and direct requests accordingly, but you could also do that using iControl from within your application. In many cases, it's actually more effecient to use iControl from within your application because it may be necessary to base your decision on information that can't be accessed via iRules, such as a information coming from a database lookup.

Integrating applications and other devices using iControl is something we do ourselves and that some of our partners do as well. For example, we've got a plug-in for Oracle's Enterprise Manager and AmberPoint's SOA governance solution. To make using iControl even easier, our gurus on the DevCentral team have created a set of Java wrappers for iControl as well as .NET and Java assemblies. I could go on and on about iControl because the possibilities are nearly infinite, but that would turn this blog post into a book.

So instead of reading my ideas, check out the iControl documentation on DevCentral and the forums for more ideas from our DevCentral team and real users of iControl and BIG-IP on how iControl can fit into your environment and make your life easier.

Imbibing: Mountain Dew

Technorati tags: MacVittie, F5, iControl, integration, management, BIG-IP, programming, SOA, web services, API

Syndicate your BIG-IP

Lori MacVittie — Thu, 22 Mar 2007 22:04:41 GMT

Enhancing visibility through iRules and RSS

The business folks in your organization like to have visibility into every aspect of the business, including the disparate pieces of infrastructure that deliver the applications crucial to the company's bottom line. There are a number of ways in which you can provide visiblity into the delivery of those applications via BIG-IP.

Yes, you could export logs and create charts in Excel, but that's not very real-time. You could also use the administrative domain features in v9.4 to give business owners view-only access to your BIG-IP so they can view the statistics themselves.

Another possibility (and much cooler in my opinion) is to provide an RSS feed via an iRule. Yes, I'm saying you can syndicate the performance of your BIG-IP. This provides an easy mechanism through which business and management stakeholders can monitor the performance and delivery statistics of their mission critical applications without you generating reports or requiring the stakeholders to bother IT for their credentials yet again.

How to Set up an RSS Feed for your BIG-IP

First, find an appropriate URI that is unique that can return the RSS feed on your virtual server. For example, I chose "/rss". Then collect the appropriate statistics from the stats profile and craft your RSS response. If you aren't familiar with RSS there are number of sites that provide good examples for the most popular RSS format specifications (0.9, 0.91, 2.0). I like 2.0, but that's a matter of (sometimes hotly debated) opinion.

Here's a simple example of an RSS 2.0 feed:

<?xml version="1.0"?>

  <rss version="2.0">

      <channel>

         <title>BIG-IP Statistics</title>

         <link>http://myvirtualip.com/</link>

         <description>Statistics for My Virtual Server</description>

         <item>

            <title>Current Connections</title>

            <description>12345</description>

         </item>

         <item>

            <title>Total Requests</title>

            <description>456781919</description>

         </item>

      </channel>

   </rss>

You'll of course want to modify the titles, and if you really get crazy RSS 2.0 includes the ability to embed images as well. You can use iRules to gather virtual server specific information such as its name, active members, etc... as well, so you can really customize the heck out of the feed.

You can put whatever statistics you think are relevant from the statistics profile, and just because we like flexibility you can even create custom statistics profiles and report on more application specific statistics. Joe wrote a great tech tip on retreiving statistics from your BIG-IP using iRules that is a great place to start checking out the possibilities. His examples include the ability to reset the statistics, and outputs in HTML, but the concept is the same.

This iRule itself is pretty simple, Joe's includes the ability to process several reporting-specific URIs so you could modify his example to support multiple syndication formats based on the URI.

when HTTP_REQUEST {

   set uri [HTTP::uri]

   if { $uri starts_with "/rss"} {

       # get the statistics you want to report

       HTTP::respond 200 " ** output the RSS format of choice with the statistics ** "

Go on, syndicate your BIG-IP. Your enterprise stakeholders will thank you for it.