Tag Archives: cloud

raas – the failure of “-as-a-service” in the physical world

Roads are empty something like 90% of the time.

8% of the time, they’re rightly-sized. 1.5% of time, they’re a little tight

1.5% of time, they’re a little tight.But that .5%? Holy CRAP

But that .5%? Holy CRAP are they ever too small when they’re too small.

Imagine if the “*-as-a-Service” model could be applied to roads: expand their capacity on-demand as use requires. It works for businesses expanding and contracting their technical needs (a la cloud computing).

It [could] work for getting fancy dentures when you need them.

I guess this is what flying cars are supposed to alleviate – but with ~220,000,000 registered drivers in the US, imagine even 0.1% of them driving flying cars. That’d be 220,000 flying cars. If even 1% of them decided to utilize the “flight” aspect at any given time, that’d be 2200 vehicles in the air. 2200 vehicles with no flight plans. 2200 vehicles in an unknown state of fueling, repair, etc. Air travel is currently the safest form of transport. Would that still be true with 2200 angry drivers trying to escape from the traffic they find themselves in at the same time? Especially given the non-uniform distribution of those vehicles (they’ll dominantly simultaneously appear in ultra-densely-populated areas and ultra-rural ones), this wouldn’t be the utopia of George Jetson. It’s be the insanity of Back to the Future Part II when the Delorean arrives in 2015 from 1985. But worse.

My best professor once said, “no one has gotten elected saying they want to eliminate roads”. But followed that up with, “every time roads are expanded, they get just as busy during busy times, and waste an awful lot of concrete the other 23.2 hours of the day”.

What we need is a way to carry-over the technological paradigm of “*-as-a-Service” into physical infrastructure. Because it sucks. Bad.

I don’t know best to approach that. Certainly the “sharing economy” models of Uber & Lyft are a component.

And self-driving cars will help.

But only when they’re not only “self-driving”, but when they’re actively communicating and optimizing with other vehicles. But what happens when you are “optimized” into a “slower” path because other vehicles were “optimized” into “faster” ones?

It’s certainly a thorny area of societal thinking to wade into. And one that needs lot of thoughtful input and consideration from many quarters.

putting owncloud 8 on a subdomain instead of a subdirectory on centos 7

After moving to a new server, I wanted to finally get ownCloud up and running (over SSL, of course) on it.

