Brad Woodfin

As posted in PublicNTP’s previous blog article, our team has spent many hours and meetings over the past months identifying the advantages and disadvantages of our own open architecture. We’ve looked hard at utilizing tried and true NTP servers in tandem with our own established network of stratum two and, more recently, stratum one servers.

Several people have asked why PublicNTP built its own solution, considering that fully-packaged, ready-to-deploy appliances can be easily acquired from a number of vendors.

It’s an excellent question: why rebuild the wheel? We aim to answer that here.

In our case, there were multiple reasons we decided to buy and build our own stratum one. In no particular order:

Cost Savings

After getting quotes for several entry-level NTP server appliances from many commercial companies, we became convinced that we could build our own solution for less money. Their products are impressive, but as our funding comes from donated dollars, PublicNTP must carefully ensure that each dollar goes as far as it can.

Technical Challenge

The members of our board and dev team had a funny reaction once we reported the results of the easier, buy-off-the-shelf research. It became a challenge to work lean and within a different set of constraints. Testing out the various options for optimal solutions was both educational and enjoyable for us!

Integration Into Existing Fleet Monitoring

The available appliances we looked at all came with their own closed architecture. While they did support things such as Simple Network Management Protocol (SNMP), our shop is primarily Ubuntu-oriented. We needed to ensure they were compatible with our Linux/Ubuntu monitoring structure. Obviously, we can’t run Canonical Landscape on an NTP appliance that isn’t running Ubuntu.

Extensible, Open Architecture

One of the most important goals of our project is to keep this open-source. We want to help the world help itself and needed to ensure we were free to publish our architecture.

Our vision is to see more and more of the community share ideas on how to improve upon PublicNTP’s work. One of the greatest examples and inspirations of community-made progress is the OpenCompute Project. The benefits of the open and free exchange of ideas are too great not to share our methodology.

Dealing With Hardware Failure

Despite the fidelity of hardware these days, things always break. If (and of course when) one of our stratum one deployments needs a replacement component, we want to be able to quickly source the part, ship it, and get things fixed. We’d rather not wait for a back order or pay an exorbitant amount to acquire a specific piece of hardware.

All of this is simplified when using widely-available, commercial equipment instead of a custom appliance.

Based on these points, our Board of Directors decided that investing the hours and money to design, build, and test our own open architecture was the best option.

Look forward to our next installment in this blog series. We’ll be tackling the technical overview of PublicNTP’s stratum one open architecture.