Cloud thinking : storage as data structures

We’ve all experienced the performance implications of saving files. We use buffers, and we use them asynchronously.

Azure storage has Blobs. They look like files, and they fail like files if you write a line at a time rather than buffering. But they’re not files, they’re data structures, and you need to understand them as you need to understand O(N) when looking at Arrays and Linked Lists. Are you optimising for inserts, appends or reads, or cost?

I know it’s tempting to ignore the performance and just blame “the network” but you own your dependencies and you can do better. Understand your tools, and embrace data structures as persistent storage. After all, in the new serverless world, that’s all you’ve got.

---

Understanding Block Blobs, Append Blobs, and Page Blobs | Microsoft Docs

 

Advertisement

My .net journey

With the release of Visual Studio 2017 and .net core, I’ve seen a few folk talking about their story with the platform. This is mine.

I’ve never been the biggest Microsoft fan, ever since I grabbed a copy of Mandrake Linux and figured out how much more tinkering was available and how much more logical certain operations were than on Windows 95. But it was definitely still a tinkerers platform.

But I got an internship at Edinburgh University whilst I was a student there, funded by Microsoft. I got a laptop for the summer and a iPaq (remember that?) to keep. I also got a trip to Amsterdam to meet the other interns and some folk from Microsoft, back before they had much more than sales people in the UK. And they told me, no matter how much anyone hates Microsoft, they always hate Oracle more.

It meant that I was among the first to get the .net 1.0 CD, so I could legitimately claim later that yes, I did have 2 years of .net experience.

But from there, I stayed in Linux, learning the joys of Java Threading on Solaris (top tip : Sun really should have known what they were doing, that they didn’t means I can see some of why they failed – it was far easier working with threads on Red Hat or Windows).

And then I did my PhD, digging into device drivers, DirectX and MFC. I hated Microsoft’s Win32 GUI stuff, but the rest, in C++, was quite nice. I enjoyed being closer to the metal, and shedding the Java ceremony. I trained on templates and started to understand their power. And Java just wasn’t good enough.

I wrote research projects in C++ and data analysis engines in Python. It was good.

But Java came back, and I wrote some media playback for MacOS, and fought iTunes to listen to music. And I vowed never to buy from Apple because both were a right pain.

And I needed a new job. And I’d written bots in IronPython against C#, so I got a .Net job. And I missed the Java and Python communities, the open source chatter. And I wanted to write code in C# that was as beautiful and testable as C++. And I wanted to feel that Bulmer’s Developers! chant was a rallying call, not a lunch order from a corporate monster.

So I found alt.net and it was in Scotland, and I wrote a lot of code, and I learned that open source did exist in c#, and that there was a conference named after that chant and I met more like minded developers. I fought my nervousness and my stumbling voice and I found some confidence to present. And blog. And help write a package manager. And then everyone else learned Ruby.

And then the Scotts joined Microsoft and alt.net became .net. And then LINQ came and I remembered how clean functional programming is, and I started feeling like I was writing Python if I squinted hard, and ignored types. And then core came, and Microsoft had some growing pains. But it’s a sign that the company has completely shifted in the right direction, learning from the guys who left for Ruby. And Node.

I’m proud of what I’ve built in C#, and it’s a much better language than Java, now. It’s definitely the right choice for what I’ve built. The documentation is definitely better than Apple or Sun/Oracle produce, although MSDN and docs.microsoft.com are having some migration pains of its own.

And alt.net is making a comeback.

And I still use Python on hobby projects.

Microsoft Edge, ungooglability and a new class of bugs

Microsoft definitely has a naming problem. .net core was one thing, but calling a browser Edge was just trolling developers. Try searching for “Edge CSS” or “JavaScript Edge”. It’s a lesson in frustration, which means the bugs in the new browser are extra painful to debug because it’s that much harder to find the blog posts and Q&A for the last person to fix the problem.

