So, as I was saying before, it’s a little rough around the edges, but it’s now ready for testing and verbal abuse!
So, until there’s a Kubernetes Operator for an Ethereum test chain (or something comparable where you click a button to get everything running and perfect), it seems like you’ll have to do things a little more manually when it comes to setting up an Ethereum development environment in the cloud. Why’s that? Because with a nascent tech like Ethereum, everything keeps changing rapidly, and a Docker image with an embedded Ethereum testchain and dev tools will be outdated in just a few months. So, in the end, you’d have to do the same thing anyway with just a basic Docker image: download the latest packages, make any needed adjustments to get a testchain working, and then refactor your code (Solidity, etc.) so that it’ll now compile without warnings or errors.
So, when I heard that Microsoft had created a service that would wrap around Ethereum, my eyes started to sparkle. Finally, I wouldn’t have to worry about playing the role of admin or devops, so that I can just develop…
…but then I promptly stopped and thought “Wait a minute? Microsoft? Creating a PaaS with Ethereum? Hmmmm…I don’t know about that…” Still, though, I’m willing to try anything once, so I decided to give Blockchain Workbench a chance.
So, I tried out Workbench to get a quick impression, and after a few hours, I think that I have a fair assessment of it. Now, if you’re a beginner, I’d recommend it: it’s a good place for an Ethereum beginner with an Azure account. But (and I’m trying not to be too harsh here), I would say that’s where its potential would be maxed out. Beyond being interactive teaching software for enterprise officers to learn about blockchain, I doubt that it’s something Ethereum developers or proponents would ever use. Not only is the Ethereum node completely hidden and inaccessible, the Workbench is an abstract wrapper around the node, so abstract that it becomes an hindrance to even communicate with the node. In the end, it’s completely unfriendly to a developer, an opinion which seems to be shared by others.
However, I will agree with Dimitrios on a second point: Microsoft’s template for Ethereum PoA could be useful. After experimenting with that one for an hour, I could totally see a consortium opting to try it out as a shared Ethereum solution.
Plus, there’s another addition to the family. In order to demonstrate its abilities when integrated into web services, there’s also now the new project WonkaRestService, a ASP.NET REST service that showcases how to use the Wonka library. Perhaps, one day, it might even become an Azure Logic App Connector. I know, it’s a lofty goal…but let a kid dream.
So, after wolfing down a lunch of Czech dumplings from the ample buffet and walking past the Giveth guy (who I didn’t know at the time and just thought was wearing a bad Halloween costume), I headed to the talk by Golem, out of curiosity since I had no idea who they were. Plus, since we were in Prague, it seemed appropriate. And after a few confused minutes, I finally got it. Wow.
Basically, Golem was offering a secure platform that decentralized the notion of buying and selling cycles of computing power. Instead of AWS EC2 and Azure VM, you could purchase your power from anonymous sources around the world. And on the other side of the coin, you could become an independent vendor, offering your computers as computing providers on the network. As a vendor, you’d just install their software on your machines. Of course, one would think of all the possible questions about trust on such a platform, but it seemed that Golem had those bases covered.
And how does Ethereum fit into all of this madness? It’s the transaction-based layer of the platform, of course! All agreements and purchases would occur within the Ethereum blockchain. How beautiful is that: one decentralized platform supporting another! After that lecture, I was hungry to discover what other projects were being developed with Ethereum in mind. So, where to next?!
So, it’s been a while since I talked about indoor navigation. It’s one of those things that I always come back to, especially since that idea for the ghost game always comes back to me now and again. After a conversation with a hardware grad student in a PhD program, I got excited about the idea again and went looking once more for a software solution. As it turns out, Microsoft wants in on the action. After playing with it for a while, though, there’s only one problem: much like other indoor navigation solutions, it doesn’t work exactly.
In my apartment several stories up and which occupies only one floor, I will walk several feet. Then it will suddenly prompt me, asking me which floor I’m headed to. Apparently, it thinks that I’m in an elevator or on an escalator.
With all the difficulties amassed between AR and navigation, it’s no wonder that Project Tango was closed by Google. And it’s no wonder that this Microsoft navigation project apparently hasn’t been updated for a year now. After all, AR and indoor navigation are tough subjects to tackle.
So, it’s refreshing to hear that Microsoft might be rethinking some of its past approaches. After having experimented with their earlier iterations of Windows IoT, I found it an interesting foray for Microsoft. However, I didn’t really believe that it’d be adopted by manufacturers and (especially) developers. It seems that Microsoft has had the same realization recently, and it’s now pursuing a new project to revamp their IoT (and mobile, to some degree) portfolio called Azure Sphere. Now, this initiative could maybe breathe new life into some of that confused tech. If somebody out there creates a kit for Azure Sphere, I’m a taker. I’m looking at you, Adafruit!
A few weeks ago, Microsoft VP Scott Guthrie stopped in NYC as part of his promotional tour for Azure’s cloud services. Normally, I don’t really care for these long informercials, but I decided to go in this case for two reasons. One, it took place in Cooper Union’s Great Hall, which was something historic I had always wanted to check out. Two, even though I’ve played with Azure’s offerings on occasion, I was curious what Guthrie would highlight in his presentation, especially after friends and colleagues had talked up Azure in the last couple of years. So, I went, and I was surprisingly glad that I did.
A few years ago, when I learned of some of Microsoft’s ambitions in the cloud space, I bought some MSFT shares and thought that they might catch up with Amazon in the cloud space. Impatiently, after a year, I began to have my doubts, and I sold off the shares. If you look at its latest price, that was clearly a mistake. I should have held onto them, and while listening to Guthrie’s presentation, it became painfully obvious as to why. Of course, he talked about the inherent power of Azure, with its various data centers around the world. (Which were all shown in a dramatic video seemingly directed by Michael Bay, with an intensely dramatic score blaring in the background.) However, it was the maturity of the platform, with its various tools and considerations for the user that was impressive.
Even though I’ve only dabbled with cloud platforms, I especially appreciate their raw power and penchant for structure. Even when you create apps that are meant to be deployed for the cloud, it heavily reinforces structure in their templates for developers. For example, if you build a web app within Visual Studio destined for Azure, it refers to queues in the project template by default (which are automatically available in Azure). You might question its need to reinforce such a feature through templates, thinking that the usage of queues in a web app as obvious. “What vital web service that receives a POST wouldn’t automatically queue that request, since the resources to fulfill the request might be temporary unavailable? Who wouldn’t do that?” Oh, you’d be surprised. Let’s just say that such bug-ridden deployments are not unheard of.
First, Guthrie talked about the typical use cases of cloud offerings, like creating and deploying a serverless app with ease or creating a container and deploying it with Kubernetes. Even when he talked about deploying apps to specific data centers, those features were interesting but expected. (I still have mixed feelings about the Azure Portal dashboard, but since that’s an argument about interfaces, that’s an entirely different subject.)
However, I was more impressed when he started talking about the other free tools offered by the platform that were supplemental. For one, its inherent monitoring system was akin to Splunk, and it could be used to monitor and query your entire setup (apps, databases, hosted servers, etc.), and you could customize your system instances with networking rules (like lock port 54545 every morning). Next, the number of devops options seemed more diverse than I remembered (with build options including Maven). There was even a tool which would suggest how you could reduce your expenses, like by consolidating servers and minimizing resources (storage, # of dedicated CPUs, etc.). After watching some examples of machine learning and image recognition, my only regret was that I had no reason to use them in my own projects.
After several years of concentrated effort, they had created an impressive, mature cloud platform that definitely could give Amazon a run for its money. I only had two points of contention. One, this promotional tour was somewhat eponymously named The Red Shirt Tour, since I was told by staff that Guthrie has a certain love for them. Aside from a terrible name for the tour, I would say ditch the symbolic shirt, since that will forever more belong to Jobs. Pick a hat, and in order to reinforce Azure, go for a blue beret instead.
Two, they served Subway for lunch. To which the answer is always no.
Yes, it was free. However, just like if you were offered torture for free, you shouldn’t accept it.
Aside from that, though, I walked away impressed. Nicely done, Guthrie and MS!
Well, I’ll give it to Microsoft: maybe they have an angle with IoT and enterprise. (Not to mention a rather creepy one.) In the end, though, only time will tell.