We often say that technology is a cycle of concepts. I don’t think so. It’s just that bad ideas are hard to kill, and are rebranded on a regular basis, hyped with marketing bullshit. Today, we will talk about Serverless(TM).

Serverless is quite interesting. In the case of a serverless application there is a server or probably many servers running code. So the « server » we are trying to suppress here is definitely not the hardware we use to power the application. Sorry for those who think we can run a node.js application live in the air, floating to the wind of electrons and running without CPU, RAM, disks… The question is: what is the thing we positively want to suppress on the serverless world if it’s not the server?

Serverless as a Major Performance Tradeoff

What is Serverless then? it’s a function as a service hosting model, where we just upload a small piece of code and sometimes data on a service and get an instant ops-free ability to answer on a URL with the previously uploaded code. And there is the response. There is no server boot, installation, management, routing… Everything is automated. Developers just code, publish code and code is started to respond on a sandboxed environment, its lifecycle bound to the request life.

Destroying context on each HTTP request is, on the vast majority of cases, a very bad performance and stability idea

I do not get this fascination for the request-bound lifecycle of application environment. It’s not the first time it’s shown as a great achievement, there was a myth of short lived containers on a single request… Let me explain my thoughts: the vast majority of applications I see today are made to accept connections from Internet (using HTTP mainly but some others protocols too) and get some data from a database, compute then serve. So, the ability to reach the database quickly is the main performances focus. Latency is still a thing (tell that to DBaaS vendors that don't let you run your code next to the data...). Connecting to the database involves a vast quantity of TCP protocols. And there is the point: establishing a TCP connection is LONG, SLOW and in many cases the most time consuming part of the request.

So, we want to keep the database connection between several web request, and keep the TCP pool awake. We don’t want to destroy the pool on every web requests. And the database server will also work better on stable connections, be much easier to monitor and audit. It’s all built on this paradigm. And yes, I also keep my TCP connections open when I’m working on databases with HTTP based API. Take a look at what we did with warp10.rs, the Rust client we wrote for warp10. Anyway, destroying context on each HTTP request is, in the vast majority of cases, a very bad performance and stability idea.

Better Server Management already happened without Serverless

Some years ago, the consensus around the 12 factors applications made most applications able to launch themselves and able to take care of their lifecycle. The model was in reaction to « application servers ». Because this model is really difficult to scale and it makes business logic and configuration spliced in many environments, and not only in one place. With serverless you actually use an application server. A closed source application server with a strong locking model, all the code produced will lock you to the provider, and the inter-portability will be an illusion, something like JEE application server portability. Except that this one, you can’t install it on your server, even for a bigger price.

Making it easy to deploy and provide sustainability to your application is really important to help developers focus on their value, innovation and to provide a quick feedback loop. The serverless name is not about removing the hardware server, but the server management, the time consuming coordination of managing how a server works. I agree. This is why we created Clever Cloud. it’s to provide application sustainability; the ability to easily deploy and be sure that the future is managed: updates, monitoring, self healing, scalability, security, backups…

The whole server management has to be a commodity, it’s what we deliver at Clever Cloud. And I think it has to be compatible with most applications, new or legacy, and should not impact the application architecture or portability . IT automation is a great idea to help people just send the code and leave the management to software. It solves timing and synchronization constraints between people, gives them the ability to innovate, build, and adapt to the software market more easily than before. Because when someone says "I like serverless", what they say is: I do not want to hear about servers and the all ops stuff, I have work to do.

Conclusion

When you create code, just be sure you are not writing it on someone else's paper, it will hurt sooner or later.

The software industry is quite young, about 30 to 40 years old. Yet massive companies emerged quickly: billion dollar businesses bringing huge social changes. What does it mean to be a developer today, and how did that job evolve these last few years? I think we need to picture this as a global shift within the evolution of productivity.

Image Source: Disney

Nowadays, we know that null is to be avoided. It's been dubbed the billion dollar mistake by its own creator, and the dreaded NullPointerException everyone knows about. Yet, when it comes to getting rid of nulls, nobody agrees.

null is bad, m'kay

• NPEs
• hard to read (is this value always defined?)
• handling possibly undefined values is tedious

The issue is that we focus on null, and not on the actual problems it causes. If your only goal is to get rid of NPEs at all costs, then you will pay those costs. Dearly.

The memory safety issues caused by null are solved on most platforms. In many languages, null is a pointer to a specific value with specific properties, so not literally a null pointer anymore, and on modern OSs, the memory protection system will prevent your code from directly accessing the address 0x00.

So the big risk is having your program blow up (NPE, segfault, panic, …) because of an unexpected missing value. The core issue is that you were unable to express that the value was possibly missing; the crash is a consequence of this issue. Yet many people try to solve the issue by preventing the crash (null check, null object pattern, …) instead of handling the core issue: a value could be missing and you weren't able to express it.

Stop chasing NPEs and fix your domain model

If you're trying to get rid of NPEs by removing the difference between "there is a meaningful value" and "there is no value", then not only you're not solving your issue, but you're making it far, far worse.

Your domain model didn't let you express statically the possible absence of a value, but the presence of null at least gave you a stuctural difference at runtime. That's why putting default values or worse, following the null object pattern, is terrible. You had structural information, but couldn't use it in a rigorous way, so you're just throwing it all away because of an implementation detail.

If you're searching for a replacement to null to denote missing values, it has to be structurally different from a regular value (it cannot belong to the domain of the value you may have). So if you're in a typed system, then a value that may be not there has to have a different type from a value that's definitely there. In an untyped language, you can't have a static difference, so using null is kind of OK (though there are better solutions).

For example, in java you can do:

// Bad
String notThere = null;
String there = "my string";
// Turbo-bad
String notThere = ""; // or "N/A", etc
String there = "my string";
// Good
Optional<String> notThere = Optional.empty();
Optional<String> there = Optional.of("my string");

With optional, not only you have a structural difference between defined and undefined strings (instead of having to check if the string is equal to "" or "N/A", without any guarantee that it's not the actual value), but it's clearly documented in the type.

Optional is available in Java 8 (and in Guava if you're not using java 8 yet). In scala, rust, ocaml and many other languages, it's called Option, in Haskell it's called Maybe.

This is why you can have nice things

Ok so now you have a proper representation for your optional values. In a typed language it means that you're forced to check if the value is already there before using it.

For instance, in java:

Optional<Integer> parseOptionalString(Optional<String> myOptionalString) {
    if(myOptionalString.isPresent()) {
        Optional<Integer> result = parseInt(myOptionalString.get());
        return result;
    } else {
        return Optional.empty();
    }
}

This works perfectly well, but is still as verbose as using explicit null checks. So if you're only concerned about code terseness (you really shouldn't), it can feel like a marginal improvement (it's way better than that).

Thankfully that's not the idiomatic way of handling Optional values: now that we can denote the abstract concept of being possibly not there (in this case, Optional<_>), then we can do useful stuff about it:

• transforming it only if it's defined (with map)
• eliminate the option by providing a default value when we don't need the information anymore (with orElseGet)
• sequencing several operations returning options (with flatMap)

All of this comes for free because we were able to clearly define our domain model. Some languages like Kotlin provide approaching solutions with things like the Safe Call Operator for chaining operations (instead of using map and flatMap) and the Elvis Operator for providing default values. This, however, is less extensible and less composable than having proper options (map and flatMap are not specific to Optional).

Optional<Integer> parseOptionalString(Optional<String> myOptionalString) {
    return myOptionalString.flatMap(parseInt);
}

Once you have properly defined your domain model, then you can have cleaner code thanks to the information encoded in your types. Aiming at terser code without proper abstraction will lead you to perlish nightmares.

To sum up

Using null causes problems. Resorting to solutions that erase information (setting a default value too early or worse, the null object pattern) will cause graver and subtler problems.

In order of decreasing importance, the problems with null are:

1. it's not clear for people if a value can be missing
2. the program can blow up if somebody forgot to handle a missing value
3. it's tedious to sequence operations returning null

Don't settle for solutions that only address #2 and #3.

The software industry is quite young, about 30 to 40 years old. Yet massive companies emerged quickly: billion dollar businesses bringing huge social changes. What does it mean to be a developer today, and how did that job evolve these last few years? I think we need to picture this as a global shift within the evolution of productivity.

Let's start from the beginning.

Tool creation is deeply linked to human progress: to improve our quality of life, manage population growth and create new endeavors. With time, tools are less and less focused on survival.

The evolution of tools is strongly linked to “technology”: better product quality, more variety and quantity. This progress is not linear. It's accelerating. Ray Kurzweil wrote about this in The Age of Spiritual Machines, where he described the “law of accelerating returns”: each step up makes the next step closer (For instance, X-rays paved the ways for many medical breakthroughs).

Industrialization was an important step on production of tools. It brought :

• cost-efficiency
• standard quality
• repeatable processes

All these to produce items in industrial quantity. So some items became something we called commodity.

Commodity is a significant concept. A product becomes a commodity when its quality becomes predictable, repeatable, and it fulfills a common need. Let's take pens, paper or clippers as example. Nobody care about their brand. We need them to be cheap and predictable. Cost efficiency is essential. Imagine the cost of a clipper handcrafted by a blacksmith. That would be a luxury product. And the ROI of this product would be irrelevant: nobody would use it. So our quality of life would be affected (what’s life without clippers? HELL).

In the 19th century, industrialization took over manufacturing. Machinery started replacing most of the human work force. This evolution was driven by the engine replacing the human and animal muscle. During the last decades, computers have been revolutionizing work by replacing humans for intellectual tasks. At first, people delegated simple and repetitive tasks: computation, accounting, price comparison, long-term memory, etc. As the technology moved forward, we started using it for more complex stuff, mapping increasingly convoluted workflows, networking communications.

Now it’s time to delegate more complicated tasks like image recognition, translation or have systems play Go. This is it: as engines industrialized muscle, computers industrialize brains. We are commoditizing of intellectual services.

So now let’s talk about developers.

A software developer’s day to day job is writing code. Modeling specific processes in software, creating tools to industrialize intellectual services, improving value creation and processes to leverage money. With a nice ROI. This is why developer-managed companies became so successful: Microsoft, Apple, Google, Uber, Facebook, etc. They industrialized intellectual services, disrupted markets where brainpower was only human powered, non-scalable and unfocused. This is why Marc Andreessen said that « software is eating the world ».

The industrial revolution of intellectual services is here, and developers like you and me are at the heart of it.

This professional evolution leads to a new way of producing software: more fluent, able to adapt the “brain power tool” faster, in a competitive market. Quickly adapting software makes for adapting businesses. It brings a huge advantage over the competition. The job of a developer must focus on short and continuous delivery, to compete in that market. This leads to a specialization of developers in various combinations of skills and tasks.

Some will go for low level systems. Others, on higher abstraction levels, will manage data or create data pipelining related to core business. That's why “developer” is more of a skill among others specialties, like banking, insurance or food, or people knowing how to model the process in a business domain, optimize and adapt it in a short time.

This is why we need to push forward efficient software factories, from dev to QA to hosting and production. Greatly reducing human and process costs to ship new software will give a decisive competitive edge.

This is why continuous delivery is now necessary.

Because it is driving competition between companies. Because it is reducing cost and time to deliver new software. Because it's providing the finest brain power at exactly the right time, and more important, ahead of others in the market.

The major change in company organization in the last few years is a pivot point. IT services evolved from being a cost center to being a company’s core, with software running the largest part of the business. It is becoming the biggest part of a company’s valuation. As developers, our role is to maintain this core and to make it evolve. We need to bring organisations to the next level, understand market and business logic, and deliver updates to all industrialized intellectual services.

Do you know that hosting is one of the nastiest business out there? Hardware, bandwidth suck up huge amounts of money and energy. But some hosting companies want to give it for free, forever. And people keep asking me “do you have a free plan?”

The problem is quite basic. Hosting the web's "hello world" applications for zero money is not a sustainable business model. Most of all, we should really ask ourselves: is it really useful to humanity? The problem with free offerings is that it’s killing product value: nobody really takes care of a free product.

At Clever Cloud, we have built a great platform.
We’ve worked with developers to help them build great applications, be more efficient, and sustain huge traffic surges without stress.

Our job is not to host unfinished side projects.

Hosting the web's "hello world" applications for zero money is not a sustainable business model. Most of all, we should really ask ourselves: is it really useful to humanity?

Since free tier costs money, who really pays for it? Loyal and paying customers, of course. And that’s just not fair. I prefer to say: our price is the right price. We are not making you pay for a poor marketing idea. If you are not ok with our price, don't worry.

We can always agree on something: just email us at sales@clever-cloud.com.

But the problem about free tier goes even deeper: this poor marketing strategy is lowering the overall customer perception of PaaS. What doesn’t have a price doesn’t have any value, and the idea that PaaS provides no value is a deeply entrenched misconception. This is one of the reasons the PaaS market has taken so long to emerge.

Can Clever Cloud ever be free?

Sure, we help open-source projects, charity, media and other projects by giving them free hosting. If you think your project deserves it, just send me an email: quentin.adam@clever-cloud.com.

Post Scriptum: I’m really happy to see Heroku changing their point of view on this and slowly nerfing their free trial offer. The industry, and the web in general, can only benefit from it.