Invariant Properties

We often have the need for relatively lightweight services. How do we select the best hardware for the problem?

The first question is “what is the problem being solved?” A non-exhaustive list includes

• File server (SAMBA)
• Print server to put non-networked printers on LAN (CUPS + SAMBA)
• Backup server
• Blog server (WordPress)
• CMS server (Drupal)
• Database server (PostgreSQL, MySQL)
• Appserver (Tomcat, JBoss, Glassfish)
• Source control server (git, mecurial, svn)
• JIRA server
• Jenkins server (coordinator)
• Jenkins server (build node)
• Local maven repository (artifactory, others)
• LDAP server
• Caching proxy (network performance)

Some of these services would be production for our teams (e.g., file and backup servers, JIRA) while others could be specific to development or QA (database and app servers). Some could be development proxies for resources we don’t need locally but which will be used in the deployed environment (LDAP server). Finally some of them may be public – with cable modems it’s not uncommon for techies to run their own web server or even mail server on a home system. Assigned IP addresses rarely change and dynamic DNS services can handle updates automatically.

(I personally prefer AWS instances since I’ve had issues with Comcast reliability. When it’s good it’s very good but when there’s problems it may take months to be fully resolved.)

Modern “best practice” is to run each service on a dedicated system but that might not be practical in the SOHO environment since it could require a dozen individual systems. This needs to be considered – what services can coexist on the hardware without overwhelming it?

In nearly every case these services can be run on relatively lightweight hardware. What’s the best hardware choice?

What are the choices?

Conventional Desktop – This is the default choice. It can be a small form-factor like a Dell 3020 micro. They will use either spinning media or SSD as their disk.

AWS EC2 micro instance – A low cost virtual system in the Amazon cloud. (Note: there is also a nano instance and I’ll come back to that.)

Next Unit of Computation (NUC) class system – A conventional CPU in an extremely small form factor. These systems require mSATA drives. I have a last-generation BRIX.

Raspberry Pi – A low-power, extremely small form factor system. These systems often use microSD cards as their disks although it’s easy to set it up to use a USB stick or USB travel disk (spinning media or SSD) as the disk.

What distinguishes the systems?

Performance – Typical “bogomips” for the systems are desktop (4x 5000+), NUC (4x 3000+), Pi (4x 40+), EC2 (1x 4000+). There are two takeaways here. First, the EC2 is markedly less powerful than the desktop and NUC. Second, the Pi is 1/100th as powerful as a NUC or desktop. However it’s worth noting that many of us were happily using Linux systems with only single-core 150+ bogomips a decade ago. It might not be your first choice as a desktop or build server but it’s not a toy.

Some services require java. Desktops and NUCs handle tomcat without a problem. I had problems with the earlier t1.micro instance but I might have simply overwhelmed the system. Raspbian Pi includes openjdk 6 and 7 but I don’t have any performance information yet – however I was using Java on the pentium systems mentioned above.

Networking – Desktops, NUCs and Pi’s all support both wired and wireless connections.

Cost – Desktops ($1k), NUCs (< $1k), EC2 (<$30/mo), Pi (< $100). When comparing prices remember that NUCs are sold without memory or mSATA drive.

Power – Power is important since low power consumption means less heat (so you can put the system in enclosed spaces) and longer life when running on a UPS. A full desktop requires a lot of power, a micro desktop requires a laptop-grade power supply, a NUC requires a large wart (8A?), and a Pi requires a small wart (2.5A). This is an irrelevant issue for EC2 instances.

A Pi would probably be safe in a drawer as long as the cover is vented and it’s not covered. A NUC could go in a large drawer or a closet. My Dell 3020 micro is hot enough that I would prefer to leave it unenclosed.

Memory – Desktops and NUCs (16 GB), EC2 and Pi (1 GB). The former can run multiple services, the latter should probably be limited to single services.

Disk space and performance – Desktops (TB, spinning media or SSD), NUCs (500 GB, mSATA), EC2 (spinning media 8 GB default, expandable), Pi (microSD – 8 to 64 GB, can use USB external drives). The NUCs are the fastest since they have mSATA drives (~460 MB/sec reads), then desktops with SSD drives (~400 MB/sec reads). EC2s are slow (~80 MB/sec reads) followed by Pi’s (< 20MB/sec reads on microSD). I haven't tested the performance of Pi's on USB drives.

Reliability – PI’s have no moving parts. NUCs only have a CPU fan. Desktops have multiple fans and possibly spinning media. That said Pi’s may be more susceptible to disk corruption if the power is suddenly lost – it’s unclearif that’s the case or if the people reporting it are simply unaware of the need to cleanly shut down Linux systems.

Disk encryption – Desktops and NUCs have their OS installed conventionally and it’s easy to set up disk encryption. The standard AWS images are not encrypted but it is possible to use an encrypted image created locally. I don’t know if Raspbian supports encrypted root volumes but it should support mounting encrypted volumes.

What is the bottom line?

Appliances – For appliances like file servers I think a Pi is the way to go. You want these local (which rules out EC2) and single purpose.

Content provider (wordpress, drupal, etc.) – I want to do more research but for internal use I’m leaning towards Pi here as well, albeit with an database hosted on a NUC or even AWS RDS. This changes to EC2 if the system must be accessed from multiple locations.

Development support (git, JIRA, artifactory, etc.) – Again I want to do more research but again I’m leaning towards a Pi with remote database unless it must be accessed from multiple locations. I would monitor performance carefully. A NUC can run multiple services but it can become a maintenance headache. One service per machine is much easier to maintain.

Databases – NUC or AWS RDS (if acceptable), with one caveat. If you have extremely modest needs a Pi, perhaps with a USB drive, might be good enough and it will save you a lot of money. But if you’re doing development or QA – use real hardware.

Jenkins – Traditional build servers will require NUCs or desktops. A Pi is simply not powerful enough.

Caching proxies – A Pi may be a good choice for this. Even a slow microSD card will be faster than the network latency and 32-64 GB is more than enough space.

One final note

There is one final note – it is easy to create a snapshot of a Pi system and copy it to a new microSD card. It’s easy to toss an inexpensive Pi into the back of a drawer against future need. I routinely keep my old disks in case I need to retrieve information from them but have run into problems because I no longer have a 32-bit desktop or a system with an IDE controller. This shouldn’t be a problem with a Pi since it will be so easy to copy the data or keep old hardware.

There is a widely accepted design rule that you’ve failed if you need to use a sign. You can still use signs – and in many cases you definitely need to use signs (e.g., on emergency exits) – but it should be immediately obvious whether a door is pushed (push bar) or pulled (handle).

So the sign is funny but someone screwed up if so many people mistake the window for a door that they have to put up a sign.

How this applies to UI/UX is left as an exercise for the reader.

(P.S., I know the third possibility is that it’s a door that’s usually locked. In that case a simple “Not an Exit” sign would suffice.)

No deep thoughts here – nothing was difficult but there was simply too much too do while looking for a job, going to meetups several times every night, and running through Udemy classes so I’ll be able to talk intelligently when applying for jobs.

I’ll continue working on the problems in my free time and be in a better place when the capstone is reoffered.