IaaS is Not a Real Cloud

In my not-so-humble opinion, putting your client-server app on an AWS or Azure VM is no more "Cloud" solution than running DynamoDB and telling people you've got "Big Data".

To me, real Cloud and real Big Data start with using scalable PaaS OS, like Azure or AWS. If you got no PaaS, don't talk cloud and big data.

Learning Azure on Your Own Dime - Extremely Expensive

OK, I am completely sold on The Cloud, and specifically on PaaS. I am ready to go use it, especially Azure since I like Microsoft stack and tools, despite AWS being more popular and having more features (we, artisans ;-) develop stronger connection with our tools and techniques, than craftsmen or business people.) I started learning Azure, got the account, a VM, Azure SDK, developed an interesting testing-the-waters project - the Azure Storage Queue multicaster, similar to ESB topics.

My first Azure bill, despite MSDN subscription was above $150. I run a 24/7 application server on a slow VM there, where majority of the cost comes from, but small experiments, like with the VPN for example, added $25 before I noticed that it's really expensive. That was unpleasant.

Now, I want to experiment with something other than what I can run on local Azure simulator (Tables, Blobs and Queues). I would like to play with ESB, API Management, DocumentDB and just about everything else, but I am really concerned about how much cost I am going to incur by using each part of the stack, especially if I forget to power everything down on Azure for a night. The point is, my impression is that simple poking around and learning Azure stuff is rife with unpleasant and costly surprises. All these risks and impediments combine into a single big turn off for a potential Azure developer.

With Azure lagging in adoption behind AWS, slapping down even dedicated fans like myself, means that Microsoft is very unlikely to ever catch up with AWS. "Developers! Developers! Developers!" indeed. I know it is possible to plan the cost ahead using complex Excel spreadsheet, and there is an almost-meaningless 30-day free trial (learn new enterprise OS in 30 days, really??), but all these impediments add up to one huge fogget-bout-it!

Here's what Microsoft could do to make it easy for me to learn Azure: create closed-off sand-box on Azure infrastructure, inaccessible from the outside, but make all Azure stack technologies and components available there for free to all MSDN subscribers. Let us play with and learn Azure for free, and charge us only when our wares is made available public. That would be a huge differentiator for Azure.

If you agree with the statement above, talk at Microsoft about this.

But while Microsoft is ignoring us, I decided to do my part, in the upcoming weeks and months will do public service so to speak, and will pay out of my pocket for learning Azure, and will blog about my experience, including costs. I will tag those posts with "azure" and "paas". Follow this blog to take pleasure in my future misfortunes on the path of conquering Azure.

A Little Help?

If you are planning to shop on Amazon, please use this Amazon link to get there - it will help me with, um.. being inspirated™ to maintaining this blog.

Thanks!

But how long will it REALLY take?

Most  programmers, myself included, are notoriously bad at estimating how long it will take to finish the job. So after much research I am ready to finally make the estimates very precise and scientific: whatever number programmer gives you, use The Vlad Law and multiply the estimate by PI. Not by 3 - that would be just a worthless guess. No, multiply it by 3.1415 - that's the objective truth, I tell ya!

What Is Good Software Architecture?

Ask any software architect a question what makes good design, and you will get a good number of very valid criteria. The one I don't hear mentioned, and one that is critical for me when I design software, is how quickly a mid-level engineer can start and keep following processes, templates and practices I create as part of the design. If design is so sophisticated that it requires superstar engineers to deal with that, that's not a good design no matter how advanced are concepts and frameworks built into the design. It's already too expensive.

Everyone, To The Cloud!

A few years ago I joined a company that was in the process of selecting new ERP system. Vendors were usual suspects: consultants peddling SAP, Microsoft, Oracle and some other ERPs. I got to quiz vendors regarding different features and capabilities of the systems they were selling. I wanted to find how how costly integration with my company other enterprise systems would be, and asked every vendor whether their system exposed their functionality as web services. All of them did, of course. Then I asked them what I considered a very logical and simple next question. I told them, since we are going to orchestrate data updates across multiple disparate systems, I needed to know whether their web services supported transaction, like WS-Trasaction from the WS-* stack? I got blank stares and promises to find that out. I asked whether they were ever asked about this before by other enterprise architects, and to my huge surprise all of them said no. I asked how many ERP implementations they had under their belts, and all of them had dozens. Later all vendors got back to me with an astonishing information: none of their systems' web services supported transactions. That meant that garbage data were bound to accumulate over time and nobody even thought that was a problem.

That struck me as very odd and made me think: in my day-to-day life even mid-level developers usually have decent grasp of what transactions are for and often don't need supervision in applying them, as long as we are talking about SQL programming or writing data access layer of business applications. But as soon as people leave database world, somehow even professional enterprise software integrators become completely unconcerned about transactions. That matched my experience of virtually every enterprise system I ever encountered having lots of garbage data in it, requiring lots of effort/money to cleanse data. But the conclusion was inescapable: by and large, as a practical matter, corporations are pretty comfortable with not having transactions guarding integrity of their data. As a matter of fact, companies don't care about their data consistency.