And Edge doesn’t behave like IE, or Firefox, or Chrome. I’m sure Microsoft, like the other vendors, are updating OSS frameworks to help them target Edge, but there’s still a lot of Javascript and CSS that breaks silently, so no Console logs to help, no odd numbers in the calculated CSS, and no hacks to persuade Edge that it can render just like the big browsers.

I want to like the browser, I really do. Anything that brings the end of IE closer has to be welcomed, but even after the Anniversary update of Windows 10, it’s far from ready. If I try to open IIS failure logs in Windows 10, it opens up IE, and displays with the correct CSS, and then tells me I should use Edge, where the CSS is broken. It’s frustrating as a user, and as a developer. It’s an alpha product, and it should have been treated as such. Give it to devs, allow power users to opt in, and iterate it. Microsoft still needs to learn what it means to develop in the open.

Documentation

Unfortunately the problem is then compounded by Microsoft’s documentation problem. For all the faults of IE, at least Microsoft had a good reputation for documentation at the height of MSDN. Unfortunately, MSDN is starting to decay, and there’s a number of conflicting alternatives springing up. For us developers, the seemingly preferred route for latest information is blog posts (or the comments thereon – which were the only source of information for a knotty Docker problem we had), but there’s also GitHub, docs.microsoft.com and the occasional update to the existing MSDN documentation suite.

Microsoft seem to be trying to frustrate developers. Especially when they have evolving, and conflicting APIs (I’m looking at you Azure, and the Python vs PowerShell vs Node APIs, and the Portal experience). The documentation experience at Microsoft feels like the Google UI experience before Material Design. And it needs a similar overhaul.

I love seeing Microsoft trying to be more open and I see it working, to a certain extent, in the C# and .Net space, aside from the .Net Core RC release cycle chaos. They’ve come a long way from the days of alt.Net (although I agree that we need to recapture that passion, both for the sake of new developers, and for the sake of keeping Microsoft in check), but they’re in danger of alienating developers once more with the confusion, and the inconsistencies within certain platforms.

In that context, removing project.json and keeping .csproj was the right decision. One clear and consistent path. Now go and apply it across the board.

Windows resource limit in services

Here’s a little something that stumped us for a few days and might be worth posting to save others time.

Following a move to IIS8.5, we started seeing “Out of resource” errors on a server that did not appear to be bottlenecked by disk, CPU or RAM.

It turns out that since a previous version of IIS, the Application Pool service doesn’t grab GDI handles as it runs as a non-interactive service, so anything relying on that, such as a DLL with GDI dependencies, like an image resizing library, only gets the non-interactive desktop heap for graphical services. As soon as you get enough calls into that DLL, the heap fills and the program crashes with the “Out of resources” error.

So you recreate the issue in the debugger, attached to IIS Express, running in user space, with the full interactive desktop heap, and you can’t recreate the issue.

To fix the problem, you need to carefully adjust the heap limit in one of the ugliest registry values in Windows. Have a read here to find out what the Desktop Heap is and the registry key that controls it, then up the 3rd SharedSection value (the non-interactive heap) in small increments (lest you put in a value too high, break the interactive heap and lose the ability to log on).

And then find a way to rewrite the DLL.

Cloud thinking : efficiency as a requirement

In the old world, you bought as big a machine as you could afford, and threw some code at it. If it could fit in memory and the disk I/O wasn’t a bottleneck, everything was golden.

In the cloud, however, CPU cycles and disk storage cost real money. Optimisation is key, so long as it’s not premature. Monitor it.

In cloud thinking, it’s less about the O(N), it’s relatively easy to scale to the input, as long as you’re not exponential. In the cloud, it’s about O($) – how well does your code scale to the amount of money you throw at your servers (or inversely, what’s the code increase per user).

Fixed costs are vanishingly small in the cloud, but incremental costs can change quickly, depending on your base platform. Not the provider, as costs between them are racing to the bottom, but the platform of your architecture.

Quite simply, the more control you ask for, the more you pay in time, and the bigger the ramp-up steps. Get metal, and you’ll pay for everything you don’t use, get a VM and you can scale quicker to match demand, get a container, get an Electric Beanstalk or an Azure website and give up the OS, get a Lambda or a Function.

