DZone
Integration Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Integration Zone > NATS as a Secure and Scalable Control Plane

NATS as a Secure and Scalable Control Plane

NATS can work wonders as a control plane for Go, Amazon Web Server, and Microsoft SQL server-based microservices — in any industry.

Mark Songhurst user avatar by
Mark Songhurst
·
Jan. 30, 17 · Integration Zone · Opinion
Like (2)
Save
Tweet
3.52K Views

Join the DZone community and get the full member experience.

Join For Free

Equine Register provides the government, industry, and members of the public with bespoke digital tools and services that increase equine welfare and combat criminal activity. We are actively replacing legacy paper-based systems with smartphone and web delivered solutions which provide unequivocal information regarding the identity, history, health, and ownership of an equine from its birth onwards.

I am responsible for the design and implementation of the architecture providing our RESTful API, which needs to serve an array of different clients and be capable of supporting new functionality with minimal delay and impact. With an ever-increasing customer base, our system’s performance metrics are estimates at best, requiring the API to be highly performant and stable.

I designed the systems providing the API from scratch, using a microsystems approach with all components being written in Go and hosted on CentOS 7 instances running in auto-scaling groups (ASG) on Amazon Web Services.

Each component in our microsystem is named after a horse breed, with the two primary components being Percheron (our public facing HTTPS interface) and Taishuh (the API endpoint request processor, which concurrently executes stored procedure calls against Microsoft SQL Server).

How Do We Use NATS?

NATS provides the messaging layer between Percheron and Taishuh.

Image title

I use NATS Message Queuing as the communication method, with each Taishuh instance declaring support for one or more Queues and each Queue mapping to an API endpoint. In Taishuh, a Queue handler is declared through a Go interface, which enables me to develop new Queue handlers very quickly. I can enable Queue support within Taishuh though JSON configuration files, so we can configure certain Taishuh instances running on Large AWS EC2 instances to handle (for example) API calls that perform CPU heavy tasks, whilst lightweight API calls can go to Micro EC2 instances.

NATS then provides routing for me by determining for me which Queue Group in the pool of Taishuh instances a message will be sent to. Each Taishuh in the Queue Group has a limit of how many messages it will concurrently process. Once that limit is met, it will ignore further messages to the Queue Group until it has available capacity.

OK, so I could do this using an AWS Application Load Balancer — but because of the flexibility of NATS, I’m not bound to any particular cloud service provider, and we could (potentially) modify our architecture as future requirements dictate relatively easily.

A further gain is error handling. When NATS times-out on a message I can pick this up in Percheron and handle the error gracefully by either returning a 5xx series HTTPS status to the client or by re-submitting the NATS message and have Percheron extend the session with the Client.

Security is paramount to our architecture and the relatively recent addition of TLS support in NATS allows use to now employ TLS connections all the way from Client to SQL Server and back again.

For redundancy, we use the NATS cluster mode, placing the Seed Servers into an AWS ASG.

We’re using the Glide dependency system for Go and because NATS Go Client declares Github release version numbers, our CI system can make both reproducible and predictable builds.

In addition to these benefits we get by using NATS, it has also allowed us to quickly adapt a modern microservices architecture. Initial management concerns about the inherent latency in such an architecture were quashed when the performance of NATS shone through.

Where Are We Going Next?

We’re looking to gain better insight into the throughput of the API infrastructure, ironing out any bottlenecks and dynamically increasing capacity when required. To this end, we’ll be looking closely at the monitoring support offered by NATS.

Nat (unit)

Published at DZone with permission of Mark Songhurst. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Developers Need to Know About Table Partition Pruning
  • Event-Driven Hello World Program
  • Kubernetes Service Types Explained In-Detail
  • Are All Kubernetes Ingresses the Same?

Comments

Integration Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo