Showing posts with label render. Show all posts
Showing posts with label render. Show all posts

Data Centre options for Pipi 9

Mike's Notes

I'm writing down my evolving thoughts about a future Pipi 9 data centre. This is to enable suppliers, Alex, and others to give me feedback.

Update 01/04/2026

Anthropic provides each customer with a MacBook Mini to create an isolated cloud environment. Pipi could easily do something similar using low-cost refurbished PC's in the data centre. I'm running experiments with a Dell OptiPlex 7050 to see if it can host a single Pipi core for a customer.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > 
  • Home > Handbook > Company > Values

Last Updated

01/04/2026

Data Centre options for Pipi 9

By: Mike Peters
On a Sandy Beach: 26/04/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi 4 in 2007

Pipi 4 used three ModemPak 45u rack cabinets to mount the servers. There was a separate 6 kw UPS. Here is a grainy photo from 2007, when it hosted the 17th most popular website in NZ, which received 30,000 unique visitors and 750,000 page views per month. It included servers for ESRI GIS, databases, applications, web hosting, updates, backups, security, rendering, and more, with extensive redundancy. It was never hacked due to the platform team led by Dave Evans. A report at the time to the Department of Conservation (DOC), written by Turing Solutions, a New Zealand government contractor, stated that Pipi 4 was worth NZ$3 million.

The first Pipi 9 rack cabinet

I am building out the first 45u rack cabinet. It was previously used for Pipi 4 and was in storage for 10 years. I'm having to replace the keyed barrel locks and get some rackstuds.

This temporary rack will be equipped with older servers for testing Pipi 9 and for rendering open-source modular applications to be sent to GitHub. Older servers work fine, but the rendering takes longer.

I will then replace these servers over the coming months with better second-hand ones to speed up the rendering.

I'm really enjoying this job. If you've ever had Mechano, you'll understand. I also have to design and build some specialist electronic gear to put in the rack. Even more fun.

It's also a significant milestone reached in the Pipi 9 build. This will be sufficient till Ajabbi scales.

The first Data Centre

Once scaling begins, Pipi 9 will need a data centre to serve as a render farm, automatically creating customised SaaS enterprise applications based on user requirements. The data centre will be completely isolated from the internet to maximise security. It can be expanded in stages if it is planned appropriately.

Each industry and each enterprise customer will get a dedicated server to store a mirrored copy of their deployment configuration and parameters, including localisation. No user data will be stored.

This enables customised updates to be created. For example, importing the latest version of Snomed or IATA.

Colocated Staging Data Centre

The built application then needs to be copied to disk and deployed to a small, caged, colocation data centre with high security, reliability, and connectivity, serving as a staging point for worldwide deployment. One option could be to use the proposed DataGrid Data Centre, set to open in Southland, NZ, by 2028, which will be connected via high-speed undersea cables.

Pipi 9 is designed to function as a swarm, with complete self-managing automation at every stage.

The emphasis is on 100% reliability and security, with extensive redundancy. See the Ajabbi Handbook reference for more initial information.

Production in the Cloud

The built application must then be deployed to a customer-selected cloud provider so the customer can use it in production. Pipi 9 would provide rapid updates and system changes within hours, not weeks or months.

Data Centre equipment

I really like the wide range of cabinet options that Rittal provides. My preference would be to use a standard 800mm wide 19 rack that could be flexibly used for;

  • Power
  • Cooling
  • Servers
  • Networking
  • Rack automation and monitoring

Other issues;

  • Determine the correct cabinet model to use
  • Use Open19 rather than OPC.
  • Use a cold aisle
  • Security doors
  • 24 hr monitored access

Looking good

I also like the look of the Eaton racks, probably because I like black racks. But maybe Rittal could provide them in black as well, on special order from their manufacturing facility across the ditch in Australia. Or else I could have them spray-painted and oven-baked locally. The Data Centre needs to be cool and look cool, and I don't like messy network cabling. Hey, I'm an artist too.

No doubt these ideas will evolve.

Rack Shelving

Shelving from Rack Solutions is designed to hold micro-format PCs. 

An example is this 5U HyperShelf for 16 Dell OptiPlex Micros, which costs US $599 for the kit.

Using ColdFusion as a Static Site Generator

Mike's Notes

Pipi has its own static site generator (SSG).

Resources

References

  • The Content Management Bible

Repository

  • Home > Ajabbi Research > Library > Authors > Bob Boiko
  • Home > Handbook > 
  • Hoem > pipiWiki > Engines > CMS

Last Updated

17/05/2025

Using ColdFusion as a Static Site Generator

By: Mike Peters
On a Sandy Beach: 29/12/2023

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Static site generators (SSGs) are engines that use text input files (such as Markdown, reStructuredText, AsciiDoc and JSON) to generate static web pages.

Static sites generated by static site generators do not require a backend after site generation, making them first-class citizens on content delivery networks (CDNs).

Some of the most popular static site generators are Jekyll, Hugo, Next.js (JavaScript), and Angular (TypeScript). SSGs are typically used for rarely changing, informative content, such as product pages, news websites, (software) documentation, manuals, and blogs.

Pipi 2

From 2000 to 2001, Pipi 2 used templates written in Visual Basic and stored in "Backpage", an Access Database, to render thousands of HTML web pages. I did the database design, Matthew Carter wrote the VB, and Graeme Cook gave helpful advice about MS Access. Many separate Access Databases store the data that the templates use to create each page.

Pipi 4

From 2005 to 2008, Pipi4 used templates written in ColdFusion CFML code to render 25,000 static HTML pages from data stored in an MS SQL 6 database. Each week, on a Wednesday morning, it took 2 hours to render every page. The logic was stored in a library of 550 class objects.

The book "The Content Management Bible" by Bob Boiko was a great help to me in figuring out how to build the CMS and the rendering engine.





Pipi 9

Now, in Pipi 9, the Pipi 7 CMS has been rebuilt. CFML templates have been added to automatically create a series of linked Wiki articles (like Wikipedia) that give an overview of each system and subsystem, and a set of classically framed "PipiDocs" (a bit like JavaDocs) that drill into the minute detail of each system.

The Wiki and Docs are also cross-linked. The next stage enables direct editing of the parameters of the underlying systems, which the Wiki and Docs then self-document—a reverse loop of sorts.

During testing in October 2023, 1200 static Wiki web pages of 300 systems were rendered in 7 seconds. I was surprised by how fast it was. This is a significant 500x performance improvement on Pipi 4. 

The CFML templates are nested and use a rule engine to determine where, when, and how they are used. As in Bob Boiko's book, I use content-type templates. In some ways, CFML is similar to Jekyll but much more powerful. CFML is straightforward to use and makes for fast prototyping.