Skip to main content

Serverless computing and the rise of the 'non-developer developer'

Within traditional central IT, applications are created by developers for whom software development is their career. But that often is not the case for business-use IT developers, for whom coding is a means to an end.

[Editor's note:  This article originally appeared in HPE's Community on August 9, 2017.]

IT spending is no longer completely controlled by central IT. IDC estimates that more than 50 percent of IT is under the control of the business users outside of the IT department, and Gartner recently estimated that by 2022, the majority of CIOs would get direct control of less than 30 percent of all new IT monies allocated.

According to research by Hewlett Packard Enterprise, this change is being driven by the fact that spending is moving to both business IT and CDO (chief digital officer) IT. Per the HPE research, 73 percent of digital transformation projects and 76 percent of Internet of Things (IoT) projects are controlled by business IT or CDO IT, with traditional CIO/central IT people being relegated to providing infrastructure services.

Within traditional central IT, applications are created by developers for whom software development is their career. But that often is not the case for business-use IT development. Business IT developers might include paid-social executives, pump engineers, or factory automation engineers—anyone for whom coding is a means to an end. Their focus is completely on the destination, not the journey. In other words, if these users could use voodoo chants and strings of garlic to achieve the same ends, they would do so. 

Not already signed-up for the enterprise.nxt newsletter? Here's your chance.

Serverless computing: A technology and a solution

So what do we mean by serverless? Well, the first thing is that serverless is not "without servers." Rather, it's more, "You don't need to worry about servers."

The functions are born, they do something, and then they die. With serverless, you write functions. Those functions are called, they do their thing, and then they die. It's ephemeral by design.

Imagine you have a website that takes orders. You might create a "take order" serverless function. This function would be called when someone wants to place an order. The function would come into existence when called. It would take the order and perform appropriate processes. And then it would die.

Whoever wrote the function would not need to worry about servers. They would not need to worry about virtual machines. They would not need to worry about containers. All that is taken care of for them.

In fact, with serverless, you don't even need to worry about scaling in a parallel fashion. If 100 orders were being taken at the same time, 100 instances of the take-order function would be created automatically. They would simply run in parallel.

Of course, you need something to invoke your serverless functions. This could be any number of things: a web user interface (via HTTP), an IoT system raising an event, an event from Slack, or a mobile application.

For detailed information on serverless computing, the seminal work on the technology is considered to be a blog post, "Serverless Architectures," by Mike Roberts.

The evolution from bare metal through VMs and containers to serverless

In his SlideShare presentation on serverless architectures, CodeOps Technologies founder Ganesh Samarthyam has a nice description of the evolution from bare-metal servers through VMs and containers to serverless.

To build applications on bare-metal servers, you have to know about the:

  • Hardware
  • Operating system
  • Runtime environment
  • Code

To build applications on VMs, you have to know about the:

  • Operating system
  • Runtime environment
  • Code

To build applications using containers, you have to know about the:

  • Runtime environment (the containers)
  • Code

To build serverless functions, you have to know about the:

  • Code—and only the code

Introducing the non-developer developer

The technology called "serverless" promises to meet many of the requirements of the what we can call the non-developer developer. Consider this conversation with a business user who started writing code to do analytics:

Q: You have just started programming in Python. Why Python?

A: Because that’s what Google told me I need to use to get the level of analytics I need from our PPC [pay per click] data.

Q: What infrastructure does your analytics run on?

A: No idea. Don’t care. I just need to get the analytics so I can more quickly and accurately adjust my PPC campaigns.

Q: Do you like Python?

A: It gets the job done.

You get the idea: Business “developers” are often, in fact, “non-developer developers.” Nowhere in their objectives does it say that they must develop code; it’s just something they have to do to increase sales, to use predictive maintenance to stop their sewage pumps from failing in the middle of winter, or to make their factories safer and more efficient. These business developers are more likely to write code themselves with the tools they can find rather than create a project with central IT that may deliver results long after the business unit started asking the questions.

What are the requirements of non-developer developers?

The number one requirement for non-developer developers is the abstraction away from anything that detracts from them getting the job done—be it pay-per-click analytics or pump predictive maintenance.

Non-developer developers are not interested in servers (their size or how many are needed), storage, VMs, containers, parallelizing, and scaling.

They know security, compliance, data sovereignty, and data resilience requirements have to be met, but if that can be done without the business user having to do anything (or understand anything about the details of security, compliance, and the like), that would be great.

Non-developer developers usually start their development of an application in "experimental" mode. They may later move to what Gartner terms "scale-out mode," but to start with, and often for a good amount of time, they are in experimental mode. Experimental mode typically means they don't have much money, or if they do have money, they don't want to throw it all at something that is experimental. Because of this, they need pay as you go, meaning they want to pay only for the compute resources they use.

The pay-as-you-go model includes the option to walk away leaving no financial liabilities. Consider the case of a major water utility. The head of engineering (not central IT, but a part of the business) was looking at using analytics to predict when his sewage and water pumps were going to fail. He wasn't sure if this project would work. In other words, he wanted to experiment, paying only for the resources he used and having the ability to walk away if necessary, without being left with unused compute assets. His needs and concerns required that he be able to quickly prototype an application that would make use of the data he already had access to and that could use that data to provide practical information that would improve his business processes.

Where to find serverless computing

Serverless functions are available from public cloud providers Amazon Web Services (AWS), Microsoft Azure, and Google Cloud. AWS has had a serverless service called Lambda for a number of years. Azure has serverless as a production service, and it is available within Google Cloud.

AWS, Azure, and Google all charge for serverless functions on a per-invocation basis. Users of serverless like this because they believe it most accurately reflects the value derived from the service.

IBM and Adobe had a serverless framework called OpenWhisk. This has now been given to Apache. Also through Apache, Platform9—an expert in Kurbernetes, OpenStack, and hybrid cloud—has a serverless framework called Fission, which is currently in alpha. Platform9's serverless framework uses Kurbernetes to manage the serverless functions' birth, death, and if required, parallel invocation.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.