On 2 March 2019, ARIN deployed its new website, a project that at its zenith required the focus and work of more than half of all ARIN staff and constituted one of the biggest software deployments in the history of the company. This may seem like a large amount of effort just to change the look and feel of our website, but there was much, much more going on behind the scenes.
While this article focuses on the technology stacks involved in our new website, we did spend a considerable amount of time seeking feedback from the community. You can read about how we solicited and used this feedback in our previous post.
In the Before Time
Preparations for a new ARIN.net began four years ago with some strategic planning on how to move both ARIN Online (the web portal part of our website) and the voluminous content of the main site forward, while simultaneously adding new features to ARIN Online and new content to ARIN.net. We had a couple of goals:
- Find technologies that could be embedded in our current stack that could later be unwrapped to stand on their own. This was important as we did not have the resources to dedicate a team to a new website. The people working toward the new website were the same people adding features to the current website.
- Improve our website with respect to both mobile and tablet user experiences, generally known as responsive web design, and meet and maintain the standards for web accessibility (WCAG 2.1 Level AA).
- Create a unified theme for the website to provide a more seamless experience for users both reading our content and using ARIN Online.
- Adopt an architecture that would bring us closer to deploying more frequently with less overhead to facilitate faster delivery of features and bug fixes.
Our test case for both of these was the SwipEZ project, which added SWiP functions (reallocation and reassignment of networks) to ARIN Online. That effort was a success, but at the end of the project we learned that Angular 2, had been released and that it was not compatible with Angular 1 which we had just deployed. Taking an inventory of ARIN Online, we found that our portal consisted of 261 separate and distinct pages leaving us with a conundrum: continue using Angular 1 and upgrade everything at a point in the future, or backtrack and convert all our Angular 1 work to Angular 2, thus delaying the project. Though it was a hard decision, in the end we decided to delay the project to facilitate an upgrade trading off a little hard work now for a lot of hard work later. Fortunately, every subsequent upgrade of Angular since has been relatively easy and non-disruptive.
Content is King
Of ARIN.net, ARIN Online is only one half of the whole. The content, relied upon by all our community and referenced far and wide by other organizations, needed upgrading, needed to meet mobile and accessibility requirements, and our community feedback told us that it needed to be re-organized.
The creation of that content used Adobe Dreamweaver with many custom template files, and the management of that content relied upon a set of bash scripts and Subversion hooks; constituting a homegrown content management system over 15 years old.
In looking for better solutions, we had a few goals:
- Find a solution where our content authors do not have to get wound up in the technical aspects of website rendering and worrying about mobility and accessibility issues.
- Adopt modern, loosely-coupled tooling to provide flexibility and better future-proofing.
- Keep an eye on potential technical needs, such as the usage of a content delivery network to help with network reachability.
To help our content creators focus on content, we adopted Markdown instead of authoring directly in HTML. We picked Hugo, a static site generator notorious for its ease of maintenance, huge list of features, and incredible speed. To push the output of Hugo to our website, we switched from Subversion to Git and utilized the features of Atlassian’s Bitbucket build server.
After deciding where we wanted to go technology-wise, we then had to figure out how to get there. Re-organizing and converting almost 2,000 web pages (!) was a daunting task. Internal analysis concluded that if we dedicated staff to this task only using manual steps, the effort would take between six and eight months (and lead to some very unhappy employees).
Fortunately, with a little study of the problem and thanks to consistent practices of our content creators over the years, we were able to write a custom Ruby script to convert webpages from HTML to Hugo-based Markdown while simultaneously re-organizing the content and rewriting internal page links. This nearly eliminated the problem and gave our content team the time to concentrate on quality issues instead of the rote mechanics of conversion.
What You Can’t See
Behind the scenes, there were also plenty of changes.
To reduce downtime, we moved our website load balancing from Apache to BigIP F5s, and converted our HTML file serving from Apache to Nginx. These changes increased both performance and our security posture.
To simplify our network architecture and systems interconnects, we moved our queuing from HornetQ to PostgreSQL. Queuing in a database is often considered bad practice, but we conducted an analysis of our queuing needs and found that we could take advantage of a recent feature in PostgreSQL called SKIP LOCK. Overall, this simplified the nature in which our various systems are glued together while giving us enhanced flexibility and management of our queues.
In addition to all the theming, better content, and new features, ARIN committed to meeting standards of web accessibility with both content and ARIN Online. To start this, we engaged LevelAccess for training to bring our entire software development and quality assurance staff up-to-speed on the present-day guidelines and practices necessary to meet WCAG 2.1 Level AA. In our processes, we adopted comprehensive manual reviews of all web pages, and we integrated tools such as Pa11y and axe into our automated build processes to catch problems in the early stages of development.
The New SEARCH.ARIN.NET
Perhaps our single biggest issue with our old website was search. Many users quite often invoked our site search for Whois queries and used our Whois system to find web pages. This was far from optimal and led to a fairly confusing user experience.
In addition to creating this “unified” search input, we moved our web-based Whois lookups from Whois-RWS to RDAP. RDAP is an IETF standard and all RIRs have RDAP services, so now IP address and AS searches at our website will pull the correct information directly from the RIR authoritative for that information. This change has become so popular, that as of this writing 30% of all page views for ARIN are the RDAP client at SEARCH.ARIN.NET.
Despite everything done so far, we don’t believe our job is finished.
In May, we will deploy new code enabling Oauth within ARIN Online. This change will bring about a stateless architecture, increasing our uptime by eliminating most maintenance outages and giving users much longer sessions to complete tickets and other work while online.
Finally, we plan to continually seek input from our community on the user experience of ARIN.net. Though the new website is up, we will continue to conduct in-person and remote user testing and look for ways to improve our site. If you would like to provide feedback, please use the feedback button at the top of our homepage. We’d love to hear from you.