Distributed Services Rule, OK?
Why the Internet is kinda like a junkyard, and digital designers, developers and strategists are like MacGuyvers with pocket knives kludging interesting and useful combinations of online services while looking fabulous in a mullet.
To be honest, I’m not sure if the term “distributed services” is correct for my article (or if many designers/developers/strategists out there have mullets), but I use the term to describe the variety of many different digital services available online.
You may have heard something of “The Cloud” encompassing strange snake-like acronyms such as Software as a Service (SaaS), infrastructure as a service (IaaS), platform as a service (PaaS), back-end as a service (BaaS), etc. With this article I’m looking generally at the some behaviours of the online ecosystem operating by combining various services together to help “doing stuff” online, and how you could consider using distributed services for digital strategies that you are currently doing, going to do in the future, and/or consider designing and building your service to be among those distributed. You could be that one who’s all about that BaaS.
Here’s a simple example to get us started: a website for a band could include their Instagram profile for photos, Bandsintown page for upcoming shows, YouTube for music videos and their Twitter or Facebook feed with news and updates (cue audience “oohs” and “aaahs”). Maybe you want to build a service where a user writes a simple yes/no question and they can then embed it on their website or Facebook feed to get instant responses. Let’s just think, think about it together.
It feels like it’s been this way since… well, since forever…
When you make a meal, you often use different kinds of “things” to achieve the final outcome: ingredients, utensils, appliances, and even cooking techniques.
The same could be said of many other activities in life: building houses, making clothes, etc. The house itself is also a combination of different types of things and services all combined to create a comfortable and relaxing living experience: shelter, insulation, security, power, heating, furniture, and so on. It’s kind of related to that classic Gestalt theory quote by Kurt Koffka that states “the whole is other than the sum of its parts”. If you had a pile of wood, bricks, a location and then some building know-how, they’re only a comfortable house to live in until you put it all together. Much like online digital solutions are!
Often we operate in a task-focused mindset, one which relies on assets and these assets needing actions done to or with them being completed in a particular order (a method or “process”, much like recipes, project timelines, Lego kits…).
Let’s say for instance that you need to do your tax return accounting. You’d look through your statements (assets of data, which represent your financial in-and-out-goings), collate it all into some computational array (an accounts book if you’re old school, or maybe spreadsheet software if you were born after 1950) to create data relationships and abstractions which allow you to perform the necessary operations to then determine the amount of money you’ve earned, that which you have spent, and that which you must then pay to the government. After that, you’ll then file your tax return using specific paper forms (or some fancy cool e-tax software — either way it formulates the data you send to the third-party so that they can read and understand it) which the government body who then analyses it to perform whatever final necessaries are needed (Yes, credit! No, debit!). SIMPLE!
Since computers have now become a household standard, you can see the points I mentioned above in the tax return example in which the computer has stepped in to lighten the load. With the interconnectedness of the Internet, there’s even more opportunity for technology to step in-between and lighten the load yet again. For some cool tech-savvy countries like Australia, e-tax software or online platforms where people can input all their data (hiya Xero!), answer some questions about their tax position and have the software calculate their return and send the information to the government body to process. So easy! So handy! There’s now many a phone app which can take photos of receipts for you to categorise (one called Shoeboxed) and the necessary information is scanned and placed into your digital accounting books to then do all the cool computations to automate your final tax return numbers. Gee whizz!
Island life
Back in ye old ‘90s and 2000s (and maybe into the 2010s) websites were kind of “island”-like affairs. If you ran a website, you often served everything that you needed to use directly from your web server: text, images, videos, audio files, everything. If you had particular tasks that you (or your visitors) wanted to perform, you’d have to bundle it all in within the site’s infrastructure.
That’s nice and all if you want absolute control over how everything looks and works (and maybe legal things like copyright), but it also means that you would have to potentially build and manage (or at least find the software/hardware/people to do) the running and maintenance of it all. It’s a lot of work and can be rather complicated and expensive to setup and maintain.
Nowadays, we have great external services like YouTube and Vimeo for video hosting and distribution, Flickr and Picasa for photo storage, SoundCloud for audio, and many more million others for various other kinds of data and resources (Pinterest for research/scrapbook collections; Twitter for news; Tumblr, Blogger and WordPress for personal journals; Google Analytics for usage data capture; Google for site searching; Eventbrite for events and ticketing; LinkedIn for employers and employees; Dropbox and Box for file storage, etc.). It’s common for websites nowadays to utilise a collection of services to provide the means to store, retrieve and manage the assets we use and the actions we need to perform to then make and arrange meaningful connections between 'em all.
I didn’t mean to turn you on...
Ages ago they used to tout USB as being this fantastic “plug-and-play” feature where if you needed to print something you just wham a printer into the USB port and boom-shaka-laka you’re free to just print straight to it without having to install printer drivers (in a perfect world perhaps…). That’s kind of what distributed services are like for websites these days.
If you want to embed a video to play on your website, you just take some kooky embed code given to you by the site the video is hosted on (Imma just take a minute to say “hallelujah!” to OEmbed), plop it in your website and then Bob’s yer uncle: you’re watching him accidentally setting fire to his beard at the last family outing with the blog entry you wrote about the whole debacle and how your family still doesn’t quite understand you. Want people to respond to your post? Disqus allows people to write comments to the blog post. Want people to share your post? Widgets like ShareThis and AddThis allow quick social network sharing buttons on any page to help content go viral. Announce the blog post via your Facebook and Twitter profiles to attract people to read and watch, and use hashtags to categorise information so people can find you when searching for those terms.
Say you composed a song about Uncle Bob’s flaming beard, uploaded it to SoundCloud and then embed that track onto your website too. Imagine you get so many hits about the blog post and the song that you then decide to play a live show; there’s probably a website out there that you can advertise your show and sell tickets that has a widget that you can embed on your site for your visitors to see and interact with (at least two, one called Bandsintown and the other Songkick).
DFF: Digital Friends Forever
The benefit of distributed services is that it allows you to take someone else’s hard work setting up and maintaining a service, and easily incorporate it onto your site. Hell, you don’t even need a central site! Many fancy people all across the world have set up website services in which all you do is sign up for free and then start posting your content. You’d be surprised at how many websites these days are just a collection of these utilised distributed services (I don’t know the numbers, but I do know that you’d be surprised...).
But what if you need to do something a bit more interesting than just advertising events or showing goofy videos? What if you needed to take some information, put it through some other operation or function and then put that somewhere else? Or, what if you needed to combine multiple external services?
Most distributed services have a layer just “under the hood” which allows developer-types to interface with the service through a specific protocol: rather than using the site’s front-end interface (or GUI — graphical user interface), you could code within your own site’s programming the means to connect and interact with these distributed services, to create a seamless interaction between however many distributed services you use.
Imagine you wanted to make an app which stores some information on your own servers, but also handled photo, video and audio capturing. Perhaps you want a low overhead with your app and don’t want to host the media files. Use those other services like YouTube, Vimeo, Flickr and SoundCloud instead! Or you could even use something like Facebook (which handles photo, video and audio) to store for your users. By interacting with the external service via an API, you can craft and deliver a nice interface that looks like it does all it needs, but hosts the media on some other relevant service that your user already uses. Interesting other caveats await such usage, but I will leave those behind a big rainbow coloured curtain labelled “another time”.
Cool combinations, bro
So with distributed services, building digital experiences now is kinda like playing with Lego, where you take some bits of this thing over here, add some other bits of that thing to this thing, put that bit here, another there, and then you’ve got an interesting cocktail of information, process and interaction.
The other interesting thing about distributed services is that it isn’t just about how the services interact between each other, but how we as humans use a range of distributed services in tandem. It could be that we use a number of different services which do similar things, but with differing quality and features, e.g. the difference between YouTube and Vimeo is that Vimeo has a more premiere quality and feel. It could be that your firm has both a YouTube and a Vimeo account which host the same videos in order to target two differing markets: YouTube is the dominant destination for people to absorb video content, is supported by a number of different playback devices and environments but displays videos with advertising and at a potentially lower quality; Vimeo is primarily aimed at the design/premium market and is more “upmarket” except with a much much much smaller audience, however the quality of the video for playback looks much better (plus no video ads — that I know of…).
The most common field of distributed services that individuals and companies use are social networks. Facebook, Twitter, Instagram, YouTube, Pinterest, Blogger, Tumblr, and more allow for people to connect, communicate and share ideas and media in whichever way the service permits. Each network has its flavour-flave — its “je ne sais quoi” — which engenders an audience to engage with it, and such individuals and companies use these angles to spread their personalities and messages out into the wild wild ‘Net, all in a bid for views, comments and likes. Marketing is often the modus operandi for social networking.
Heard of If This Then That? Maybe you should check it out. It works as an “in-betweener”, taking all these different channels and services and allowing you, the user, to create new connections and usages. Sky’s the limit, my friend.
Mo’ stuff, mo’ problems
So what happens when you have to use multiple services which all kind of do the same thing? In the case of social networking there exist some applications which allow people to post the same content across the different channels. This can be with varying levels of quality and success (Ping.fm was okay and short-lived, but in its stead Buffer is pretty good, but still a bit limited). The changing environment of services’ APIs can make some other services which rely on them slow, or costly, on the uptake.
The technological environment is an always-changing beast. As long as the software developers communicate openly and are motivated to do well, then things can proceed nicely. Technology often attempts to be more efficient, and sometimes that means having to change how it was done previously. Most distributed services’ APIs are “versioned” (i.e. they have multiple versions available for backwards compatibility) but can also be decommissioned if the business logic costs too much (or they get rate-limited/monetised. Read this interesting The Guardian article on why Apple dropped Google Maps to then develop their own back in 2012).
There are other issues almost too numerous to mention (international law regarding data storage and copyright issues, legal issues on what kind of data you can hold and how attributable it is to individuals, etc.). But generally distributed services build into their business models the machinations to address these issues, so you can generally do your thing willingly without worry.
And then… ?
Distributed services are really the building blocks of the Internet these days. It’s not just the programming language you use or where you have your website hosted (sometimes you don’t even need a host), it’s the network of services you can successfully connect together thanks to APIs and those enterprising sorts who design and build these things to take in something and spit out something else so you don’t have to do the bits between.
It makes one think that while coding is a valuable skill to have, the future may lie in the combination of services that one uses, rather than the building of them.