Storagezilla

Sync & share. For anyone. For everyone.

Having spent some time speaking to customers, partners and distributors across Europe I wasn’t surprised by the…cautious..approach Europeans have to sync & share.

It’s not enough to have a data center ‘in the region’, Europeans want that data center to be down the road. And if we can show up and take a tour, grab a coffee and have a biscuit we’ll do that too.

That’s why the full ‘as a service’ sync & share offerings will do business with a certain customers but will find others to be impenetrable. In this case you’re not selling an idea, you’re trying to change a culture and while ideas come and go culture lasts for generations.

So what do you do to fit into the culture? You build data centers of course!

The problem with data centres is they cost money to build. Mozy has a huge amount of production storage under management and when I look at something like Mozy Stash, which uses the Mozy backup application to ingest files thereby allowing for remote file access via the Mozy desktop, iOS and Android apps directly from Mozy’s datacentres, and I consider the infrastructure investment it would take to stand that up in every country in Europe, it’s head spinning.

What’s much more practical is to allow people to stand up their own sync & share services in the data centres they already own or already rent. Thereby allowing them to take those data center tours any time they choose.

Syncplicity with Atmos as it’s storage backend allows people to do just that. Deploy sync & share in your own data center or at a local service provider of your choice, using global namespace multi-petabyte object storage as the repository. 

Your data resides inside Atmos, with object puts and gets from inside the organisation or authorised clients out on the internet flowing through stateless Syncplicity compute nodes (VMs or x86 servers running Syncplicity code in HA mode) located in a DMZ, which use an Atmos tenant as their storage repository.

These nodes provide front end connectivity for the desktop and mobile Syncplicity clients and perform various file transfer (resume, retransmission, compression) and optional security (inline file encryption) functions.

Only the Metadata and authorisation control, the over all orchestration components of the system, exist as a SaaS function outside of your data center. The data itself remains local to where ever you decide it should be local.

Of course, if you really hate your end users you can deploy it in a way that they have to login to the corporate network to access the data via your VPN. But what backward looking IT sadists would ever do that? -blink- -blink-

Mozy Stash and Syncplicity with Atmos.  Two different offerings which cover the broad spectrum use cases for file sharing.

In public and in private.

The final generation.

The final generation of Mainframe operators, those who entered IT before the emergence of client server computing and the rise of open systems, have nearly all retired. Within in the next two years as members of the IT community they’ll be either be endangered or extinct.

This is an interesting time in the Mainframe segment. The Senior Mainframe Admin promoted to take the retirees spot probably cut their teeth on Windows & Linux, have bought more than one iPad and were amongst the first to rip their Nirvana CDs to MP3s and then torrent them.

Change is coming to Mainframe land.

How to rig the game when asking for new software features.

One of the biggest time wasters I’ve come across in my working life are meetings. That’s not to say meetings aren’t important, they are, but when badly run they’re torture.

Meetings with your co-workers or partners or customers are very important but meetings shouldn’t be about deciding things, the decision making process at the top is much less public than anything you’ll ever see presented in a meeting format, so meetings should be about communicating what’s already been decided and taking feedback on that and/or assigning tasks to carry out the decisions that have been made.

Since I moved out of technical pre-sales and into a more strategic thinking role a lot of my time and nearly all of my travel time is spent communicating to co-workers, partners and customers what has been decided and how we are going to proceed.

I may have had some direct input into a few of those decisions, for a lot of others I probably won’t have, but I always attempt to dig out the ‘why this and not that’ of any of the major decisions and as a result I end up (usually) with a well run meeting. Well run doesn’t mean neat & tidy, good meetings are messy, what it means is at the end of it people are clear about where things are going and why we’ve decided to go there.

In such meetings feedback is always welcome but it needs to be the correct kind of feedback.

Lets say there’s an issue of some sort. A piece of functionality that needs to be added or changed to act in a different way. If you can cleanly define the issue and do it in an amount of time that doesn’t put people who don’t care too much about this peccadillo into a coma you’ve started well.

That’s the easy part and being direct it’s the incredibly lazy part.

Where you need to start really thinking and what you’d need to be able to communicate clearly, pictograms and cave paintings are acceptable, are things such as: 

-What you think the solution should be?

-What alternatives have you considered?

-Is your solution reactive because some other product out there does this right now? If so are you solving a real problem or just checking a box?

-How flexible are you to the solution being totally, completely and entirely different than what you’ve proposed if it solves the problem?

That last one is actually a major challenge with some people. If you can crack the problem but don’t do it in a way they think it should be done, they come back to you with your solution presented as a new problem. It isn’t, it’s a solution to the problem they highlighted, probably implemented in a technical way that makes sense for everything else you’re trying to achieve in the context of your product vision.

You’re never going to get everything you want into a product release and have it ship with high quality and on time. The list of things you can do is dwarfed by the things you want to do. Both of those being tiny in the face of what you realistically can do.

That’s why it’s important to have thought out from end to end what you’d like done before you ask for it.

The easier it is to say yes to a coherent well thought out piece of feedback the greater the odds things will get done.