Choria Blog

Yesterday, in our previous post, we did a light compare between HTTP and Middleware based architectures for Microservices. Today we’ll start focusing on Middleware based architectures and show some detail about the why’s and the patterns available to developers.

Why Middleware Based

The Middleware is a form of Transport, rather than addresses you think in named channels and the endpoints within that channel decides how they consume the messages, 1:1, 1:n or randomly-selected 1:n.

The goal is to promote an architecture that is scalable, easy to manage and easy to operate. These goals are achieved by:

• Promoting application design that breaks complex applications into simple single-function building blocks that’s easy to develop, test and scale
• Application building blocks are not tightly coupled and can scale independently of other building blocks
• The middleware layer implementation is transparent to the application – network topologies, routing, ACLs etc. can change without application code change
• The brokers provide a lot of the patterns you need for scaling – load balancing, queuing, persistence, eventual consistency, failover, etc.
• Mature brokers are designed to be scalable and highly available – very complex problems that you do not want to attempt to solve on your own
• Fewer moving parts, less coupled to infrastructure layers and scalable across multiple clusters

There are many other reasons, but for me, these are the big-ticket items – especially the 2nd one.

Back in 2011, I wrote a series of posts on Common Messaging Patterns Using Stomp; these posts were very popular, I figured it’s time for a bit of refresh focusing on NATS - the Middleware Choria uses as it’s messaging transport.

Today there are 2 prevailing architectures in Microservices based infrastructure - HTTP based and Middleware based Microservices. I’ll do a quick overview of the two patterns highlighting some of the pros and cons here; first, we look at the more familiar HTTP based and then move to Middleware based. In follow-up posts, we’ll explore the Middleware communication patterns in detail and show some code.

Note though the context here is not to say one is better than the other or to convince you to pick a particular style, I am also not exhaustively comparing the systems - that would be impossible to do well.

Today the prevailing architecture of choice is HTTP based, and it’s demonstrably a very good and very scalable choice. I want to focus on using Middleware to achieve similar outcomes and what other problems they can solve and how - the aim is to share information and not to start a product/architecture comparison debate.

Series Index

• Series introduction
• Description of the major messaging patterns supported by NATS
• Running NATS Server and exploring patterns from the CLI
• Creating a basic log distribution tool
• Adding scalability to the log distribution tool
• Introducing JetStream
• Interacting with the JetStream API
• Adjusting the log distribution tool for JetStream
• Reliable delivery and Acknowledgement Patterns

Open Policy Agent is a CNCF incubating project that allow you to define Policy as code. It’s widely used in various projects like Istio, Kubernetes and more.

It allows you to express authorization policies - like our Action Policy - in a much more flexible way.

Building on the work that was done for aaasvc, I’ve added a rego engine to the choria server, which will allow us to do most of what actionpolicy allows, as well as:

• Assertions based on the arguments sent to actions
• Assertions based on other request fields like TTL and Collective
• Assertions based on if the server is set to provisioning mode or not

Read below the fold for our initial foray into OPA policies and what might come next.

Choria configuration, despite efforts with Puppet module and so, is still very challenging. Just knowing what settings are available has been a problem.

We tried to hide much of the complexity behind Puppet models but for people who don’t conform to the norm it’s been a challenge.

I eventually want to move to a new configuration format - perhaps HCL? - but this is a massive undertaking both for me and users. For now we’ve made some effort to give insights to all the known configuration settings on the CLI and in our documentation.

First we’ll publish a generated configuration reference in CONFIGURATION.md - for now it’s in the Git repository we’ll move it to the doc site eventually.

As of the upcoming version of Choria Server you’ll be able to query the CLI for any setting using regular expressions. The list will show descriptions, data types, validation rules, default values, deprecation hints and URLs to additional information.

And get a list:

$ choria tool config puppet -l
plugin.choria.puppetca_host
plugin.choria.puppetca_port
plugin.choria.puppetdb_host
plugin.choria.puppetdb_port
plugin.choria.puppetserver_host
plugin.choria.puppetserver_port

