Let’s say you just finished your undergrad in computer-science and got hired as the lead developer in a small start-up that’s developing a novel hardware product. How would you go about choosing the tools of your trade?
Here is my high-level take on a few of the nodes in a software group structure and the information flow between them. I am not going to discuss any tool-chains in this post as they are slightly lower level than the scope I want to present.
NOTE 1: The following configuration is derived from my experience developing code for an architecture that contains some hardware driven by a micro-controller which then connects to a computer running an application that is the interface to the user.
NOTE 2: This IT infrastructure is most likely NOT IDEAL for web-centric app development.
I will now go through (in alphabetical order) a few of the nodes and explain why I think they are important:
Box1 – Code Server:
The Code Server stores all the code related files. In my case it runs a Mercurial server for source control management and a Redmine server for bug tracking/feature requests and general software project maintenance. I chose Mercurial (as opposed to the dominant Git) because it has a high available-functionality to complexity ratio. A few of the features that made me stick with Redmine are that it integrates nicely with Mercurial, it is fairly customizable using a range of plugins and it is free. One of the downsides of using Redmine is that it’s a little trickier to update.
As far as the actual platform, the Code Server, is a VirtualBox running off Ubuntu OS. I assign it initially 64GiB hard drive space with 2GiB of RAM. As the software project grows you might need to assign it more space.
Box2 – Wiki Server:
A wiki is one of the center piece software modules of a start-up. It can store anything from contact info for suppliers and purchasing procedures to assembly instructions and recycling locations. The principle that anyone can edit it and improve it creates a hub for all members of the team to congregate around. For the wiki engine I choose MediaWiki over DokuWiki. DokuWiki is great because it does not need a mysql DB, however it does not have as an extensive set of plugins as MediaWiki.
Hardware wise, this is also a VirtualBox running Ubuntu. 32GiB hard drive space and 1GiB RAM should suffice. I like to keep the Wiki Server decoupled from the Code Server because as it has a higher user demand ideally it has as little downtime as possible. The fewer services the Wiki Server runs the more likely it is that it won’t need a restart.
Box3 – NAS:
This is real hardware and as the company file server is one of the corner stone of the Software Group. As I don’t like to maintain file servers I default to a Synology’s DS412 Disk Station NAS. Even though they it is a little more expensive (as of 2013 it is $700 and with 4x 3TiB $600 it comes in at $1300 all in) the piece of mind of not scrambling to fix someone’s file access problems, when your plate is full with fixing high priority bugs and implementing some last feature that changes 50% of the software architecture, more than makes up for it. The Synology box is your file storage solution and as such you wouldn’t want anything bad to happen to it. What I am driving at is that all the data on it needs to be backed up somewhere safe. When it comes to back-up solutions I like to use CrashPlan. They have great client software and good prices. Not to mention I like they’re corporate attitude – just go and read some of their job postings and you’ll know what I mean, young paduan.
This is the real hardware PC on which all the virtual boxes will run. As such it needs to be adequately fast and stable. As of this writing (2013) I would like the following configuration an i7 3770k CPU ($350) with 16GiB of RAM ($150) and a 256GiB SSD ($200). No need for a monitor or a stand alone graphics card as this box won’t be running anything fancy. Though you will need a motherboard ($150), a case w/ power supply ($150) and a puny keyboard ($10). I like to think that running a Windows7 64bit Professional ($150) as the host OS is slightly better than a Linux distor just because of the drivers support available. I seem to think Microsoft and Intel optimize their packages for each other but I admit I didn’t do any research into it. All of the above comes in at around ($1200) and will form the other corner stones of the Software Group.
- i7 3770k CPU (NCIX sku: 70540)
- 16GiB DDR3 RAM (NCIX sku: 66354)
- 256GiB SSD (NCIX sku: 60446)
- Motherboard (NCIX sku: 71114)
- PC Case (NCIX case sku: 55583
- Ppower supply (NCIX sku: 67325)
- Keyboard (NCIX sku: 54063)
I happen to think that Virtual Box is one of the best creations in OS history. It allows for decoupling of the OS from the underlying hardware and more than that it provides for a straight forward, fast and robust backup and restoring procedure. I can export my VirtualBox client which contains all the source control and issue tracking repositories I develop on, move it on a USB stick and then import it on my laptop’s VirtualBox. This way I can have my server with me wherever I go. Yes, yes it’s actually not as simple as this and with great power comes great responsibility but these are topics for another discussion.
I have been using Crash Plan as my cloud backup solutions for a few years now. It has a simple interface and allows for incremental backups. The data is encrypted locally and then uploaded into the cloud which means Crash Plan doesn’t have access to my files. For a small start-up needs I find it more than adequate. A few caveats related to backing up. The original seed backup will take a long time. If the full backup needs to be restored expect a few days to get it on HDDs. However in this case I find that in most cases only a small percentage of the backed up data is touched during daily operations. Most of the backed up data being stored on the NAS being stale. Ideally the start-up has a fast connection (most often the case if it’s a spin-off from an university lab research) and in case of NAS failure a small daily-work chunk of data can be immediately restored and the users can continue working off it.
Having a solid infrastructure for the software team from the get-go allows you to focus more on the development of the core software rather than on development of maintenance procedures and ancillary software.