The term “devices and services” has become very popular recently. However, a lot of people including software engineers wonder what it means in terms of technology as well as how it will generate revenues for software companies.
This article represents my personal opinion and only my personal opinion. It may or may not match Microsoft’s opinion. Either way, this article MUST NOT be taken as official or sanctioned by Microsoft.
Devices
Price Wars
It is naïve to think that any company [except Apple] can generate considerable revenues from hardware devices. The reason for that is that devices are made of mass market components. If one company can design a device with certain capabilities and a certain form factor, then other companies can do the same at the same or lower cost. Thus a device pioneer won’t enjoy glory for too long. (The only exception could be Apple that has uniquely loyal customers who are willing to pay extra for the brand.)
Look at this offer – Nokia Lumia 521 without contract for $69! This is a great device that runs the exact same Windows and apps that run on any expensive Windows phone, and the best of all features - no blood sucking contract! I don’t think Nokia/Microsoft will make a ton of money out of this device at this price.
Or, how about this Dell Venue 8 Pro for $279? This device is a full blown computer that runs the real Windows, not RT.Will Dell make billions from it? I doubt it.
Open Platform
The PC platform was designed to be open from the very beginning. No one has ever owned it – neither chip makers, nor operating system vendors, nor PC manufacturers. Apps have had full access to the hardware capabilities of the PC. Users have been able to install apps from anywhere. Very democratic.
Democracy, however, is not easy to consume. It requires knowledge and responsibility. For instance, when a user needs some functionality, she has the freedom to choose any app. Great! But where to find apps? How can she be certain the app will not do something bad either intentionally or unintentionally?
The open platform works fine for computer/software savvy people. As long as you know where to search for apps, and you accept the risk of eventually installing a bad app, you will enjoy the open platform. Although there were hundreds of millions of PCs sold worldwide, it was a tiny fraction of the human population that was using them effectively.
Closed Platform
It is possible to create a platform that restricts what apps and users can do, but that platform can only enforce such restrictions over the layers built on top of itself. If the lower layers of the stack are open, an alternative platform could be installed that would not respect those restrictions, and thus no guarantees could be made. Therefore, in order for a platform to preserve integrity, it must include all the lower layers of the stack down to the very bottom – the hardware device.
That’s where devices come to play a major role. Devices themselves won’t be generating revenues. They will be part of a closed platform that is expected to be more profitable than its open predecessor.
Why will the closed platform be more successful than the open platform? Because, although we are crazy about freedom, we are too lazy to sustain it. We want simple, constrained, experiences. We want someone else to guarantee the safety of our own device. And that’s exactly what the closed platform offers – when you need certain functionality, there is a single app store where you can possibly find an app. All apps have been tested by the platform vendor before they’ve been made available for you to download. When an app runs on your device, the platform won’t let it use any device capability that it hasn’t declared. When you want to remove an app, the platform will wipe it out like it has never been there. That perfectly fits the needs of our modern spoiled civilization.
But how would a close platform generate a revenue? Here is the model that Apple pioneered in modern days: the platform vendor takes a percentage from every single app sale. Let’s say 4 developers have made app sales for $1M each. If the platform vendor takes a 25% cut from each app sale, it will make $1M while each of the developers will make $750K. Now imagine 4 million developers selling apps. You can do the math. Not every developer will be successful? No problem. The platform vendor requires an upfront license fee from every developer whether he will become successful or not. And yes, that license has to be renewed every year. Clever, isn’t it?
Devices and Services
The key factor that contributes to the success of a closed platform is the user experience. A good user experience attracts users who are potential app buyers. A large number of potential app buyers attracts app developers who make more apps available on the platform. More apps make the platform even more attractive to users which closes the loop and so does the process continue.
Emerging User Experience
Of course, each platform vendor will put its signature on the user experience, and will provide a different set of free apps to make its platform unique, but that’s not the interesting part. The important thing is the emerging user experience that is the same across all device platforms, and that will change the software industry.
To understand this new experience, let’s take a look at the evolution of doing business: In-person –> The Web –> Devices and Services.
In-Person
- Get your butt off the couch to sit in your car.
- Drive to the point of business.
- Stand in line.
- Do your business.
- Drive back.
- Place your butt where it belongs – on the couch.
5 out of those 6 steps are plain overhead. Not only does that waste time, but it’s often dangerous.
The Web
The Web significantly simplified the experience by replacing physical driving with cyber navigation:
- Get your butt off the couch to sit by the PC or to fetch the laptop.
Sit in the car and drive to the place of business.
Navigate to the target web site.Stand in line.- Do your business.
Drive back.- Place your butt where it belongs – on the couch.
The Web made it safer and faster. But one big problem still remains – we are lazy, and we want to sit on the couch doing nothing.
That’s where devices and services comes to help.
Devices and Services
Get your butt off the couch to sit by the PC or to fetch the laptop.
Suspend the Facebook app.Sit in the car and drive to the place of business.Navigate to the target web site.
Bring up the app for the job.Stand in line.- Do your business.
Drive back.Place your butt where it belongs – on the couch.
Resume the Facebook app.
Your butt remains planted on the couch the whole time. Halleluiah! This experience can only be successful.
Impact on the Web Site Industry
I’m not writing out of excitement about how our society will get fat faster. I’m writing because I foresee a disruptive change coming up triggered by devices and services.
From *SP to Plain HTML
The vast majority of web sites is implemented using a server page technology - ASP.NET, JSP, PHP, etc. An HTTP request comes to the server and gets dispatched to the web site’s handler. The handler loads and executes a custom module that does some computation and ultimately sends back HTML that a browser visualizes in front of the end user.
Since the user experience is what sells a web site, the UI dictates how code is written and structured. You may see projects where all the code is packaged in server page modules, though most commonly developers try to extract business logic into separate modules. That’s the funny part. Since all code paths are driven by UI experiences, it’s hard to draw a clear line where UI-specific code ends and where business logic starts. Thus what typically ends up in the so called business logic can be classified in two buckets:
- Unrelated utility functions.
- An object model that represents the persistence schema.
This is funny because despite of the developers’ best intents, such a separation has no value with regard to reusability or scalability. It might as well live with the rest of the server page code because that’s the only purpose it serves.
Now the important part - that code doesn’t belong to the server side at all! Its place is on the client side just like any other app. That’s the first architectural change that devices and services introduces:
Devices and services kicks web UI out of the server, and converts it to plain HTML. The web site becomes yet another client app for the given service.
This is a very important change because it deeply affects the COGS of running a web site. Instead of the service vendor paying for the resources (CPU, memory, bandwidth, etc.) needed to generate a web page, each user will run that code in their own browser. And those utility libraries and object models? They’ll have to be rewritten in JavaScript - as I already explained, they only serve the UI.
Scale Out and the Current Lack of It
The removal of the UI from the server will reveal an unspoken truth:
Most web sites never really scaled out.
(There is a tiny portion of modern web sites, mainly in the search or social space, that are designed to scale out and that I don’t include in the above statement.)
Most development teams actually believe their web sites scales out. And their scale out is done by replicating front end boxes where those teams believe the most compute-intense code, the business logic, runs. First, we now know that all that front end code doesn’t belong on the server side to begin with. Second, the assumption that the most compute-intense code is outside of the data layer is wrong, because the relevance of a web site is proportional to the data it processes. If there was no giant volume of data around which the whole experience gravitates, you’d be running that functionality on your local box!
(In all fairness, there are some web sites that offer a poor man’s backend scale out by creating static partitions. A user session statically belongs to exactly one partition based either on the host name or on the user account. While this approach does offer some scalability, the scalability is uneven and the approach requires constant monitoring and a manual migration of data among partitions to maintain a relatively even distribution. Thus the cost of this approach is too high to accept as long-term solution.)
That defines a problem for the whole web site industry:
Follow the search and social leaders and design your data stores to scale out.
A lot has been written about Big Data, and I won’t repeat it. My point is that Big Data stores will become the primary choice of data stores for web-facing systems. The sooner development teams accept this idea, the better position they will get in the new world of devices and services.
Thin Client No More
Lastly, I’d like to point out that our perception of the client experiences will change. So far we’ve been categorizing clients as “thin” (web pages) and “rich” (standalone apps.) The web interface was viewed as lass capable than standalone apps. That perception is about to change – device apps will provide limited UI for limited functionality suitable for the lower resolution and the smaller form factor of the device while the web pages will provide full functionality leveraging high definition screens. For instance, we’ll be using our phones to read our Facebook feeds most of the time, and we’ll use a browser when we want to do a more sophisticated operation like managing settings.
Conclusion
Devices and services launches a new era in software history. The trend is irreversible. We, software developers, will have to accept the constraints and the requirements of the new platform.
I am truly excited about the disruption to web-facing systems. As a backend developer, I’ve been waiting for the demand to build up, and now that the moment has come, and I can’t hide my excitement.
No comments:
Post a Comment