Apcera NATS, Messaging and Simplicity

Datetime:2016-08-22 22:38:05          Topic: Coder           Share

With the ever-increasing amounts of data sent and received by today’s applications, developers are turning to tried-and-true technologies to help them address message brokering across different applications, or between different microservices within an application. Stripping the complexity from message brokering at scale is something which Apcera aims to accomplish with its Go-based message broker service NATS .

In this episode of The New Stack Analysts , we explore how Apcera hopesNATS will stand out in the message broker ecosystem, why simplicity is a powerful tool for message brokerage at scale, and how developers can ensure their services remain cost-efficient in the long term. Apcera Product Manager Larry McQueary and Apcera Vice President of Alliances and Channels Steve Dischinger spoke with The New Stack founder Alex Williams and co-host 451 Research Analyst Donnie Berkholz to learn more about NATS.

The interview can also be heard on YouTube .

McQueary highlighted some of the challenges developers can face when working with distributed applications, such asKafka. “It’s got kind of a bunch of moving pieces depending on which version you’re using. We just try and leave all that to the applications and developers. We want to provide a core tool that’s as small as it can be, with the smallest footprint and least amount of complexity. So you can build the best application without worrying about, ‘How do I do messaging?’”

Sponsor Note

The Apcera trusted cloud platform is a highly secure, policy-driven multi-cloud platform for cloud-native applications, containers, microservices and legacy applications. Apcera enables developers and DevOps teams to use any modern tool or software they want while giving IT and Operations teams the assurance that their infrastructure is safe and secure.

The costs associated with getting data from point A to point B can quickly add up if one is not paying close attention. McQueary highlighted that while the protocols may have changed in the 20 years since Java’s Remote Method Invocation (RMI) dominated message brokering, the pub/sub process hasn’t shifted into obscurity just yet. “These services are using HTTP orHTTP/2 to establish point to point connections between processes that they first have to look up through an external service like Consul oretcd to get to, and the cost of that’s expensive. Generally, it’s more expensive than you think. Especially when you’re firing a lot of events and transactions in the control plane in particular.”

As the conversation continued, McQueary posed a question to those seeking to integrate their message brokering platform with their existing stack, “The thing that we think that users should be thinking about is: What’s the simplest path to value in doing those integrations?”

Apcera is a sponsor of The New Stack.

Feature image by Etienne Desclides , via Unsplash , under a cc0 license.





About List