HOW INTEROPERABILITY AND OPEN NETWORKS MAKE BUSINESS EASIER
With ever more complex systems, the need for these systems to work together through interoperability is clear. But what exactly is interoperability and why is it important to take into consideration when choosing an e-invoicing service provider? Read on as Pagero’s Hanna Sterner explains.
OPERATION WITHOUT INTERRUPTION
To enjoy the benefits of e-invoicing, interoperability is essential. But what do we mean when we talk about interoperability, exactly? Telecommunications is an example of an industry that had to embrace interoperability, and it benefitted us all. Consider using your phone, do you question if you’ll reach the person at the other end of the line? Whichever operator you use, you make the natural assumption that you will be able to speak to each other.
It was not always quite so simple. In the past, operators tried to restrict customers to their services. They charged them for calling outside of their network. Soon it became clear that for the industry to move into the future, each network needed to communicate with each other seamlessly, or the industry would fall apart. They created an interoperable network.
“Telecommunications is an example of an industry that had to embrace interoperability, and it benefitted us all”
In our industry, interoperability is a young idea. However, we are quickly approaching the same tipping point as the telecommunications sector did. We need to be able to work together in a fluid manner with the fewest possible obstacles, to do this we need to break down barriers.
OPEN OR CLOSED THAT IS THE QUESTION…
Just as we are seeing in so many other areas, there’s a debate about open and closed or proprietary systems when it comes to e-invoicing.
Closed networks, often representing countries, regions or industries, represent isolated communities. Each community, in turn, has their own separate systems and standards. These isolated communities make it complex and difficult for trading parties to connect.
An open system gives businesses a network that extends beyond your service provider and your network, giving you maximum reach to as many business partners as possible.
A truly open network is also designed to integrate seamlessly with new technologies and solutions as they emerge. This brings value to businesses, as they then have the full freedom of choice for their own operations, without the burden of needing to consider what systems or processes their business partners are using.
WORKING TOGETHER FOR COMMON STANDARDS
Organisations such as EESPA (the European E-Invoicing Service Providers Association, OpenPEPPOL (Pan-European Public Procurement On-Line), TIEKE (the Finnish Information Society Development Centre) and NEA (the Electronic Business Network), all work to help standardise and smooth the e-invoicing process between businesses, institutions and across borders.
“Ultimately, modern, outward-looking, open networks are preferable overall”
Pagero works with each forum and organisation to gain both a broader understanding of the market but also to make it easier for our customer to connect with their business partners. Further, through our involvement, we manage to stay informed of the latest trends as well as bring our long and successful experience in working towards global reach to the wider community.
PAGERO BELIEVES IN AN OPEN NETWORK
At Pagero we have been committed to interoperability from the start, and we are keen to help our customers streamline their flow of business documents. Pagero has agreements with a large number of other operators, and our network is constantly growing. Our goal is to make it possible for our customers to reach as many other companies as possible in both the private and public sectors, worldwide.
As we all move towards a more open business community, why choose closed networks? Pagero has always believed in openness and it is what we invest in.
SIMPLICITY LIES AT THE HEART OF NATS
FROM KUBECON IN COPENHAGEN TO PAGERO IN GOTHENBURG
At Pagero, we constantly evaluate new technologies and software products. Sometimes, they turn out to be dead ends, but quite often, they help us speed up our development, or provide a better service to our customers. One project that we have been watching for a while, is NATS.
We already have an event-driven architecture, using RabbitMQ; a battle-tested message broker. While RabbitMQ is working pretty well for us, NATS is really interesting for us. We’ve already tried it as an embedded queue in some prototype Go (programming language) application, where it a great experience to work with.
When we heard that the NATS team were visiting Kubecon 2018 in Copenhagen, it was exciting news. Many of our developers were interested in NATS but not all could attend Kubecon. Thus, we contacted Synadia and asked if anyone would be willing to come to speak at a couple of meetups in Gothenburg. Renown NATS core contributor Waldemar Quevedo graciously accepted, and we were thrilled.
From doing a keynote in front of 4.500 people at Kubecon Copenhagen, Wally arrived in a warm and sunny Gothenburg to speak at two meetups at Pagero. Continue reading my article or check out Wally’s entire presentation below:
THE HISTORY BEHIND NATS
Wally began by explaining a little of the history behind NATS. A Cloud Native (CNCF) messaging system NATS was developed in 2010 by industry veteran, entrepreneur and pioneer in large-scale distributed systems and cloud computing, Derek Collison.
Collison, a messaging developer for some twenty-five years began to develop the system as a side project. Originally written in Ruby and built for Cloud Foundry it was later rewritten in 2012 in Go.
Open-source, NATS is currently available under Apache License (2.0) and is deployed in some of the largest cloud platforms, including VMware, Cloud Foundry, Baidu, Siemens, and GE. It is recognised by the industry for several specific strengths over its competitors such as Kafka.
“From doing a keynote in front of 4.500 people at Kubecon Copenhagen, Wally arrived in a warm and sunny Gothenburg to speak at two meetups at Pagero.”
WAY, WAY FASTER!
Speed is one of the central pillars to its success. When the system underwent its re-write in Go, or upgrade, it became pretty quick. “It’s way, way faster!” Wally explains.
In fact, the speed of the system is something he was keen to underline during the meetup: “If I have to tell you one single thing about NATS is that it’s very fast” he says, and he backs up his confident statement with some solid facts.
Wally explains that “Even in the days of Ruby it could push 150,000 messages a second,” but that’s nothing compared to the turbo-charging it went through thanks to Go. Now a single server can push approximately 11milion messages a second.
Wally explains that it achieves this thanks to its agile architecture. NATS is designed to be as operationally simple and reliable as possible while maintaining a high performance. Performance, simplicity, security and availability are the real DNA of NATS. Simplicity, Wally says, is key to effective and agile functionality.
THE TWO NATS: NATS AND NATS STREAMING
NATS is offered in two interoperable modules:
The first is the core NATS platform known simply as “NATS”.
The second is NATS Streaming, originally known as STAN (as the opposite of NATS, though the name didn’t stick).
NATS Streaming is an event streaming service that can be used to add event streaming, delivery guarantees, and historical data replay to NATS. In addition to the features of the core NATS platform, NATS Streaming provides several extra features such as enhanced message protocol – NATS Streaming implements its own enhanced message format using Google Protocol Buffers.
NATS Streaming messages can contain the following fields:
Subject – The NATS Streaming delivery subject
Reply – The optional “reply-to” subject
Data – The message payload
Timestamp – the received timestamp, in nanoseconds.
Redelivered – A flag signifying whether this message has been redelivered by the server
“NATS is designed to be as operationally simple and reliable as possible while maintaining a high performance.”
THE DARK SECRET OF NATS
Having given an extensive and authoritative rundown on the design and background to NATS and NATS Streaming, Wally draws his presentation to a close.
However, there is one question left unanswered: What does the apparent acronym “NATS” stand for?
Even on the NATS website, there is a reference to the “lore” of the NATS name but there are no answers. Unfortunately, we are still in the dark about this and can only hope that Wally returns for another meetup and an explanation soon.
OUR TAKEAWAYS
Our takeaways from Wally’s presentations are the following:
In software, complexity is dangerous. What we love about NATS is the simplicity. This goes for NATS-streaming as well.
NATS has no place in the ballroom. It doesn’t do elegant, it’s a simple, gritty beast that does exactly what it advertises.
It does not bring any dependencies, while Kafka requires Zookeeper (not to mention the JVM ). In fact, both NATS and NATS Streaming are very straightforward to embed into your Go applications, and with a very small footprint.
While Kafka is positioned as the enterprise-ready, battle-tested option, NATS Streaming can be described as a hungry contender.
It does not offer exactly-once-delivery; but do you really need it?
Also, on this topic, another project that might interest you is Jocko – a Kafka rewrite in Go.
PRACTICAL NATS: FROM BEGINNER TO PRO
For further reading on the problems which come along with microservices and cloud-native application development, do not miss Waldemar Quevedo’s newly published book “Practical NATS: From Beginner to Pro“.
GOTHENBURG TECH RADAR
Join Pageros’ meetup Gothenburg Tech Radar for more information and invitations to future events about the latest software, technology and methodologies!