NATS as the IoT mobile messaging system for an earthquake early warning network

I’m a programmer. I like to find difficult problems to solve, and work on effective solutions to these problems. We’ve all seen earthquakes covered in the news, sadly, and earthquakes are on the rise globally. The average frequency and magnitude of earthquakes has increased recently, and more people than ever are living in urban areas which are dangerous during earthquakes.

Our NATS-powered Validation Services in Action

I’d like to focus for this blog on what NATS has helped us to achieve. There are a whole set of other great entries on this site looking at various aspects of technical implementations, and the NATS community as a whole is incredibly responsive and helpful; so if you have questions about how to do something just have a read around here, and you can always ask a question in the NATS Slack channel for pretty much immediate gratification.

The Linux Foundation’s OpenIoT Summit was held in San Diego in April, and for those of you who attended and maybe went home with some swag, you’ll remember the NATS team had a booth. What you may not remember a month later are the details of Larry McQueary’s overview of NATS at one of the speaking sessions . As a refresher, the recording of the talk is now available for viewing on YouTube. You can see a quick demo of NATS later in the video (starting here ), and QnA at the end . The full video is available below:

NATS is outstanding at moving data between endpoints - but what kinds of endpoints? You may have legacy applications that use some proprietary data sources, or perhaps you are migrating from another messaging technology onto NATS. For cases like these, you’ll want to take advantage of the NATS Connector Framework .

The NATS Connector Framework

The NATS Connector Framework provides a foundation to build a connector - an application that moves data into and out of NATS. In creating the connector framework, NATS tenets of simplicity, usability, and community were kept in mind. This resulted in a simple, extensible, and single purposed framework for users to quickly and easily build reusable bridges between NATS and other technologies.

The REST to NATS proxy project sohlich/nats-proxy is the micro framework that provides a bridge between HTTP and NATS. To introduce the problem, we first compare the HTTP and NATS communication models. The table below represents the matching of HTTP and NATS concepts and what do they provide.

As you can see, the NATS provides both synchronous and asynchronous communication between clients. The synchronous communication, represented by simple Request and Response of HTTP protocol, could be matched with the Request/Reply communication model of NATS. As the documentation for “request reply” model describes: each request sent via NATS contains reply subject, to which the reply is sent. The asynchronous, let’s say real-time communication, can be represented by Websockets on HTTP side.The truth is that it is not really related to HTTP, but if we simplify it, at least the handshake is based on HTTP. For this purpose, the Publish/Subscribe model could be used.

In the context of a submittal to the Samsung Maker’s Against Drought Challenge (more on that here ) extended hackathon, my team has developed a partial solution to the very serious California drought crisis. I say partial since this problem is so vast that many solutions are required to operate collaboratively to fully solve it.

The solution utilizes physical water system monitoring and control with Samsung ARTIK 10 IoT modules, and a Particle Photon module running the arduino-nats NATS client. One ARTIK 10 is running a custom server written in Go and the second is running a NATS server and local database.

In this post we’re going to discuss using Micro on NATS . It includes discussion around service discovery, synchronous and asynchronous communication for microservices.

If you would like to learn more about Micro first, check out the blog post detailing the toolkit here.

Let’s get down to business.

What is NATS?

NATS is an open source cloud native messaging system or more simply a message bus. NATS was created by Derek Collison, the founder of Apcera. It originated within VMWare and began life as a ruby based system. It’s long since been rewritten in Go and is steadily gaining adoption amongst those looking for a highly scalable and performant messaging system.

At Sendify we’ve been using nats as a simple and effective means of communicating between our backend services. I came across Nats a few years ago when building a relatively small microservice backed system and it worked wonderfully. With that experience, I introduced it to Sendify this year as the main nervous system for inter-service communication.

Our system is mainly processing api requests to various freight carriers based on user searches though we’re also building integration for public api access as well. We have a mix of legacy php and newer golang services. We’re running everything as containers on docker swarm.

A few weeks ago, the Apcera Platform gained a new service gateway. The new NATS service gateway will allow Apcera Platform users to quickly give their apps a NATS server - without sacrificing security or reliability. In this post, we’re going to demonstrate a simple server that broadcasts data to some clients over NATS.

As a distributed messaging system, NATS is lightweight, high performance, and secure - making it ideal for modern architectures.

Hello everyone. It’s been a great start to 2016, and we didn’t want to go too long without hosting another NATS meetup. Now that we are well past the holiday hangover, and into the conference and event season, before things get too busy we wanted to invite everyone out to our offices in the heart of San Francisco at 140 New Montgomery Street.

On March 22nd, we will be hosting a NATS Meetup (RSVP here if you can make it!), and I am thrilled to have two excellent guest speakers from the NATS development community. Both Tyler Treat and John Lockwood work at Workiva; Workiva uses NATS as their cloud native microservices transport in their distributed systems infrastructure. If you are not already familiar with Tyler, he maintains the blog Brave New Geek.