Invariant Properties

  • rss
  • Home

Comparing EC2 t2.micro, Brix (NUC), and Raspberry Pi

Bear Giles | February 23, 2016

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.

Comments
No Comments »
Categories
Uncategorized
Comments rss Comments rss
Trackback Trackback

Enter Here. Or Not.

Bear Giles | February 17, 2016

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.)

Comments
No Comments »
Categories
Uncategorized
Comments rss Comments rss
Trackback Trackback

Cloud Computing Capstone – Final Thoughts

Bear Giles | February 17, 2016

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.

Comments
No Comments »
Categories
cloud computing
Comments rss Comments rss
Trackback Trackback

Archives

  • May 2020 (1)
  • March 2019 (1)
  • August 2018 (1)
  • May 2018 (1)
  • February 2018 (1)
  • November 2017 (4)
  • January 2017 (3)
  • June 2016 (1)
  • May 2016 (1)
  • April 2016 (2)
  • March 2016 (1)
  • February 2016 (3)
  • January 2016 (6)
  • December 2015 (2)
  • November 2015 (3)
  • October 2015 (2)
  • August 2015 (4)
  • July 2015 (2)
  • June 2015 (2)
  • January 2015 (1)
  • December 2014 (6)
  • October 2014 (1)
  • September 2014 (2)
  • August 2014 (1)
  • July 2014 (1)
  • June 2014 (2)
  • May 2014 (2)
  • April 2014 (1)
  • March 2014 (1)
  • February 2014 (3)
  • January 2014 (6)
  • December 2013 (13)
  • November 2013 (6)
  • October 2013 (3)
  • September 2013 (2)
  • August 2013 (5)
  • June 2013 (1)
  • May 2013 (2)
  • March 2013 (1)
  • November 2012 (1)
  • October 2012 (3)
  • September 2012 (2)
  • May 2012 (6)
  • January 2012 (2)
  • December 2011 (12)
  • July 2011 (1)
  • June 2011 (2)
  • May 2011 (5)
  • April 2011 (6)
  • March 2011 (4)
  • February 2011 (3)
  • October 2010 (6)
  • September 2010 (8)

Recent Posts

  • 8-bit Breadboard Computer: Good Encapsulation!
  • Where are all the posts?
  • Better Ad Blocking Through Pi-Hole and Local Caching
  • The difference between APIs and SPIs
  • Hadoop: User Impersonation with Kerberos Authentication

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Pages

  • About Me
  • Notebook: Common XML Tasks
  • Notebook: Database/Webapp Security
  • Notebook: Development Tips

Syndication

Java Code Geeks

Know Your Rights

Support Bloggers' Rights
Demand Your dotRIGHTS

Security

  • Dark Reading
  • Krebs On Security Krebs On Security
  • Naked Security Naked Security
  • Schneier on Security Schneier on Security
  • TaoSecurity TaoSecurity

Politics

  • ACLU ACLU
  • EFF EFF

News

  • Ars technica Ars technica
  • Kevin Drum at Mother Jones Kevin Drum at Mother Jones
  • Raw Story Raw Story
  • Tech Dirt Tech Dirt
  • Vice Vice

Spam Blocked

53,313 spam blocked by Akismet
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox