Why The Middle Tier, Including Docker, Won’t Matter to Most of Us
The rise of cloud computing (read: VMs, containers, bare metal by API) is of enormous benefit to businesses everywhere: we can now deliver products faster and better using fewer workers than ever before. And we are seeing a concordant interest in technologies that improve on the first iterations of cloud computing, from monitoring tools to containers and Docker. But the knee-jerk focus on improved versions of cloud computing ignores the fact that cloud computing is in the process of being disrupted by cloud-based services in a way that will ultimately render these improvements irrelevant to most organizations and developers.
The middle tier is being abstracted by cloud services. The developer doesn’t have to deal with all the complexities that have historically come with managing apps. It is the service provider, not the user, that manages the application servers, containers, monitoring and everything else. A user developing a thick AngularJS web app just makes a call to the service. They don’t have to really worrry about the hosting and all the backend complexities that come with the middle tier. They just want the service to work. That’s the user’s main concern.
The middle tier arose with the explosion of software as a service (SaaS). Starting around 10 to 15 years ago, applications that used to be written as thick desktop clients running against locally-hosted databases, began to be built as web browser front-ends running against centrally-hosted databases. Because the web browser front-ends couldn’t run complex code reliably and couldn’t be trusted (from a security standpoint), a “middle tier” emerged, handling communications between the front-end and the database. This “middle tier” became quite thick, leading to frameworks like Ruby on Rails to help manage large and sprawling codebases that essentially did all of the work of the applications.
But then the iPhone came along, and it became clear that mobile apps would be a big thing, leading many to declare applications should be build “mobile first.” The user experience of mobile apps was superior to the mobile web in many cases, so companies realized to reach customers most effectively they would need apps. Additionally, the capabilities of client web browsers improved significantly, allowing for much better browser-based user experiences with “single-page applications” (SPAs) that used Javascript to make the browser work much like a thick client-side application.
But the thick middle tier was not built with thick client code (app or SPA) in mind, and so the two had an awkward marriage for a while. Until, that is, services like Parse and Firebase came along to enable mobile app and SPA developers to build awesome client-facing applications without the necessity of a middle tier at all. Instead, these “backends as a service” (BaaS) handle everything. And even applications built with middle tiers are embracing these new thicker clients. And so the size of the middle tier is shrinking.
The middle tier is also shrinking because of a sea change in the way applications use databases and data stores. The traditional single-master relational database (think SQL Server, Oracle, MySQL) that stores all data is being replaced by a collection of data stores that are purpose-built: object storage to hold files (and large text blocks) and highly-available document/key-value stores are regularly chosen as the main databases for applications because of their ability to deliver high availability. And even relational databases are being replaced by managed relational database services like Amazon’s RDS.
Two different customer-driven desires are driving the size of the middle tier down: better user interfaces (thicker clients) and higher availability and speed on the data-store side (thicker database services). It is difficult to see the middle tier growing again — as we get better and better cloud services, we reduce the amount of time and effort and code we spend on non-core-business-specific functions. Like middlemen in many situations, the middle tier in applications is being disrupted.
And this brings us to cloud computing — specifically, running compute units like VMs on Amazon’s EC2, or containers on Google’s Container Engine. Cloud computing isn’t running the front-end code (which instead resides at the client), and increasingly, it isn’t running the data store, which may be a managed NoSQL service like DynamoDB or Orchestrate.io, or on a managed database service like RDS, or may still be a relational database on a beefy bare metal server to handle the load properly.
So cloud computing, for most of us, is largely about running the middle tier of applications — the vanishing middle tier.
All of this means the next iterations on pure cloud computing (e.g., Docker) are going to be relevant mainly to the people who are running cloud-based services, in the same way tools used by power plants are only relevant to people who work for the plants, and not to most people who consume the energy produced by those plants.
To put things another way: the immense benefit of outsourcing workloads does not end with moving from VMs in a local data center to containers running on public cloud computing. There is no inherent reason why the average company need worry about individual servers. It is said it is better to treat servers like cattle than like pets, but wouldn’t it be better still to have no livestock (servers) at all? I, for one, have no inherent need to optimize my cloud computing instances if I can get rid of them entirely.
Originally published at thenewstack.io on April 3, 2015.