I can’t recommend to you how much you should abstract. I don’t know how big your ops team are, or how much computation you need to do for each user. I suspect you might not know either. Stop optimising for things you don’t care about. Optimise for user experience and optimise for cost per user, and measure everything.

Naming things is hard – Microsoft’s Core problem

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

• https://twitter.com/secretGeek/status/7269997868

Microsoft are changing the name of the next iteration of .Net – what was .Net 5.0 is now .Net Core 1.0, and like Rick Strahl, I like the idea, but I’m not find of the timing. Although, as it’s pre-release, anyone writing production code on it was playing with fire anyway. I’m not a big fan of the naming scheme though.

The timing issue is an easy one to solve. I’ve had projects running under placeholder codewords for months whilst the business agreed a proper name. Microsoft has been doing this for years. No-one expected to see Windows Chicago, Windows Threshold or SQL Server Denali. No-one would have expected to ship .Net Sapphire (hey, they’ve admitted that were going after the Ruby developers 😉 ) Everyone knew they were codewords, to be replaced pre-release once marketing figured out what year it was being released – or the regression testers discovered how much old code thought 9 < 7.

The problem I have with it is that ASP.Net Core sounds like part of the family that includes ASP.Net MVC, ASP.Net SignalR or ASP.Net AJAX, whereas it actually replaces the ASP.Net part with its own .Net Core stack. I can’t at the moment think of a better way to name the ASP.Net Core though, without losing the ASP.Net brand.

The naming works when you compare .Net Framework to .Net Core, and to me it’s as natural as when Netscape open sourced Navigator to give us Firefox (once they managed to choose a unique name). It was from some of the same team, and it did the same job, but the new one was leaner, faster and more focused.

Naming things is hard, but starting a new roadmap and resetting expectations is definitely the right thing to do. .Net and the ASP.Net frameworks have needed a decent overhaul for a while to fix the untestable, interdependent ball of mud that the .Net framework install had become. I like the new Core world, with NuGet and Gulp and Grunt, and Github at the heart of development. This is not a Microsoft I thought I’d see when I was at the ScotAlt.Net meetings all those years ago.

Alt.Net is dead. Long live .Net Core.

Innovation vs Quicksand

Anyone following me on Google+, Facebook or Twitter may have seen me posting quite a lot about the many Intellectual Property cases currently strangling the mobile computing market. A lot of them involve Apple, but it’s not an attack on them. They just happen to be in the dominant mobile position now that Microsoft was in 10 years ago on the desktop, and so they’ve got the most to lose.

Last decade, the stories were of Microsoft using Windows to cripple competing office suites and promote its own, and the big move to unify the desktop, server and mobile Windows experience with XP and .net, and giving us IE6 and anti-trust cases. Now, we have Apple unifying desktop and mobile, and pushing others away with policies on in-app purchases and legal battles blocking competition in the marketplace.

I like competition. Competition makes phones faster, batteries last longer, and keeps everyone on their toes. Without it, innovation stagnates.

I am not a lawyer, so I don’t understand why a sketch that looks like a sat nav can be used by Apple to stop tablets from competitors being sold. It’s not like the Chinese rip-off that fooled even the employees at the fake Apple stores.

There is something rotten in the world of technology. It’s about patents, copyright and other protection, but whereas it works for Dyson, to protect his cyclone, whilst allowing competition from other bagless systems, the same protections are smothering the computing and smartphone market, distracting all companies into defending themselves against others, instead of differentiation through innovation. I don’t to work in an industry that’s moving through quicksand, dragging platforms, tools and devices back. We’re already held back enough trying to build for incompatible browsers without having to rewrite for new platforms just because the ui of one has protected interactions (think touch screen versions of Amazon’s pervasive One-Click patent). Higher costs for developers, higher costs and frustration for end users and the vendors fighting amongst themselves won’t benefit, ripping chunks out of each other and alienating the rest of us.

Samson needs to come and cut some crown jewels in half.