And I like subdomains for different services, so I wanted to put it at sub.domain.tld. This turns out to be not as straight-forward as one might otherwise hope, sadly – ownCloud expects to be installed to domain.tld/owncloud (and plops itself into /var/www/owncloud by default (or sometimes /var/www/html/owncloud).

My server is running CentOS 7, Apache 2.4, and MariaDB (a drop-in replacement for MySQL). This overview is going to presume you’re running the same configuration – feel free to spin one up quickly at Digital Ocean to try this yourself.

Start with the ownCloud installation instructions, which will point you to the openSUSE build service page, where you’ll follow the steps to add the ownCloud community repo to your yum repo list, and install ownCloud. (In my last how-to, 8.0 was current – 8.2 rolled-out since I installed 8.1 a couple days ago.)

Here is where you need to go “off the reservation” to get it ready to actually install.

Add a VirtualHost directive to redirect http://sub.domain.tld to https://sub.domain.tld (cipher suite list compiled thusly):

<VirtualHost *:80>
ServerName sub.domain.tld
Redirect permanent / https://sub.domain.tld/

Configure an SSL VirtualHost directive to listen for sub.domain.tld:

<VirtualHost *:443>
SSLCertificateFile /etc/letsencrypt/live/sub.domain.tld/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/sub.domain.tld/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/sub.domain.tld/fullchain.pem
DocumentRoot /var/www/subdomain
ServerName sub.domain.tld
ErrorLog logs/subdomain-error_log
CustomLog logs/subdomain-access_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
ServerAdmin user@domain.tld
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLOptions +StdEnvVars
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
# allow .htaccess to change things
<Directory "/var/www/subdomain">
Options All +Indexes +FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all

Comment-out every line in (or remove) /etc/httpd/conf.d/owncloud.conf.

Move /var/www/html/owncloud/* to /var/www/subdomain.

Make sure permissions are correct on /var/www/subdomain:

  • chown -R :apache /var/www/subdomain

Run the command-line installer: /var/www/subdomain/occ maintenance:install

Fix ownership of the config file, /var/www/subdomain/config/config.php to root:apache.

In config.php,

  • change trusted domains from ‘localhost‘ to ‘sub.domain.tld
  • make sure ‘datadirectory‘ is equal to /var/www/subdomain/data
  • change ‘overwrite.cli.url‘ from ‘localhost‘ to ‘https://sub.domain.tld

Navigate to http://sub.domain.tld, and follow the prompts – and you should be a happy camper.

above the cloud storage

Who wants to go into business with me?

I’ve got a super-cool storage company idea.

Load up a metric buttload of cubesats with radiation-hardened SSD storage, solar power, and [relatively] simple communicaton stacks (secured by SSH or SSL, of course), and launch them into orbit.

You think cloud storage is cool? What about above-the-cloud storage?


  • avoid national jurisdictional rules, since the data will never be housed “in” a specific country
  • very hard to attack physically
  • great reason to use IPv6 addressing


  • expensive to get the initial devices into orbit
  • software maintenance on the system could be annoying
  • need to continually plop more cubesats into orbit to handle both expanded data needs and loss of existing devices due to orbital degradation

Who’s with me?

dell buys emc

So I missed predicting anything like this one.

If you’ve been under a rock, like apparently I was last week, you’ve missed out on hearing Dell is purchasing EMC. For $67 billion. With a “B”.

This seems to be taking lots of people by surprise, but it makes perfect sense: Dell is already a huge supplier of servers into not only the SMB market, but also enterprise and cloud providers. EMC needs to find ways to keep their expensive storage relevant, especially in an era of storage proliferation, do-it-yourself options that are more than merely good enough, and less and less need for “dedicated” storage (though you still need flash in the underlying arrays, contrary to what Todd Mace thinks).

Thin provisioning, on-demand storage expansion and contraction (ok, ok – so the “contraction” part is not common), separation of duties via *aaS architectures, and more has been pushing EMC not so much to a bit or bench player, but into a corner of making it harder and harder to justify their pricing.

Silver Lake & Michael Dell obviously see the benefit of doing what some have claimed as the biggest merger in tech history (the Compaq-HP debacle was ~$25 billion back in 2001; AOL-TimeWarner was ~$106 billion, but not a pure tech merger). But the benefit is not the synergy of storage and servers.

Nor is it the management software, services groups, great corporate management, or anything of the kind.

The benefit will be in having a completely vertically-integrated and holistic offering because EMC is the majority owner of VMware.

That is why Dell et al wanted EMC. And why they’re willing to pay $67 billion in cash, stock, debt, etc to get it.

This move perfectly pivots Dell, already maneuvering away from “just” servers into a major competitor in the cloud space – especially the enterprise cloud space.

HP and IBM have their own storage and server offerings (IBM’s x86 offerings are all Lenovo now since they sold them off, but whatever) – but they don’t have the virtualization platform to bring it about in a soup-to-nuts way. Of course, HP and IBM will happily put VMware onto servers they sell you (IBM will also happily sell you non-x86 gear with their pSeries and zSeries stuff, but those are discussions for another day).

HP Helion and IBM Bluemix are interesting. But not as interesting, in my opinion, as Amazon’s AWS, OpenStack, and other offerings from !HP and !IBM.

Oracle is really the only main competition to the hybrid Dell-EMC company which will emerge, via their acquisition of Sun a few years ago (which is also a whole other conversation).

It’ll be interesting to see how the future HPE will try to compete against future Dell.