These references are extracted from the Go code - something that I never imagine is possible - read on for details on how that is done.

I’ve previously blogged about a niche system that enables Mass Provisioning Choria Servers, it is quite scary and tend to be specific to large customers so it’s off by default and require customer specific builds to enable.

I’ve had some time with this system and it’s proven very reliable and flexible, I’ve had many 100s of thousands of nodes under management of this provisioner and can kick 10s of thousands of nodes into provisioning state and it will happily do thousands a minute.

The concept is sound and the next obvious step is to make it available to FOSS users in our FOSS builds. To get there is a long road one that I think will take us toward Kubernetes deployed Choria Broker, CA and Choria Provisioners and eventually a Puppet free deployment scenario.

It’s a long road and step one is about looking at how we can safely enable provisioning in the open source builds. Read on for the details of what was enabled in Choria Server 0.13.0 that was released on 12th of December.

Open Policy Agent is a CNCF incubating project that allow you to define Policy as code. It’s widely used in various projects like Istio, Kubernetes and more.

It allows you to express authorization policies - like our Action Policy - in a much more flexible way.

I’ve wanted to explore what is next for our general Authorization piece and I think this gets us to a very good place - and OPA have massive adoption so it’s always good to adopt widely used standards.

Using Open Policy we’ll be able to do a number of things we’ve never been able to do - but get asked about regularly:

• Make sure requests have filters associated to avoid huge blast radius
• Assertions based on the arguments sent to actions
• Assertions based on other request fields like TTL and Collective

And just generally be much more expressive about it.

Read below the fold for our initial foray into OPA policies and what might come next.

It’s been a while since we had release announcements and it’s been a surprisingly busy period.

The main focus here has been on a number of stability and bug fixes, we’ve had some users dig in really deep into various aspects of the system and a number of bugs were squashed.

Past the quality of life stuff I have started reworking Choria Server Provisioning which will set us on a path to having a good Puppet free story, I have some POCs lying around of a Kubernetes based Broker, CA, and Provisioner that will give a really smooth path forward - provisioning is now compiled in to the FOSS stack by default and can be enabled using a JWT token, more on that in a future post.

We also include a Tech Preview of NATS JetStream support and significantly moved our event formats over to Cloud Events v1.0 format.

Thanks especially go to Alexander Hermes for his deep dive into all aspects of the client side playbooks. Deep dives into a product and filing some tickets, discussing the model on slack etc it hugely time consuming and very often this kind of community contribution flies under the radar but I find it more valuable than code, huge props to Alexander.

Other shout outs to Ben Robert, Yury Bushmelev, Romain Tartière and Vincent Janelle

The upcoming Choria Server release will support publishing fleet data to JetStream a new Streaming Server from the folks who built NATS - the core technology of the Choria Broker.

This technology is currently in tech preview and so we’ve added early support for it so Choria users can test it for their needs.

Support for JetStream will be in the nightly build tonight and a release will be soon.

Read on for some background on the why and how.

When we first introduced our Lifecycle Events we mentioned efforts by cloudevents.io to standardize a format and set of transports but that it was a bit early in their life to adopt it.

Cloud Events is now a CNCF Incubator project and they reached CloudEvents 1.0 which means there is now a standard to work around that is stable. A good introduction to the concept can be found in The CloudEvents Spec Seeks to Bring Uniformity to Event Data Descriptions.

Since then adoption of this format has exploded - a whole bunch of companies and projects support ingesting and routing CloudEvents, examples: solo.io with their event powered API gateway, OpenFaaS, Serverless.com Event Gateway, Oracle Cloud, Azure, Knative and many many more.

So for us the time is ripe to adjust the format of our events to support CloudEvents 1.0. As of the next release of the Choria Server the Life Cycle events and Autonomous Agent Events are all been transitioned to CloudEvents format.

The latest release of Choria includes support for external agents, so now writing agents in any language is possible. For those of us who prefer to use Python to manage our systems, we have a new library, py-mco-agent which is intended to make it as simple as possible to write Choria agents. The simplest possible agent can be written with just a few lines of code.