Tag Archives: software

Server Backup with Spider Oak

I’m a SpiderOak fan. It’s secure, easy and well documented. Some really good traits. Their support is fantastic too.

After using it on my Laptop, I thought I’d start using it for my Debian server’s backup. It makes sense to use something that bundles encryption and zero-knowledge to satisfy offsite backup.

The same client you would use on your Linux desktop can be used in headless or batch modes. Combined with the --backup command, you can target your essential backup areas quickly and easy.

Assuming you have signed up (you get 3GBs free with this referral link), all you need to do is follow these easy steps.

Step 1 – Get SpiderOak on your sever
wget https://spideroak.com/directdownload?platform=slackware&arch=i386

Extract it to a place of your choosing and cd there (for argument’s sake, we’ll call this extraction directory $SO_HOME).

Step 2 – Copy the shared libraries
SpiderOak’s client will expect shared libraries to be available on your system. These are bundled in the .tar.gz you’ve downloaded. Copy these to your /usr/lib/ to make life easy.

cp $SO_HOME/usr/lib/SpiderOak /usr/lib/ -R

Step 3 – Initialise SpiderOak
You need to give SpiderOak a username and password and then let it add the server as a new device. You can do this by executing the following command and completing the prompts:
SpiderOak --setup=-

Step 4 – test the client works
Running a simple $SO_HOME/usr/bin/SpiderOak --help should show no errors and present you with the help message.

Step 5 – run a backup
Now all you’ll have to do is execute SpiderOak with a backup target and let it run!

SpiderOak --batchmode --backup=/home

Voila!

Modern Service Oriented Architecture: the basics

Just some of my notes on looking over SOA related theory.

What is “SOA”?
Service Oriented Architecture is a means of exposing business services
separately from their platform and codebase in order to provide local
and/or remote invokation of said services through abstracted data types
and signatures.

Put simply: SOA allows you to talk to alternate platforms by removing
the bespoke or language-specific features and data types to a
higher/specified representation providing interoperability between
platforms without the need for their awareness of eachother.

As a real world example, an organisation can provide interoperation
between legacy and new systems by abstracting the manner of how they
talk and the underlying content: new code can use technologies like XML
to define the data and the corresponding types and the two systems can
work together through that abstraction. This scenario is commonplace
among business where different streams are responsible for systems and
so a common format for data interchange is necessary to allow the two to
co-exist separately.

SOA also provides a more modular approach to service integration: if a
web service can “proxy” requests from one system to another, the two can
change independently without the need for related changes to the
services themselves. Such a scenario – one of proxying – can encourage
an ecosystem of services allowing each to communicate with seemingly
unrelated counterparts through a common set of data types and methods.

Benefits of SOA
Typically, the “promises” of SOA are numerous.

SOA allows for system agility
As aluded to previously, the ability for bespoke systems – those written
for specific purposes in a language of choice – to communicate with each
other allows for greater flexibility and scalability with an
organisation’s data. For example, if you can have your sales systems
talking to your suppliers through an aggregation service to warn of
unusual sales volumes, out-of-stock items and so-on, you can better
support the volume of a growing business and provide real-time response
to customer needs.

Consider an organisation where a sales system cannot speak with the MI
to ascertain whether a customer on the phone holds an account with you.
Crazy, no? In scenarios like this where legacy, decades-old and
difficult to support systems hold the key to sales success but are the
hindrance to it, SLA can be leveraged to quickly and easily have the two
communicating and providing front-line departments with the information
they need.

SOA can encourage innovation
In the post-Google era, notions of service “mash-ups” are commonplace.
These newfound, new-age businesses popularised the developer by
harnessing open source technologies and building public-facing APIs: all
built on service oriented architecture. They encouraged interoperation
between seemingly unrealted entities which built a platform for
innovation and a revolution in the software industry.

If you reduce this scale and manage to accomplish this very nature
within an organisation, then new products and alternatives to existing
ones spring from innovative and organic attitudes from developers and
system integrators.

You wouldn’t build a palace with breeze blocks

I strongly believe that if you want to build awesome software, then every aspect of it needs to be as good as you want the final product to be.

It is often the case that aged software shops will have put in place aspects of their software that they’ll “revisit later on”, which then doesn’t happen.

It gets lost to the crowd of “more important things to do”.

One of the most common neglects I see is how a shop will build, deploy and distribute its software. At best their solution is amateur. It’s usually home-baked and rigged with esoteric and often superfluous tasks and features that are “necessary” due to some poor design decision made previously. The build system — be it continuous integration or some poor sod in the corner — has to do 30 different things, copy 11 thousand files, just to compile the few.

And so the problem persists; the rot festers; the software continues to be sub-par and so do the profit margins.

I feel that if you start from the ground-up, that you build consistently and efficiently then your software becomes such. If it is easy for a developer to build and deploy or distribute your software, it’s then easy for them to do their job. Any developer knows the pains they’ll go through day-to-day when making a change that requires a 15-minute rebuild and 5 minute deployment wait just to check the first name field doesn’t fall over on a null pointer.

With poor practice comes poor software comes poor profit.

So if you’re heading up a development shop and your developers are crying for a more efficient, simpler, consistent build process, then heed their recommendations and concerns. Let them spend the time and money streamlining how they work, because you’ll get reliability, efficiency and less coffee breaks if you do.

Would you pay for that shiny new tablet PC if it came packaged in A4 paper?

How disappointed do you feel with a product when you hold it and you “know” its build quality is poor.

Why is software any different?

You wouldn’t build a palace with breeze blocks.