(My) Early Beginnings
I started my career in software development as a very junior web developer in 1999. I taught myself HTML, VBScript and JavaScript. The browser wars between Microsoft and Netscape were raging. I still remember how exciting my first Classic ASP page was. The fact that I was able to connect to an Access or SQL Server 7 database with just a few lines of code inside my markup was incredible at the time. I consumed new recipes from “4 Guys from Rolla” with relish and kept Scott Mitchell’s titles like “Teach Yourself Classic ASP 3.0 in 21 Days” on my desk at all times (it’s still on my bookshelf which itself has become a sort of Smithsonian for software development over the last decade). Even more exciting was that fact that it seemed like the beginning of a new era in which I could relegate JavaScript as a necessary evil for handling tricks like focus and validation on the UI.
At the time, I was doing some really fun and interesting work as a young Padawan for the credit card division inside the #1 Visa issuer in the country (we didn’t have a fancy name for it other than “reports” back then but we were doing very early work on what would become “BI”). By rendering data-driven operational reports dynamically on the browser, we had revolutionized how metrics like Occupancy, Average Handle Time, and Multiple-Call-Rate were disseminated within the bank ushering in a new era of productivity, transparency and accountability for everyone from agent to VP. Through this experience, we built a center of excellence which served as a benchmark for other call centers to follow (in fact, we had the likes of Amex come in and review how we did it). Sure, we had displaced an army of Excel Macro and Access developers, but such was the price of progress. As this little rogue IT shop basking in our success, I remember a number of “true programmer” personas in the “Real IT” group that tended to undermine what was happening. These were programmers who came from C++ or Java (and whose managers felt threatened by what we were able to do with such few resources) and mostly thumbed their nose at things like lack of strong typing, OO, etc. They looked at JavaScript as just a tool for dirty hippie web masters (remember that term) and VBScript as as something OK for administrators to use to walk AD hives, but being inferior for lacking OO and being handicapped by things like variants. Despite our incredibly visible success (at the CEO level and above) by applying these scripting technologies, I was hungry to see the forest for the trees and experimented a bit with COM and COM+, learning how to encapsulate business logic in components and delighting in being able to wire up my COM libraries with Classic ASP even though with the exception of my manager and mentor at the time, no one else even had the tools to debug my components.
The Server Era
Then, this thing called Windows DNA came along which promised to marry Windows, ActiveX and Internet into one big cluster… well you know. Fortunately, it’s fate was short-lived, but I remember attending a couple MSDN events where it seemed like concurrency and single threaded apartments would become mainstream topics on the web. Maybe us script kiddies would earn some respect after all? Then, just like that, this new, new thing called .NET happened. All of a sudden, just like that, I had a ton to learn. All my Classic ASP and JavaScript skills were superseded by Web Forms. I still remember stepping through every line of code in the I Buy Spy reference app and being completely blow away. ASP.NET offered something that was OO, strongly typed, and would even render JavaScript for you. Cumbersome JavaScript validation was replaced by server-side templates and controls. Form fields magically remembered their values across post backs. And, as I learned, WebForms offered a better separation of concerns with a nice, clean code-behind model that I would later leverage to introduce patterns like MVP, MVC Page Controller and Front Controller. I built a nice CMS portal for a multi-national bank (which according to Forbes Magazine is the largest public trading company in the world today) with these new skills and I hear it is still running today. Life was good. This was the age of the web server, and the only major argument within the Microsoft web community at that time was “C# or VB.NET”?
At this point in my career, I’d grown a bit bored with web development. I felt like I’d accomplished everything I wanted to with ASP.NET, and the roles I found myself in started dealing with problems at a more holistic, program level which would involve a handful of web apps and coordination between them and new and existing enterprise resources. I discovered Web Services, and the problems I was now trying to solve led to the gradual gravitation to enterprise architecture and middleware and before I knew it, I was hooked. Admittedly, it was a great time to make the shift. SOA was king. COM+ had grown up with support for Enterprise Services in .NET and in parallel, this amazing new messaging framework codenamed “Indigo” was in development that would provide a black belt for hungry ninjas like me who wanted to take over the world with SOA. When it came to Indigo, there were two types of members in the community: Those on this inside, and the rest of the world. I was very much part of the rest of the world, but I consumed every bit of content I could get my hands on from folks like Don Box, Juval Lowy, Wenlong Dong, Michele Bustamante and Dr. Nick.
Around the same time, a major re-engineering of a product called BizTalk Server was nearing release which took full advantage of the .NET Framework. My employer then, a mid-sized auto retail and finance company was one of the first BizTalk Server 2004 customers in Phoenix. For a fledging enterprise integration architect, this was an awesome opportunity. I learned a ton from my friend Todd Sussman, Brian Loesgen and Adam Smith, the latter of the two I wouldn’t meet in person for a few years, but I had read “BizTalk Server 2004 Unleashed” and “The Blogger’s Guide to BizTalk” from cover to cover more than once. Even better was that I was leading the development of our first SOA and 802.11 enterprise mobility project. We had decided to build the mobile apps- which were a superset of a desktop control center- with ASP.NET. Users would hit the same URL whether they were on the desktop or in the field with their device, and the right screen would render. All of our business logic was wrapped in an ASMX façade which then communicated with our BizTalk orchestrations. With my first real enterprise program under my belt, and WCF nearing GA, I decided that this was what I wanted to do when I grew up, or at least for the next 5 years.
Along with WCF, WPF was nearing release. WPF offered a completely different paradigm on which to build traditional Windows apps. Support for rich media like video and sound, flat controls, new gradients all with an incredibly “webby” DHTML-looking design aesthetic. At the time, I remember introspecting that if presentation technologies like this were successful at winning over users, then one day, users won’t care if they are using a browser or an OS to interact with software. What I didn’t realize was to what extent everyone’s cheese was about to be moved. Here we had two tremendously powerful additions to the .NET Framework, poised to revolutionize how we write software from a presentation and back-end perspective, and yet, something subtle was happening that was bigger than Microsoft, bigger than the marvel that is .NET.
The Web Reborn
Content building SOA solutions in the walled gardens of my employers and clients, almost overnight, I remember when web developers started insisting on me starting to expose JSON endpoints on my services. Apparently, while I was in messaging la la land, users had grown tired of refreshing their browsers and posting back to the server every time they submitted a form. Turns out, I too was one of them! Users were demanding not just a dynamic web experience, but one that was interactive, and felt more like a rich client (a great example at this time was Outlook Web Access). But if you wanted a rich experience, isn’t that why you stuck to the desktop and used WPF? Following the promulgation of XML as the second coming, wasn’t JSON nothing more than an esoteric relic of JavaScript? AJAX had arrived. What followed was a complete disruption of the seeming balance between intended purpose that would shift the pendulum once again to the web.
This was about the same time that Microsoft had shared its vision for Software + Services, first unveiled at Mix 07. On the outside, the Mix conference was all about the web, but the reality was that this was also part of a pretty massive campaign to court and win over designers from Adobe/Macromedia to a new technology: WPF/Everywhere, aka Silverlight. While many had been signaling WPF as the return of the smart client, users were accepting an alternate, even degraded user experience in exchange for interop. Silverlight offered a superset of WPF capabilities, delivering a somewhat equally productive design time and development experience as .NET and thus began penetrating Apple and Linux via the ubiquity of the browser. This was the first time I saw Microsoft really understanding that it wasn’t only about .NET and Windows anymore. This was evidenced by prominent PMs on stage demonstrating Silverlight apps on Macs, and running Linux distros on VMs to show that you could write the app once, and run it (almost) everywhere. A number of incredible apps were released on Silverlight including examples like Netflix and Hard Rock Café Memorabilia which were each both a sign of the times and a hint at what was to come.
To be sure, this had indeed become a software + services world, and for a while Silverlight looked promising despite the tremendous market footprint that Flash had and continues to have. I remember writing about how remarkable Silverlight was and what a game changer it could be. But then, an interesting thing happened. JavaScript and REST started appearing more and more in web apps, particularly in the consumer space. At first, despite the popularity of Fielding’s paper, REST seemed like a fringe thing, and in many ways a step backward. Here we had a tremendously powerful consortium of standards built around SOAP representing the intersection of the very few things big players like Microsoft, IBM, Sun and Oracle agreed on. What’s more, it seemed that Microsoft had timed this SOAP bubble (no pun intended) perfectly, with its shiny, new, equally efficacious messaging stack called WCF which was, and still today remains unrivaled by other platform vendors. In addition to HTTP, WCF brought TCP, MSMQ and IPC to the enterprise, offering (proprietary) binary encoding and MTOM for optimizing message exchanges. The programming model had (and continues to have) a learning curve over ASMX, but once you got over the hump, you were on a high summit and could see the world for miles around from this new vantage point. So, why in the world would anyone want to go back to using HTTP POST and POX? How could it be that the world was settling for REST and JavaScript?
Simple. The world (and the internet) was changing. A gradual, yet viral shift was taking place fueled by the success of Ruby on Rails and PHP which built the foundation for what is today known as Web 2.0. All of a sudden, anyone with a laptop and an internet connection could download a few packages and get an app up and running in no time. The barrier to entry was financially negligible and because these languages fully embraced HTTP, a tremendous community was born that was as smart as they were entrepreneurial. Interop and reuse were mere side-effects that led to tremendous adoption by everyone with a browser. Fully embracing JavaScript with their productivity boosting libraries that took the sting out of writing JavaScript, similar approaches to packaging robust functionality into libraries such as JQuery followed. In addition, while at first, Ruby on Rails embraced SOAP, it was later replaced with REST. Ask your mother or grandmother what Twitter or Groupon is and you’ll have the answer as to why REST and JavaScript have persevered.
In response to all of this, WCF added support for JSON first, followed by REST, and by the release of .NET 4, both were in the box. In addition, WCF RIA Services was introduced, adding an easy button for integrating with Silverlight clients with the stack, and WCF Data Services provided a REST-friendly approach to managing CRUD operations using ATOM as the message contract. The success of the ASP.NET MVC framework, which has all but subsumed its older, less cool ASP.NET Web Forms sibling, is further evidence of the developer and user community embracing the browser as a conduit for interoperability on the client.
The Mobility Wars
Even amidst the mobile revolution, which has been largely built on the ubiquity of broadband connections and increasingly capable handheld devices, proprietary platforms have emerged which in many ways are more restrictive, and costly than any other platform. Want to build apps for iOs? Learn Objective C. Android? Got Java? Windows Phone? .NET. Even though they all sit on similar devices and depend on the same infrastructure for messaging (the internet), apps are hardly interoperable with one another. I am sure you know at least two people that carry multiple headsets with them for this very reason, and tablets, sure to be the next wave of mobile innovation suffer from the same dilemma (if you ask me why HP abandoned WebOS, I think it has more to do with the writing on the wall regarding HTML5 than anything else, but more on that shortly). At first, this dilemma seems somewhat benign, perhaps only affecting developers. The truth is it affects everyone. Talk to any iOS developer (that’s not a complete Apple zealot) and they’ll tell you that Objective C isn’t the most productive language to write apps with. Aside from Java not being too sexy these days, I don’t hear many Android (or WP7) users raving about the selection of apps in Android Market. Same goes for WP7 and Windows Marketplace- I remember how long I had to wait to get Angry Birds on my Windows Phone 7! But the most salient example I can think of is the fact that after a decade of browser wars, tremendous innovation on the client and the server, I still can’t play Flash videos on my iPad or WP7. My iPad refuses to run Silverlight apps, even though its browser on the desktop is fully capable of doing so. This is a situation that is just plain broken, and it isn’t just me that feels this way…
The World Wants Native Interoperability on the Client, and Today, the Answer is HTML 5.
Like it or not, HTTP has become the ubiquitous interface for both the client and its conduit to the backend. This incredibly simple protocol has had more influence on software over the last decade than any other technology, completely reshaping the strategies of the biggest players. I don’t have to tell you that without HTTP, you don’t have cloud computing. For example, who would have thought that Amazon, after pioneering e-commerce would get into the PaaS business by being the first to truly innovate in commercial cloud computing at scale? Who would think that Microsoft would completely reinvent itself on Windows Azure and invest as deeply in REST as it has, not only with standards and technologies like OData and WCF Data Services, but also in exposing their incredibly rich and powerful Azure APIs as REST heads? Again, the answer is simple. HTTP has become the lingua franca of the interconnected world and the disruption started with the first packet in the early 60s.
Just as SOAP was developed to aid in interop between vendor platforms, banks and partners, REST has increased the native interoperability of applications on the web. Hold your rotten tomatoes, but I am afraid that so too is the fate of iOS, Android, WP7, WPF, ASP.NET and Silverlight. Are they going away tomorrow, next year or 5 years from now? Nope. SOAP still has a very important place in back-end systems and I don’t mean just for legacy applications. When you you want to work with contracts and interfaces (very important when designing critical message exchanges for business processes), need support for heavy lifting such as distributed transactions, reliable messaging, multiple transports and the like, SOAP is your tool. Case in point as I mentioned briefly above is Windows Azure. While the investment in REST has been significant, these REST endpoints are merely designed for optimizing interop allowing any client or platform to take advantage of the services offered by Microsoft’s cloud. Want to start or stop a compute instance? Need to write a file to blob storage, retrieve an entity from table storage or publish a message for hundreds of subscribers to consume over the AppFabric Service Bus? There’s a REST API for that. While adoption is key to the success of any product or platform, the API, and thus REST is not the end itself but merely a means to the end, and as such is only the tip of the iceberg. Below the water’s surface, there is, and will continue to be a ton of SOAP and .NET.
The same is happening on the client with HTML5. While Silverlight and ASP.NET MVC were a step in the right direction and aren’t going to just vanish tomorrow, HTML5 offers true interop at the native (browser) level, and since native interop is what the world wants, it will win, at least for now. I say at least for now because as tempting as it is to chock this up to just another trend, unlike the crusty programmer personas I mentioned when I started this stream of consciousness that has become a rather long post (thanks for staying with me this far, btw), I’ve been doing this long enough to have seen software reinvent itself a few times now. I’ve learned that rather than cry over spilled milk, it is important to embrace change and this means you have to expect and be prepared for anything. HTML 5 could fail, and companies that have already invested significantly in ASP.NET, Silverlight, Flash and one (or several) mobile platforms aren’t going to just jump in right away, but they are going to watch very, very carefully. If I am building a web app or a rich client app today from scratch though, I’m going to think very, very hard before I decide to do so in anything but HTML 5.
Who Moved my Cheese?
Who would have thought that Microsoft, with an incredibly lucrative productivity, OS, server and tools business would bet the farm on Windows Azure? As innovative as I think Microsoft’s (PaaS) cloud story is, in many ways, it is the software giant’s response to its cheese being moved by the web. And make no mistake, it is a massive bet. Initial buzz around Windows 8 has so far been met with both positive and quite negative feedback after the revelation that Windows 8 will make HTML 5 a first class citizen on the desktop and the tablet. Viewed simplistically, the seams between client and server/backend are exposed with Windows 8 and Microsoft Azure respectively. At first, this seems quite alarming (Joel Spolsky saw this coming over 8 years ago), but if you think about it, it makes perfect sense. If the client is moving to the browser, the value proposition of a beefy desktop or a rack of servers in an opaque data center is diminished significantly. However, all that data, records, images, videos, files still have to be stored and served up some where, and that somewhere needs to be natively interoperable with the the client at the iceberg and get the heavy lifting done below the water’s surface. The need for middleware- integration between the client, that somewhere and its data, applications and systems has never been greater.
Even though I’ve joked to friends that stayed on the front end that I didn’t miss anything by skipping WPF and Silverlight because we’re back to where I first began with HTML and JavaScript, the reality is that the last decade has been incredibly important in reinforcing that innovation is bigger than any platform vendor or standards body because unlike them, it is you and me that determine the fate of technology, and for that we should all be proud.
So, What Now?
I provide no value without designing distributed solutions that can be consumed by the client applications and automate the business processes they serve. So just as before, its time to buckle down once again and learn the client technologies that one of my primary customers- the UI developer- will soon be using. First in line is Mango. Next is HTML 5. And who knows, after specializing in integration for the last 5 years, I just might start generalizing a bit and get back into web development again.
See you at the other end of the wire.