In this edition of Solace Says, I interviewed Jonathan Schabowsky of Solace’s office of the CTO, who recently wrote a blog post about event-driven microservices that’s turned out to be quite popular. In that post, and this video, Jonathan describes the characteristics most microservices share, what they’re commonly used for, and how they share information with REST and/or messaging technology.
Most people starting with Solace will probably use our administration GUI, SolAdmin. SolAdmin is an excellent tool, but as with any GUI, once you get used to the concepts and procedures of using Solace message routers and gain experience, you may want to use a Command Line Interface (CLI) for some tasks.
Using the SolOS CLI has some advantages:
- Its structure closely matches that of the SEMP management interfaces and associated APIs, so those familiar with the CLI will find programmatic management easier;
- It is possible to create replay files with CLI, which can automate tasks – such as moving a Message VPN configuration from test through UAT to production environments;
- For some tasks, the CLI is faster.
I personally use a mixture of the CLI and SolAdmin. I find VPN bridges tricky in the CLI but a cinch with SolAdmin, while I’d rather use the CLI for redundancy configuration and initial setup. … Read the rest
Microservices are extremely popular these days, and for good reason. They provide a blueprint that makes it easier for developers to repeatedly create robust and scalable applications. While there is no official industry-adopted definition of microservices, there are some generally accepted attributes that make up a microservice:
- Small and single in purpose
- Communicate via technology agnostic protocols
- Support continuous integration
- Independently deployable.
Many of these attributes are interrelated – since services are to be small and single in purpose, they must communicate with each other to provide real business value, and to be independently deployable they need to be small and single in purpose. While each of these are vital attributes, the ability to communicate without being tightly coupled to one another is a critical aspect of microservices architecture.
Smart Endpoints and Dumb Pipes
Openness in technology is an element of interactions. It’s about allowing access to whatever information is needed to take appropriate action, without tying that access to a single technology or vendor so you can always pick the right solution for each problem.
Of course, open has become a heavily loaded term. A few years ago I did a talk on the overloaded nature of the word open, and I suspect you could add additional examples to the list therein. But in nearly every case, openness in communications benefits everyone.
The ability to move and share information is the lifeblood of many corporations – and some would say all of them these days thanks to the advent of analytics, IoT and the cloud. As technology evolves, that movement of information will increase in both ubiquity and value.
I recently ran across an opinion piece with an attention grabbing headline: Did Amazon Just Kill Open Source?
The author’s primary argument is that the industry is moving too fast for good architecture to take shape around open standards like inter-application protocols and common APIs (which take time and collaboration). He makes his case by pointing out that well thought out integration layers were a hallmark of early open source projects like Linux.
The article also layers in the idea that a glut of overlapping open source projects that don’t have clean integration layers has benefitted Amazon’s “full stack” cloud approach, which is easier for developers than sifting through many similar choices and tackling integration on their own.
His points are correct, in some contexts, but they have little to do with problems with open source as a concept or market model. Open source is here to stay. Even if managed cloud services replace some of what people do today with open source code, there will always be other aspects of any project that will inevitably come from the community.… Read the rest
Many IoT applications will see very large numbers of clients connecting to Solace message routers via insecure public networks. For example, vehicles in a fleet may communicate with the company’s Solace routers over the Internet using MQTT. In such a scenario the company’s system administrators may want to implement Access Control Lists (ACLs) so each vehicle can only publish to topics containing their own MQTT client-username. This would prevent, for example, one vehicle from impersonating another.
But client connection counts can be quite large in IoT applications, making it impractical to create a unique ACL profile for each client. In the recent 8.3.0 release of the Solace Virtual Message Router, we added substitution variables for client-usernames in topic strings to ACL profiles, which means you can now apply a single ACL profile to many client connections. When the MQTT client-username substitution variable appears in an ACL rule being applied to a client, the router replaces that variable with the corresponding client-username for the client connection when performing an ACL check.… Read the rest
On May 30, Solace Senior Architect Jonathan Schabowsky explained how messaging and microservices work with Pivotal Cloud Foundry as part of a Brighttalk webinar. He provided a great introduction to the concept of microservices and then dove into the details of architectural considerations.
As part of that he covered how Platform as a Service (PaaS) makes it easier to deliver on the microservice promise by eliminating some of the distractions that app developers face while providing a “deploy anywhere” capability. But, as Jonathan covers, “deploy anywhere” comes with its own headaches around communication and data movement.
Jonathan dug into a comparison of REST and other open protocols, like AMQP and MQTT. One of his comments (often mentioned in technology) refers to the fact that not everything is a nail to the REST hammer. Fortunately, we find out that there are a lot of different tools available in the Solace toolbox. You can find even more on microservices on the Solace dev site and find code, demos and more examples on the Labs site and Github repositories.… Read the rest
Ever since we introduced the VMR a little over 2 years ago, people have been asking me “I get why your hardware performs so much better than software messaging products, but why is the VMR so much faster than other software products on the market – isn’t it just software too?”
Well, yes, the VMR is software, but I wouldn’t say “just.” Our developers come from a background of building hard real-time software for things like IP routers, ATM switches, and other embedded solutions — designing for performance, robustness, and scalability is in our DNA. The engineers who programmed the network processor on the Network Acceleration Blade, and wrote the code that makes the Assured Delivery Blade do its magic, are the same people who wrote the code for the VMR. In fact, we share the code between the hardware and software wherever we can, building the two products from a common code base. … Read the rest
The performance of Solace’s software and hardware data movement products has always been the best in the industry, but demand for ever higher throughput continues as the increasing ubiquity of technologies like big data, hybrid cloud, IoT and mobile computing drives the need to move more and more data in real-time. That’s why product performance is something our engineers are always working on, and it’s why we’ve just announced improvements to the performance of our Virtual Message Router software and 3560 appliance.
Version 8.2 of the VMR boosts message rates to 640,000 guaranteed messages per second in fan-out scenarios, and 80,000 guaranteed messages per second when routing messages on a 1:1 basis. That’s a 30%-50% improvement over earlier versions of the VMR.
Our hardware team has also been busy. We’ve just released the Assured Delivery Blade 4, our fastest ADB ever. Combined with a new 80 Gbps network I/O blade in the latest 3560 chassis, this new configuration is 50-120% faster than the earlier ADB-3 systems.… Read the rest
I have recently created a new integration guide for an Apache project called NiFi. NiFi is an enterprise integration and dataflow automation tool that lets you send, receive, route, transform, echo and sort data. NiFi was drafted as part of the NSA’s duty to respond to foreign-intelligence requirements, so it anticipates and aims to support high volume, high availability and absolute security. The interface is very intuitive so even non-tech savvy people can design and understand NiFi data flows.
NiFi’s support for JMS is vendor neutral and broker services can be dynamically configured by specifying a few key properties such as Connection Factory Implementation, URL, Library path, and user credential. However, the NiFi JMS service provider can only instantiate connection factories by calling zero-argument constructors, which not all JMS brokers support. Most JMS brokers do, however, support JDNI stores, so you can drop in a JNDI connection provider while preserving the integrity, simplicity and neutrality of NiFI’s design.… Read the rest