Serverless

With the introduction of the serverless paradigm, another level of abstraction was introduced that did away with the need to maintain uptime or deal with server patching and updating. Serverless applications run in stateless compute containers that are event-driven, ephemeral (may last for one invocation), and fully managed by the cloud provider of their choice.

These applications scale seamlessly and do not require any server operations.

Serviceful Serverless

I recently saw an article by Joe Emison that used the term Serviceful Serverless.

He responded with a link to the talk where the term may have been coined:

While I have subscribed to a similar philosophy, I had never heard of the term until then. I had described similar ideas and labeled them as Managed Serverless, but I like Serviceful Serverless better because I think it describes exactly what it is.

Serviceful services assume responsibility for providing a defined set of services and are “serverless” in the sense that they do not require any server operations, scale seamlessly, and require no need to manage uptime but most importantly they are essentially codeless.

A few examples of serviceful services include Auth0 / Amazon Cognito(managed authentication), Algolia (managed search), Contentful (content infrastructure), AWS AppSync / Cloud Firestore (managed API services), Amazon Lex / Rekognition / Textract (machine learning services), and Cloudinary (managed image & video hosting service).

In the past, each of these back-end features (search, API layer, auth, etc..) took a competent back-end engineer weeks / months to build securely and properly.

Now a front-end developer can hook into these services and implement these features with no knowledge of the actual back-end implementation, with little to no back-end code at all, and they can do so at a fraction of the time and cost.

Codeless

Because these services are created and managed by a third party, the services require you for the most part to write no back end code meaning your application has less code.

Less code leads to less bugs and your application becomes that much more easy to maintain.

When a new developer comes onto your team or you hand off your project to someone else in your organization, on-boarding becomes easier because the mental overhead is also decreased (there is simply less to understand).

Less Complexity

Along with less code comes less complexity. This architecture abstracts away complexity by providing simple APIs that *just work*.

This moves the discussion from “managing complexity” to “removing complexity”, the complexity simply does not exist anymore for these features since they are no longer in your codebase.

Developer Velocity

This way of engineering enables developers and companies to iterate much more quickly and cheaply, enabling them to experiment more often and with less overhead than the traditional approaches of building out these services by hand would allow.

Cost

In addition to the benefits that come with rapidly increased developer velocity, there is also the benefit of cost. In this paradigm, you are trading capital expense for variable expense.

Instead of paying an engineer x amount of dollars to reinvent the wheel, you are subscribing to a defined feature set and API and not worrying about the underlying implementation. You are also only paying for your usage (vs the up front cost of building out the feature yourself).

Sophisticated and Secure

These services have large specialized teams of people developing and maintaining them, consistently iterating on the given service that is their core competency. They also usually serve a large number of customers and even larger number of users.

This means you basically have a team of specialized engineers that have built out and iterated on something that you or your team simply could not do alone without investing an impractical number of hours.

They have been confronted with and solved issues and problems that you may have never thought of, “unknown unknowns” that only come with scale and experience.

Relying on something tried and tested always makes a lot of sense.

What is Serverless

While you may find many academic and opinionated definitions of what serverless means, there is no shared definition of what a serverless application actually looks like.

For instance, when people think of serverless, they typically think of a collection of Lambda functions calling each other and being invoked from the client application.

“Instead of a collection of functions calling each other, the best serverless/serviceful applications are: (a) thick client code handling all interaction logic, (b) heavy use of services (e.g., AppSync, Cognito, @Auth0, @Algolia, @Cloudinary), and © small glue functions.” — Joe Emison

I not only agree with this opinion of how modern serverless applications should be engineered, I see it in practice every day (from side project to startup to fortune 500 company).

What I don’t see though is enough discussion around the subject. I feel that it’s the ultimate enabler of innovation because of how fast and cheap it is now to prototype and test new ideas. Failing becomes much more tolerable because the up front cost is almost completely diminished as the services can now trivially and quickly be torn down and rebuilt over and over.

More and more companies and developers are ditching the need for a traditional back end and engineering team and instead focusing their efforts on delivering value to their users, with their important workloads being moved onto these types of managed services.

2019 and Beyond

This Serviceful Serverless philosophy will be something we see a lot more of in the coming months and years.

As complexity associated with software development continues to go up and the demand and cost for quality software engineers continues to skyrocket around the world, I think we’ll see cloud providers doubling down on these managed services while software companies and developers will increasingly leverage them to take advantage of the benefits that they offer.

If you’re interested in how my team is enabling developers to build these types of apps, we’ve built an entire framework around this philosophy. Check out AWS Amplify.