Ask the Expert: Server to serverless—How businesses can achieve more by thinking of servers less

Software design and programming have often been compared to songwriting: it’s very abstract, it usually written in pieces, comes together slowly, and often fails to create a ‘hit’ song. 

However, get all the parameters right, and it’s something that spikes in popularity and enjoyment. That’s the upside.

The downside is that after listening to it—or working with it—for a while, its star slowly fades, and in time it needs to be replaced with yet another ‘hit.’

This is also true of software development. We’ve gone through various cycles in design and languages, as well as multiple cycles in hardware capabilities. I mention the hardware only because, over the decades, the capacity of hardware is often reflected in the design and construction of software.

I feel the influence of hardware (or now the lack thereof) is at the heart of the paradigm shifts in software application design we’ve been experiencing in the last few years.

Serverless… or servers less?

The current ‘hit’ in software development is something that is being referred to as “serverless” application design. This is often interpreted as a software design that does not need servers. Obviously, this isn’t true, and both linguistic purists and those in IT management alike wince at the use of the word.

My interpretation of the term, however, is different: “Serverless” is a design paradigm that simply means we think less of servers, or think of servers less. When we think of “serverless,” my perspective is that it allows us to think of software architecture (and the business domain that it serves) more than the deployment of that software across various bits of servers and hardware.

Of all the change that’s occurred in software architecture, this is a change not only in the abstract design of software but also in the business acumen behind how enterprises use it.

In terms of software architecture, most Architects work from the traditional perspective of servers. The “architecture” designs need a web server, and server with business logic, and likely a database server to persist data. This is NOT thinking of servers less; instead, it’s a paradigm that we naturally fall into. If we are to think of serverless, we must think of services first and foremost, rather than servers.

The same thought pattern using a serverless mentality would be a web service (HTTP/HTTPS); application services (or even better, business services and their business processes); and finally a data persistence service. Note that in each of these layers we talk about services, and the notion of a product that provides the service becomes absent in thought.

Think of servers, and you may think of something like IIS on Windows, or Apache and the implementation on those platforms. Think of the service that the application needs, and the thinking moves to the application domain—rather than the physical deployment domain—and how that domain provides those services, which likely directly affects the software design. (For example, authentication and how it works with IIS vs. Apache would be a distraction from the business need for authentication.)

A new way of thinking

As most Solution Architects today have been trained with only a server deployment mentality, this paradigm shift in thinking requires discipline to NOT fall into old habits, and the paradigm of designing software to what servers offer. We need to stay above the implementation perspective, and only think of what the application requires from a services perspective.

In terms of the business acumen of IT in enterprise-level businesses, this same paradigm exists. The technical deployment paradigm has bled over into the business domain. Business leaders, at a high level, solution against their business needs in terms of what they know. This is only natural of course, and most business discussions of IT center around a business-lead solution.

Solution Architects who attend to these business needs interpret the design and add the necessary details so that Technical Leads can construct the software and deploy to the servers. The business is happy, the Solution Architecture did their job, and the software was created as the business stakeholders had wanted.

However, a significant opportunity has been likely missed: everyone involved has been thinking of servers rather than services. In cloud platforms, Platform-as-a-Service (PaaS) is often thought of as the counterpart to servers. For example, a SQL Server provides a SQL service, and web server provides a web service. But the capabilities of the platform service, as opposed to the server, does not translate well, if at all.

Platform services are scalable, reliable, accessible, and, arguably most importantly, dynamic. Aside from their dynamism, their other characteristics can be provided by a server configuration, though at a considerably higher cost in terms of time, resources, and coordination. These characteristics of platform services, let alone how to leverage them in existing or new business models, are simply not appreciated by most business leaders.

Thinking of server-less in both business domain and software architecture can yield amazing results.  Consider a business (any business) that went from start-up to a $1 billion evaluation in 18 months! In a traditional business landscape, this is simply not possible. The infrastructure of both business and technical aspects would not be able to scale quickly enough. Yet this is exactly what happened to Instagram.

Instagram: a serverless success story

Instagram moved to a cloud platform very quickly after it launched because waiting 48 hours for a new server was simply too long. Then, in April 2012, it again leveraged the cloud to handle signing up 1 million users in 12 hours after it launched its Android mobile app.

Most business leaders today don’t realize how a staff of just 14 people executed Instagram’s business model and harvested the required computing power to earn so much success in such a short period of time.

Benefiting both the commercial and technical sides of the business, cloud services allowed the Instagram team to dynamically scale their solution quickly, easily, and most importantly, as it was needed. In the past, the resource needed to address this steep uptake in business would mean significant time, effort and capital to purchase equipment, carry out configuration and maintenance, manage licensing, and cover overheads like physical space, networks, power, and cooling: all of which would’ve taken significantly longer and would have had a negative effect on their overall market success.

What if somebody made the same effort to focus on managing financial data? Oil and gas? IoT devices that send data directly to the cloud? Health care data that uses the patient as the central focus to share data?  Would business leaders in these industries predict an assault on their market segment in the same timeframe?

In traditional business leaders’ thoughts, they simply do not believe it’s possible. Business leaders must mix business acumen with dynamic cloud service capabilities, which would allow them to repeat of Instagram’s incredible success.

Marrying commercial goals and tech know-how

To bridge this gap, business leaders must express business problems and goals without allowing their technical knowledge to limit their vision of what’s possible. Without knowing what businesses like Instagram have achieved with cloud computing, how many business leaders would set a target of 1 million new customers in 12 hours?

Architects must educate themselves on what cloud services are, and how they can help businesses avoid the limitations of server deployment and configuration.  More importantly, they must understand the commercial needs that underpin everything they do, and ensure business leaders recognize that 1 million new customers in 12 hours really is possible.

Bi-directional communication and mutual respect between IT and business leaders is essential if companies want to achieve an optimum solution—a solution that supercharges existing business models, or adapts to new business models that weren’t previously possible.

Only then can we achieve the ultimate goal of IT as an enabler of an agile and efficient business that can respond quickly and easily to both increasing demand and changes in business requirements.