The spacesuit of today is much the same as the one of the last few decades. It’s an incredibly complicated device, combining all the systems necessary to keep an astronaut alive in the vacuum of space into a wearable package. However it’s not the easiest thing to use, often requiring extensive training not only to get familiar with it but also to train your muscles in how to use it. This is mostly because the design, which makes even the slimmest astronaut look something like the Michelin Man, is centred on ensuring that the pressure on the astronaut’s body is kept constant. This is currently done using an inflated lining which is quite restrictive however future designs, like the one from MIT, could provide the same protection whilst giving astronauts far more freedom.
Our bodies are accustomed to 1 atmosphere of pressure which, on the grand scheme of things, really isn’t that much. Indeed the difference between what we’d consider normal pressure and a complete vacuum is about the same as going 10m under water, something SCUBA divers do on a regular basis. However the trick is ensuring that that pressure stays consistent and constant over your entire body which is what led to the spacesuits today. Interestingly though it doesn’t matter how that pressure is generated so the traditional method can easily be replaced with something that’s mechanical in nature, which is what the new BioSuit from MIT seeks to do.
Instead of covering the astronaut’s body in what amounts to dozens of inflated pillows the BioSuit instead looks to use Shape Memory Alloys (think nitinol wire, if you’ve ever played with it) to provide the pressure. Essentially they’d have a full body tourniquet that would be embedded with this wire and, upon heating, it would contract around the astronaut’s body, providing the required pressure. How that pressure would be maintained is still a problem they’re working out (as keeping the astronaut heating constantly isn’t exactly ideal) but seem to be making good progress with various clip designs that would keep the suit tight over the duration of a spacewalk. They’d still have to have the traditional fish bowl on the head however as employing a system like this on the head wouldn’t really be feasible.
Whilst a suit like this wouldn’t provide complete freedom of movement (think a wetsuit that feels like it’s a size too small) it would be a vast improvement over the current design. Right now every time an astronaut wants to move a part of their body they essentially have to compress the protective bubble of gas in their suit, something which ends up being extremely tiring over the course of a long duration spacewalk. A design like this would likely require far less energy to manipulate whilst also allowing them to move a lot more freely, significantly reducing the time they’d need to spend outside.
For me though it’s just yet another piece of sci-fi making its way into reality as we’ve long dreamed of spacesuits that would be like a second skin to its wearers. Better still it’s being made with technology that we have available to us today and so no exotic material sciences is required to bring it to fruition. We likely won’t see any astronauts wearing them any time soon (the cycles for these things are on the order of decades) but as time goes on I think it’ll be inevitable that we’ll move to suits like this, just because of the vast number of advantages they offer.
Since my side projects (including this blog) don’t really have any kind of revenue generation potential I tend to shy away from spending a lot on them, if I can avoid it. This blog is probably the most extravagant of the lot getting its own dedicated server which, I’ll admit, is overkill but I’d had such bad experiences which shared providers before that I’m willing to bear the cost. Cloud hosting on the other hand can get nightmarishly expensive if you don’t keep an eye on it and that was the exact reason I shied away from it for any of my side projects. That was until I got accepted into the Microsoft BizSpark program which came with a decent amount of free usage, enough for me to consider it for my next application.
The Azure benefits for BizSpark are quite decent with a smattering of all their offerings chucked in which would easily be enough to power a nascent start up’s site through the initial idea verification stage. That’s exactly what I’ve been using it for and, as longtime readers will tell you, my experiences have been fairly positive with most of the issues arising from my misappropriation of different technologies. The limits, as I found out recently, are hard and running up against them causes all sorts of undesirable behaviour, especially if you run up against your compute or storage limit. I managed to run up against the former due to a misunderstanding of how a preview technology was billed but I hadn’t hit the latter until last week.
So the BizSpark benefits are pretty generous for SQL storage, giving you access to a couple 5GB databases (or a larger number of smaller 1GB ones) gratis. That sounds like a lot, and indeed it should be sufficient for pretty much any burgeoning application, however mine is based around gathering data from another site and then performing some analytics on it so the amount of data I have is actually quite large. In the beginning this wasn’t much of a problem as I had a lot of headroom however after I made a lot of performance improvements I started gathering data at a much faster rate and the 5GB limit loomed over me. In the space of a couple weeks I managed to fill it completely and had to shut it down lest my inbox get filled with “Database has reached its quota” errors.
Looking over the database in the Azure management studio (strangely one of the few parts of the Azure that still uses Silverlight) showed that one particular table was consuming the majority of the database. Taking a quick look at the rows it was pretty obvious as to why this was the case, I had a couple columns that had lengthy URLs in them and over the 6 million or so records I had this amounted to a huge amount of space being used. No worries I thought, SQL has to have some kind of built in compression to deal with this and so off I went looking for an easy solution.
As it turns out SQL Server does and its implementation would’ve provided the benefits I was looking for without much work on my end. However Azure SQL doesn’t support it and the current solution to this is to implement row based compression inside your application. If you’re straight up dumping large XML files or giant wads of text into SQL rows then this might be of use to you however if you’re trying to compress data at a page level then you’re out of luck, unless you want to code an extravagant solution (like creating a compression dictionary table in the same database, but that’s borderline psycotic if you ask me).
The solution for me was to move said problem table into its own database and, during the migration, trim out all the fat contained within the data. There were multiple columns I never ended up using, the URL fields were all very similar and the largest column, the one most likely causing me to chew through so much space, was no longer needed now that I was able to query that data properly rather than having to work around Azure Table Storage’s limitations. Page compression would’ve been an easy quick fix but it would’ve only been a matter of time before I found myself in the same situation, struggling to find space where I could get it.
For me this experience aptly demonstrated why its good to work within strict constraints as left unchecked these issues would’ve hit me much harder later on. Sure it can feel like I’m spinning my wheels when hitting issues like this is a monthly occurrence but I’m still in the learning stage of this whole thing and lessons learned now are far better than ones I learn when I finally move this thing into production.