Posts

How Rich Internet and Smartphone Apps are Driving a Return to Client-Server Architecture

Solace recently announced a new network card that can boost the capacity of each Solace’s appliance to 80Gbps of bandwidth. As more companies embrace real-time computing and “big data” fueled by information flowing between mobile devices, sensors and social networks, this kind of capacity will enable some seriously cool innovation. But I believe there’s even more to it than that – I think this kind of massive capacity will influence the very nature of enterprise applications.

Think about the fact that smartphones didn’t exist just ten years ago. Think about the server-side ramifications of all that recent change, and where we are today. Having a hardware-based HTTP termination point, WebSocket wireline support, higher connection density and using messaging as a communication paradigm even over HTTP is allowing front end applications to become much more scalable, faster, and most importantly easier and more intuitive.

Lets examine this from an application developer’s perspective to see if we can extrapolate what’s next.… Read the rest

Why Horizontally Scaling Message Brokers isn’t All it’s Cracked up to Be

When it comes to increasing the capacity of IT systems you can either scale “vertically” by increasing the power or storage of a given device or piece of software, or “horizontally’ by adding new devices or instances of that software.

interbroker-comms-diagramOne of the biggest problems with increasing the capacity of a software-based messaging platform by adding brokers is the communication that inevitably needs to happen between brokers. When clients or applications connected to one broker need to communicate with an application that’s connected to another broker, you end up sacrificing some of each broker’s capacity to that inter-broker traffic, leaving less available for client communications. In fact, this problem increases exponentially as you add more brokers, so the return you get by adding each new broker is less and less.

focused-overload-diagramThe next challenge that IT personnel face when horizontally scaling software-based message brokers is that of capacity planning. With discrete message brokers serving unique sets of clients and instances of applications, each broker must meet the demands placed on it by clients and applications alike with its own available capacity.… Read the rest

Apples, Oranges, and WAN Optimization Appliances

iStock_000002646362XSmall-300x199WAN optimization is a crowded and confusing space full of solutions that all sound alike and promise magic 10-20x performance increases. But when you look at what each solution actually does, they are often completely different and your mileage may vary, so it’s important to understand the various approaches and apply the right tool to each challenge.

I recently presented at QCon in San Francisco on the topic of “Distributed Data Fabrics and Hardware WAN Optimization“. If you have never been to a QCon event, note that it is a geekfest and the attendees have zero tolerance for marketing hype. Developers and architects come to QCon to learn, share, and socialize amongst their peers, not to listen to sales pitches. I like the vibe at QCon and think it’s very much in line with the kind of content that works on a tech blog, rather than a corporate blog, so I’d like to expand the audience of my thoughts here.… Read the rest

Deconstructing Kafka

iStock_000020380404XSmall-300x199A colleague of mine asked me to “compare and contrast” Solace with Kafka. Apache Kafka is an open source distributed messaging system, written by LinkedIn specifically for activity stream and log processing. As a detail oriented techie, I hate it when someone asks me a one sentence question that requires a two page answer. Sometimes I wish I could feel good about myself while spouting weasel words like “robust”, “scalable”, and “carrier class” to explain why my employer’s products are different. I am just not that guy. Instead, I got out my green highlighter and my reading glasses and spent the afternoon dissecting the excellent whitepaper written by Kreps, Narkhede, and Rao.

First it’s important to introduce what constitutes large scale in the log processing space and why there is a need for solutions like Kafka. These are some log processing metrics quoted in the paper.… Read the rest

The Fleet of Buses

iStock_000002004120XSmall-300x199The message bus, information bus,   and enterprise service bus concepts are popular, and now old enough, that most large organizations find they have an entire fleet of such buses. Complicating matters is the fact that they tend to be heterogeneous in version and vendor and much of this middleware is really embedded legacy application infrastructure that cannot be easily changed. So how do you modernize your fleet of old buses?

1 ) Federate: Get them talking to one another so that they benefit from the network effect that returns greater value as more endpoints are inter-connected

2) Accelerate: Get rid of the road bumps and bottlenecks slowing down the real-time flow of information. Modern data movement is much lower latency, globally distributed, with active/active  replication into in-memory datagrids and distributed cache.

3) Rejuvenate: Remodel a few key flagship implementations to take advantage of the new world of streaming big data, real-time analytics, mobile sensors, M2M, etc.… Read the rest

Topic Namespaces and Governance

In my last article I introduced the power and use of topics within an enterprise messaging platform and provided some information about how Solace’s appliance utilizes topic names to deliver information to interested parties.  In the second part of the series I want to provide suggestions about how organizations can leverage these features in a consistent way to maximize the value from their enterprise messaging capabilities.  Additionally we’ll focus on considerations and suggestions when designing a governance model to make sure the best practices are leveraged whenever possible.  These elements help drive adoption, reduce total cost of ownership and accelerate the learning curve as new developers interact with this technology.

Who Controls the Topic Namespace?

The importance of this question is directly proportional to the size of the organization and project it’s being asked about.  If you’re the sole person on a project performing development, SysAdmin, and Help Desk Guru tasks, then the answer should be obvious.  … Read the rest

Controlling Information Flow with Topics

First things first:  What is a Topic?

Publish-Subscribe (PubSub) architectures are designed to create a separation between data publishers and consumers.  Using this approach rather than publishers sending data to specific consumers, as you would when sending an email, data is sent with tags that allow for consumers to find the information based on interest.  The data tagging utilized by many middleware providers is called a Topic.  For consumers to receive messages, they need to register their interest in one or more topics – like choosing to follow someone on Twitter.  When dealing with Solace Messaging Appliances, the appliance acts as the broker that keeps track of everyone’s interests, and does the high performance matching to make sure that everyone gets each message that they are interested in.

Topics & Message Routing

A topic is a string or a sequence of strings separated by a delimiter.  Different Messaging systems use different delimiters, the most common being dots (.) or slashes (/). … Read the rest

Approximating Queue Semantics in Non-Persistent Messaging

Solace provides the ability to approximate queue semantics within the non-persistent publish and subscribe environment. This is useful for a number of reasons –

  1. It operates at rates an order of magnitude higher than persistent messaging, i.e. a million messages per second rather than 100k messages per second.
  2. It allows load balancing of requests across a number of instances providing services to the application, e.g. entitlements checking, grid processing engines.
  3. It allows fault tolerance of services to the application, e.g. entitlements checking, grid processing engines.
  4. It allows JMS users to effectively build applications that do not want persistence, or durability, but that do want to use queue semantics rather than topics (JMS does not allow you to name temporary queues).
  5. On application removal there is no state kept within the message transport domain

Deliver-To-One

Figure 1: Direct Messaging – DTO Load Balancing from a Topic

Deliver-To-One (DTO) is a Solace Extension to the standard Publish and Subscribe pattern.… Read the rest