maxkabakov - Fotolia


In no-server, NoOps cloud era, developers deliver to users

What do developers and musicians have in common? Both have been stripped of the middleman as their products are delivered directly to users. But what does a NoOps era look like?

Imagine you're a music publisher. You make money by bridging the gap between musicians and people who wish to listen to it. You take a big chunk of the economic value of each transaction because you solve a lot of complicated problems. Without you, artists would languish in obscurity and the shelves of record stores would remain empty -- wait, record stores?

Fifteen years ago, there were many record stores. Since then, the internet has utterly disrupted the business of music publishing by commoditizing and democratizing all of the things it did. Enabled by cloud computing, Google, YouTube, Spotify and countless other online services, which made it easy for consumers to access artists and their work. The effect was to erect a streamlined pipe between producers and consumers, cutting out the facilitators and the overhead. Whether this is a good thing remains to be seen.

Now, imagine that you run a department within a large enterprise. You have a vision for how to use software to deliver more value to your internal customers, and you have a team of bright developers who can execute on it. Between the output of the developers and your customers are probably several layers of operations and infrastructure. There are the people who manage devices, the people who manage how those devices connect to the network, the people who manage the network, the people who manage servers, the guardians of data and the people who make sure it's all secure. All those layers are a little like what the music business was, but how does that picture change with NoOps?

You might think I'm out on a limb when I compare software developers to artists who make music, but the analogy holds. In both cases, something that didn't exist is created through the work of skilled minds and has value because of its desirability and usefulness to people who will pay for it. You could say the same about a painting, a novel, a plan for a building or advice on how to win at poker. You might object that a large part of the value of software is in the servers it runs on, the wires over which its bits stream. My response would be that those things are not value: They're overhead.

When you're trying to deliver value to customers, anything in between you and them that you have to pay for is overhead. Overhead, by definition, reduces the value of a transaction and is only allowed to exist because there is no choice. While there is no choice, the overhead can be seen as acceptable, perhaps even good. Like the music publisher, it solves a problem. As soon as a choice materializes the overhead is shed and overall value increases. One way to view the phenomenal growth of cloud computing is as the consequence of thousands of businesses, from startups to established organizations like Netflix, shedding overhead because they can.

All of this lends impetus to the emergence of serverless computing, which we could just as well call NoOps.

When reliable, performant, large-scale computing and networking resources are available from stable providers at commodity pricing, only the very largest enterprises can justify building their own. Recent software as a service outages like the infamous Salesforce #NA14 incident were taken by many to be a signal of the risks of moving to the cloud, but software quality is a separate issue from the overhead of infrastructure. You can buy your software or you can build it, but in the future, the chances are very good you won't own the boxes it runs on or the network between them, and why would you want to?

So you can move to the cloud and not have a network to manage or racks of servers that need power and a place to live and engineers to keep them humming. Someone else will provide all that at massive scale and far more economically and skillfully than you'd be able to. That's good, and you'll be happier, but you still have to manage the runtime state of the servers you're renting from them. You still need people who can make sure all the right stuff is installed and connectivity rules are defined and DNS routing is set up and backups happen. That's overhead. Perhaps you utilize developers in these roles and call it DevOps. That's still overhead.

Imagine an artist today recording music and uploading it so that millions of people can consume it at essentially zero incremental cost. Almost all of the overhead in that transaction has been shed. That's software developers in a few years. That's many right now. The tools to enable the streamlining of software delivery pipelines were made possible by the cloud, which boiled away a lot of the infrastructure overhead, and platform as a service offerings like Heroku and Google App Engine that began stripping the system configuration and platform management overhead. All of this lends impetus to the emergence of serverless computing, which we could just as well call NoOps.

Take AWS Lambda as an example. Launched in November of 2014, Lambda was one of the first serverless platforms. You write code, you upload it and it runs. Amazon designed a powerful event system that invokes your code and passes input to it. It can run in response to API gateway requests. It can run on changes in an S3 bucket or RDS database. It can run when a line of text appears in a Cloudwatch log. It can connect to internal and external services and do stuff. You pay by the request and by the amount of CPU used, and there's not an instance in sight. Google has launched their own competitor as Cloud Functions, which has the same basic goal.

That goal is to make the deployment of code, and thus the delivery of software value, as efficient and free of costly overhead as possible. My experience with Lambda has been that it is stable, reliable and fast enough for many tasks, particularly event-driven data transformation and HTTP request handling. Parts of it are still more complex than they need to be, but AWS CloudFormation and open source frameworks like Serverless step in to make setup and deployment much simpler and more repeatable. A NoOps environment may or may not be suitable for your production tasks today. That depends on what you're doing, but the future these systems herald is clearly on the way and will be offering businesses yet another opportunity to reduce overhead and deliver more value to end users.

Next Steps

Even as DevOps matures, IT ops specialists still have key roles

A question for all software developers: what's in your sandbox environment?

When DevOps isn't enough, try NoOps

Dig Deeper on Managing software development teams