Lori is a Technical Marketing Manager at F5 Networks, an experienced software developer, author, and technology editor, a geek, a mom, a wife, and an avid RPG gamer.
Cloud computing promises customers the ability to deliver scalable applications on-demand without the overhead of a massive data center. The visibility - and flexibility as well as control - you have into and over the cloud computing environment depends on whether the provider you select offers an opaque or a transparent cloud computing environment.
In reading through ZapThink's latest post regarding the "Great ESB Controversy of 2008" it occurred to me that it is quite possible, and probably likely, that the issue of ESB use primarily revolves around whether you're doing SEA or SOA.
Yes, I know. You've never heard of "SEA" before. That's because I just made it up to describe the difference between a service-enabled architecture and a service-oriented architecture. And there is a difference.
Comments [0]
An application delivery controller (ADC) essentially acts a reverse proxy. That means that client requests interact with the ADC, and the ADC interacts with web and application servers on the client's behalf. This mediation offers the chance to implement acceleration, availability, and security features without requiring changes to existing applications.
There are many, many more features in an ADC that provide significant value. These eight capabilities are the most commonly employed features in reverse-proxy application delivery solutions that provide immediate benefits to web applications, and all can be used without modifying applications or the servers on which they are deployed.
Comments [0]
Forrester Research recently conducted a survey on virtualization, citing server consolidation as one of the primary drivers behind the 73% of enterprises already or planning on implementing virtualization technology. But virtualization, particularly operating system virtualization, assumes you have additional cycles on servers to spare. In some cases, that's just not true. Your application servers are working as hard as they can to serve up your applications and virtualizing them isn't going to change that fact.
That's one of the secrets of application acceleration. Some of the "tricks of the trade" that make applications faster include techniques that reduce the load on application servers which means, ultimately, that you can consolidate and use fewer servers while still improving performance.
There are three primary mechanisms used by application acceleration technologies that can help you reduce the burden on servers and thus consolidate your application infrastructure: offloading, optimization, and acceleration.
Let's say you have 10 servers in a server farm, each with a total capacity of 1000 concurrent HTTP requests, and that you need to support at least 10,000 concurrent HTTP requests. You're full up. In order to consolidate you're going to need to maintain support for those 10,000 concurrent HTTP requests with fewer servers.
Let's take a look at how application acceleration solutions can enable you to meet that goal.
Comments [0]
Alistair Croll has a great post on GIGAOM discussing how networking vendors will need to change in order to support a cloud computing infrastructure.
He outlines two options for networking vendors that will keep them relevant in a cloud computing environment.
In option number one he postulates that virtual appliances are the way to go, that the "pendulum swings back to software". Option number two revolves around sales strategy, and he suggests that networking vendors will need to sell to the providers of the cloud. That makes sense to me. If you want to be a part of the cloud computing infrastructure then you should probably sell to the people building those infrastructures. Option #2 is not really a question of technology; Alistair is somewhat mixing his metaphors, as it were, with these two options, so I'm going to focus on the technology because honestly, I couldn't sell water to a man dying of thirst.
The
goal of the virtual appliance (option #1) is to provide networking (routing,
firewalls, load balancing) to customers of the cloud in a way that is (a) easy
for cloud computing providers to provision and de-provision on-demand and (b)
segregates management and configuration on a customer by customer basis. When
Customer A wants a load balancer, for example, the cloud computing provider
needs to provision the resource and associated management to the customer in an
automated way. Hence Alistair's choice of a virtual appliance, as it is well
established that within the right framework, with the right tools, a virtual
image of any application can be easily provisioned and de-provisioned. 
While the virtual appliance is certainly one way in which this can be accomplished, there is another option that doesn't introduce the overhead of virtualization into the equation and maintains the performance gains made in hardware in the networking world.
Comments [0]
I read with interest an article on port knocking as a mechanism for securing SOA services on CIO.com. If you aren't familiar with port knocking (I wasn't) then you'll find it somewhat interesting.
From Nicholas Petreley's "There is More to SOA Security Than Authorization and Authentication"
For the sake of argument, let's say you have an SOA server component for your custom client software that uses port 4000. Port knocking can close off port 4000 (and every other port) to anyone who doesn't know the "secret method" for opening it. Any cracker who scans your server for open ports will never discover that you have an SOA service available on that port. All ports will appear unresponsive, which makes your server appear to offer no services at all.
Ironically, your client gains access to port 4000 in a way similar to the way crackers discover existing open ports. As described above, port scanners step through all available ports sequentially, knocking on each one to see if there's an answer. By default, a port knocking-enabled firewall never answers on any port. The secret to unlocking any given port is in the non-sequential order your client uses to check for open ports.
For example, your client software might check ports 22, 8000, 45, 1056, in that order. Each time, there will be no answer. But the server will recognize that your device —running the legitimate client software—knocked on just the right ports in the right order, like the key to a combination lock. Having gotten the right combination, the firewall will open port 4000 to the authenticated device and only to that device. Port 4000 will continue to look closed and unused to the rest of the world.
A great description is also available here along with client and server side software.
At first I thought "this is way cool". Then I thought about it some more and thought "Wow. That's going to destroy performance, increase development and support costs, and put a big target on your services."
Comments [0]
Outside of the technology world a lot of products are billed as "one size fits all". Anyone who's purchased such a product generally knows, no, no they don't. They're close, but never a truly good fit.
Inside the technology world we know better. Software and solutions are never a "one size fits all" proposition, that's why so many business software solutions are "customizable": ERP (enterprise resource planning), CRM (customer relationship management), workflow, automation, and portals. Just about every software solution you can purchase these days takes a customizable approach to actually meeting the needs of the business.
The goal of SOA (service oriented architecture) is to align IT more closely with the business. What that really means is enabling, or empowering, the business to meet its goals in a dynamic, fast-paced environment. Agility, or flexibility, is one of the three primary goals of business and it's one of the most often touted benefits of a well designed SOA. A well designed SOA brings to IT and the business the same benefits as a customizable, packaged software solution: flexibility.
Comments [0]
I'm going to give you an engine low to the ground.
An extra-big oil pan that'll cut the wind underneath you.
That'll give you more horsepower.
I'll give you a fuel line that'll hold an extra gallon of gas.
I'll shave half an inch off you and shape you like a bullet.
When I get you primed, painted and weighed...
...you're going to be ready to go out on that racetrack.
You're going to be perfect. (From the movie: Days of Thunder)
In the monologue above, Harry Hogge, crew chief, is talking to the framework of a car; explaining how it is that he's going to architect her for speed. What I love about this monologue is that Harry isn't focusing on any one aspect of the car, he's looking at the big picture - inside and out. This is the way we should architect web application infrastructures for speed: holistically and completely, taking the entire application delivery infrastructure into consideration, because each component in that infrastructure can have an effect - positive or negative - on the performance of web applications.
Analyst firm Forrester recently hosted a teleconference (download available soon) on this very subject entitled "Web Performance Architecture Best Practices." In one single slide analysts Mike Gualtieri and James Staten captured the essence of Harry's monologue by promoting a holistic view of web application performance that includes the inside and outside of an application.
Comments [0]
IPv6 was supposed to eliminate NAT (Network Address Translation). But in order to make the transition from IPv4 reasonable and less painful, it's being added to IPv6. It's intended use in being included in IPv6 is to create gateways that bridge between IPv6 and IPv4 while the transition occurs.
The IETF is not thrilled however. It's description of how it feels about NAT and the necessity to include it make it sound like school-children forced to allow that kid to play in their game of kickball. And then they put him in far right field. And I mean far right field so it's obvious what they think of him.
This Network World article describes NAT as "much maligned" and reminds us that purists hate it for breaking the end-to-end communication model on which the Internet was designed.
From the article:
NAT is deployed in routers, servers and firewalls, and it adds complexity and cost to enterprise networks. Internet purists hate NATs because they break the end-to-end nature of the Internet; this is the idea that any end user can communicate directly to another end user over the Internet without middle boxes altering their packets.
I'm guessing purists hate a whole lot of technologies because there are a ton of other technologies and products that are essentially "middle boxes altering packets."
Comments [0]
There is an interesting war being fought in the blogosphere over the use (or overuse) of ESB (enterprise service buses) to build out a SOA (service oriented architecture). It certainly appears that Dave Linthicum is taking on the role of Leonidas and the Spartans at the battle of Thermopylae while everyone else is on the side of Xerxes and the Persians.
Dave is defending his view that ESBs are overused and often, apparently, misused against a host of ESB and SOA focused bloggers like Joe McKendrick and Jeff Schneider.
But everyone is talking in abstractions, and no one's really giving anyone a good checklist of when to use an ESB or when to avoid them. No one seems to be looking at why people are or aren't using ESBs and getting to the root of the question - when are they appropriate for use in a SOA and when are they simply being implemented for the sake of being implemented?
So when should you consider implementing an ESB as part of your SOA?
Comments [0]
Comments [0]