Now, my thinking went like this: if people voluntarily give up transactions without getting anything in return, what can be gained if transactions are avoided not by neglect, but instead, by design? Well, if we believe CAP theorem, letting go of data consistency should let us gain high availability and partition tolerance, which translates into high scalability. And, ladies and gentlemen, that's what "big data" management systems offer: high scalability and high availability if you can deal with eventual consistency of data. And since lots of companies are not even trying to achieve data consistency, switching to NoSQL-based "big data" platforms becomes a no-brainer.

Now, NoSQL and "big data" have becomes such an incredibly abused buzzwords, that I need to stop for a moment and state that, for example, MongoDB, in my opinion, although a very fast NoSQL data management system, is not necessarily a *bit data* system, because it was not designed to be one - it was built for speed and sacrificed parts of CAP to achieve high performance. Then let's look at Hadoop. No question that's a big data management system. But the main problem is that it's not for on-line data processing - it's strictly batch processing using map/reduce approach. And if you want to set up Hadoop cluster, it's a pretty expensive proposition.

All that said, I  argue that first truly useful general-purpose big data on-line processing data management system was Amazon AWS DynamoDB. It has eventual consistency, no transactions, limited returned data set size, and other limitations, but it scales in a nearly linear manner. Then Microsoft came up with Azure Tables and now Document Database. Even though you may say that eventual consistency in not really what data online processing is, I say these systems latency is tolerable enough that these systems could be considered pseudo-online.

Now lets review the landscape again: transactions are abandoned, non-transactional highly-scalable data management systems are available as a part of PaaS stacks from Amazon and Microsoft, so... there is pretty much no reason to have your data processing strategy depend completely on ACID databases. Moreover, if we, developers, train ourselves to deal with more complex DAL tiers underpinned by Azure and AWS eventually-consistent big data engines, there is no real reason to use ACID databases as a default position, which is equal to "everyone, to the cloud!"

The IoC Framework Folly

I've been around long enough to live through several Things That Will Save Us All.

First was the OLE. Look it up, kids. It was cumbersome and not well adopted, but we still have remnants of it in OleDB data access drivers.

Than there was the XML. It was for some reason to be used everywhere. I was thinking: OK, just another way to serialize data.. Why is it presented as revolutionary and adopted without much reflection? Recently Json was adopted with about as much fervor.

And today - I think it's fair to say the verdict is in - the Thing That Will Save Us All is DI/IoC frameworks. By now I saw a few projects making heavy use of IoC frameworks and all projects using them have the same basic setup: everything is an interface regardless of how many implementations are planned for the interface, and completely irrespective of whether the interface was ever planned to define a service (for both the provider and a client). Everything gets injected even if the instantiated real dependency dependency graph has no externalities like a database or a remote production system. In addition to that, polimorphism is murdered and inheritance is done via composition of the base interface. And so on and so forth.

And for what end? Testability, of course. Ok. I am very pro-testability. But, testability is only *one* of meany avenues of achieving high quality of code. Testability demands that more dependencies are exposed, to make code more unit-testable (mockable). But this is not a pure asset - it's a trade-off. It comes with a cost. More dependencies exposed means lower level of abstraction of the component or the API. APIs are lairs, say TDD extrimists, because API hide dependencies, which makes them not terribly well-testable. Fair enough. But that's exactly the point: APIs should hide as many dependencies as practical. Not hide all of them, which would lead to the very low testability, and not exposing all of them, making the API hairy and busy. For example Entity Framework hid too many dependencies until v.6, making it impossible to inject a custom connection string factory. That's where more exposed dependencies would be better. But then look at WCF, which, for all intents an purposes, is a specialized IoC framework, with tons of different interfaces, and where everything is pluggable (injected) and dependency declaration shifted to the .config file. As far as I can tell, most developers hate WCF because of its complexity. That is a fair criticism. But when I come across an engineer who loves IoC but hates WCF, I turn into Louis Black inside: an engineer should be able to understand that WCF and IoC frameworks have very similar architecture and share trade-offs.

Finally, if you ask me what I think about IoC, you better be able to clarify: the pattern or a framework. And don't say "both", please. Because IoC the pattern was popular ever since Windows Programmer's Guide told us to handle WM_xxxx events to write any Windows program, and before that a virtual function was introduced to masses by Bjarn Stroustrup, and before that the function pointer was gifted to the world by K&R, etc. And IoC frameworks have unfortunately become The Way We Do Things Today: often used mindlessly as a proof of engineering sophistication to the same extent Apple gear came to signify creativity. There is only one universally-valuable design principle: no pattern is universal.

A Single-Question Software Engineer Interview

After 24 years being at it and spending countless hours interviewing dozens of software engineers, I relatively recently realized that I can predict with a surprisingly high precision whether a candidate is a good programmer by getting an answer to a single question:

How long ago did you create your most recent virtual function that was not prescribed by a base class?

If the answer is a blank stare, confusion, or more than a month ago, then the engineer is very likely not above average. If not more than 2-3 weeks ago, then the programmer is pretty likely a good one.

Here is why I think this is a valid test.

These days most devs are quite well prepared for the interviews and can competently rattle off main OOP principals and names and even usages of the most common design patterns. What I observed, however, is that this knowledge is more often than not does not really translate into practice - i.e. into the the ability of spotting a pattern or a potential extensibility point, which most commonly is expressed in a virtual function.

Truly good programmers are always on the lookout for the extensibility points of their components: such engineers are fluent in using virtual functions, events, callbacks, asynchronicity and other ways of inversion of control (a term I now use with trepidation after it has been thoroughly misappropriated by the DI/IoC frameworks, which have become the Today's Way of Doing Things, like the XML was 10 years ago). Average programmers can implement an interface, but can hardly recognize the place, or see the point of creating a virtual function. Average one doe not work with the polymorphism in mind.

Doing The Right Thing For Wrong Reasons

There are very few things I would do rather than programming. I discovered that back in 1987 and it is still as true now as it was then. I love the creative part of it for sure, but what I love the most are two factors: the objectivity of the result - it can be measured, analyzed and proven better or worse than an alternative; and (gasp) the aesthetics of the programming language and runtime design.

First is simple: I really need to be able to tell whether any given way of achieving a goal is the most optimal and efficient. The notion of different styles of programming as equally-valid means of achieving a given goal troubles me, because given the set of qualities: scalability, availability, maintainability, complexity, time to market, etc. - all collectively known as total cost of ownership (TCO) - your way of getting there and mine are guaranteed not only to be different in style, but also to have different TCO. See, I am suspicious of both natural self-promoters and nurtured entitled types (your output is precious before you've done anything), which is why wherever I see different approaches, I want to get an objective measure of the value of each approach, and programming is one of the few activities that allow for ways to tell a BS from a well-done piece.

The second - the aesthetics angle, is defined by how easily I can feed my obsession with finding the best way of doing things. I care a lot of how I get where I am heading. This manifests itself in my learning slower but deeper, achieving higher clarity of understanding, and improving my ability to articulate the net value (assets minus liabilities) of a given technology, approach, pattern, etc. If I sense that there is a better way of doing things, I want to find it now. If I find that I wrote code that is not most efficient (not just in performance, but also clarity, expressiveness, maintainability, extensibility, and so on), I feel embarrassed and cheated.

This leads to some of my idiosyncrasies in how I work. I loath going back to less efficient ways of doing things. For example, after I discovered C++ in 1991, I could never imagine going back to plain C, which I loved very much until then, ever since I found that C could be as much fun as Assembler with much higher productivity. When I saw JavaScript for the first time back around 1996, I gave it no more than one year before it would be replaced with something real. Boy, was I wrong about the staying power of a monopoly-holding programming language of the slowest-ever-evolving OS: a web browser. Same with how I now dread going back to TFS or SVN after experiencing Git, which I kind of didn't want to learn because in 2011 I felt TFS was pretty great.

At around 2001 I fell in love with C#/.NET 4.5. These days, with its LINQ and pseudo-functional veneer, async/await, extension method, IEnumerable + yield and deferred execution, beautifully-implemented Generics, phenomenal performance - C# and .NET stack are my absolute favorite, which, from a practical manager perspective can be both an asset, as I know them really well (I know what "volatile" is for and how .NET 4.5 has finally implemented claims-based access rights security management), and a liability. A liability here is that being the connoisseur of the Microsoft stack, I lack the "do what it takes" attitude so often valued in the corporate world. It all means that my work is more artisan than industrial. I think I'd rather build a beautiful thing than change the world. Sometimes I get lucky, and get respectable if not world-shattering number of installations of my pet products - 1.1 million as of now. Sounds pretty good, right? But it took me 1.5 years of nights and weekends work to get there. Sounds kind of expensive doesn't it? But the quality is such that my products average only 1 support request per 2-3 weeks. Not bad again, I think, for a product that gets installed a few hundred times a day on every possible configuration of PCs ranging from Windows XP to 8.1. So you see, since I'd rather learn from Schubert or Picasso than Zuckerberg or Jobs, I am probably good for your team only if its values are such that it has more foodies than coke & pizza eaters.

I imagine observing me working could give a strange impression: a very quick delivery of large and complex, high-quality components (60% of this was written in 7 days), offset by somewhat deliberate pace of learning, caused by the obsessive need to learn in-depth and understand motivations of people who created the subject of my study.

So there it is: I exist just outside of the "change the world while making the bundle" cliche philosophy and values of the Silicon Valley (the place, the TV series is laright). But if you run besides me while I take on my next obsession (today it's The Cloud/PaaS) you are very unlikely to be ahead of me in 3 years from now, even if you got 3 years head start.