Foreword

In a hyperactive technology ecosystem, it’s easy to hear the latest buzzwords and form a knee-jerk opinion one way or another about their viability or relevance to your daily software practices and "serverless" is no exception. Establishing nuance and understanding what a single word could mean is often a luxury reserved only to things that break the initial knee-jerk reaction and linger long enough that you clicked this post.

This post is the first in a series about serverless engineering and application design. In this post, I'll introduce terminology and try to enumerate the technologies involved with each part of the serverless landscape, while also setting a template for building based on it. In later posts, I'll expand on how the technology should be used, what practices make for a good serverless application, and what pitfalls are frequently encountered while engineering serverlessly.

What Does Serverless Mean?

To get this one out of the way early -- serverless doesn't literally mean "no servers". It's astonishing how quickly commenters will jump past an article into the comments to repeat something like this. The comments may be true, but that doesn't make them a good argument against the idea just like "cloud is just somebody else's computer" didn't; their protest has no weight nor actual criticism. Serverless is the generalization of several different ideas. It combines Functions as a Service (FaaS), Database as a Service (DBaaS), Backend as a Service(BaaS), and, in case you're not spotting the pattern, pretty much anything "as a Service".

"Serverless" is a term that summarizes "X as a Service" where X is everything used to build an application. Rather than enumerating all of the "X as a Service" that a project uses, "Serverless" signifies using any number of these tools as your application needs them. "Serverless" is just a word, but arguing about the meaning of the word doesn't make the practices it represents more or less viable. It's those practices that are often distant from people's minds when trying to visualize an application serverlessly or appreciate what it means to build this way and what value this architecture provides.

The ecosystem around serverless right now is vibrant but still nascent. There are a number of strong technologies out there to work with, but since serverless is much more an ideology and design pattern than a pure technology, there's no comprehensive, intimidating graph of all of the technology available like there is for Cloud-Native, even despite the fact that the Cloud Native Computing Foundation (CNCF) has one specifically for serverless. A number of important practices and technologies will likely never be found on the graph above, despite being critical to the success of many engineers, simply because they are services and designs, not software or frameworks. However, a number of the technologies that help engineers be "cloud native" can continue to help them build reliable, serverless applications, if used correctly.

What Does Building a Serverless Application Look Like?

For the sake of simplicity, this series splits the application into a classic three partitions, "front-end", "back-end" and "data", each of which will be expanded on in their own posts. When developing engineering patterns, it’s important to attempt to generalize a solution for a wide range of projects. Some projects may find themselves overflowing a template and believe that's an indication that they can't build serverlessly -- this isn't accurate. If an application overflows the design, divide it meaningfully so that the portion that overflows the templated partitions below becomes a client of one of the partitions.

While it's important to partition an application this way to separate concerns, it should also be noted that engineering teams do not necessarily need to be formed aligning to these partitions. The split serves to denote where development effort should be focused and how individual concerns should be architected. Lastly, the partitions also denote levels of maturity and are listed by ease of adoption from easiest to hardest.

Front-End (Website, UI / UX)

Building an application serverlessly is easiest on the front-end. While it may be counter-intuitive, it's common that a company which is only beginning to make a move from private datacenter to cloud already has a website(s) or front-end(s) that are serverless friendly or already leveraging serverless practices/technology -- skipping cloud or making their first foray into cloud via serverless. Of those, the primary technologies and practices that front-end engineers can leverage to embrace serverless are:

• Single Page App (SPA) Frameworks
• Static Site Generators
• Content Delivery Networks (CDNs)
• Generalized Object Storage as a Service

It should be noted that Server Side Rendering (SSR) is explicitly not on this list and will be discussed in the later section as a service/API. If Search Engine Optimization (SEO) is a concern, work towards the setup above and then follow SSR guides in the API section to improve SEO.

Back-End (Business Services / APIs)

Meticulous readers may have noticed that the CNCF serverless landscape was purely focused on compute. It's a fair assessment to say that the term "serverless" likely came about due to a foray of newcomers in the compute as a service, functions as a service, and containers as a service arenas. However, it's important to note that simply using these services and practices may make your application appear serverless, but because only the stack is serverless and not the code itself, it can potentially introduce a deluge of headaches and accidental problems. This is why it’s important to when designing APIs and business services on the back end to be mindful of serverless practices. Back-end tends to be an area that is still being explored by teams and can often be fraught with mistaken optimization and implicit constraint.

The key technologies that back-end engineers will use when building serverlessly are:

• Functions as a Service / Workers / Lambdas
• Generalized Object Storage as a Service
• Containers as a Service
• In-Flux Storage as a Service
• Other People's APIs

Databases / Persistent Storage / In-Flux Storage

This seems to be the hardest thing for people, not just serverlessly, but in general. A number of problems encountered in back-end are actually database problems. Databases are trickier because there's not simply data in some store, but also metadata about that data's structure, data in-flux, and an abundance of configuration in modern applications. Serverless is no different, but it can often add some difficulty for those who don't already have good data management practices because of how spread out and duplicated the data can be. While there are a number of different products out there, the primary groups can be broken down by the service they provide:

• In-Flux Storage as a Service
  • Queues
  • Notifications / Events
  • Data streams
  • State Machines
• Relational Databases as a Service
• NoSQL Database as a Service
  • Configuration stores
  • Secrets stores
• Stateful Connection Pools / Load balancers as a Service
• Generalized Object Storage as a Service
  • ETL (Extract, Transform, Load)
  • Business Analytics
  • Data Lakes, Streams, Oceans, Pools, etc.

Conclusion

In this post I've given you a high level view of what technologies are part of a serverless application ecosystem and how you might mentally divide an application to begin developing serverlessly. Follow me for the next posts in the series where I'll dive into each component and paint a picture of how to build your application and which technologies to leverage.

About the Author

I am a Computer/Software Engineer focused primarily on Cloud-First Software Architecture. I have been working professionally with serverless applications for 3 years as a DevOps/Architect and 10 years overall in a DevOps role. I previously worked on a large web application, designing the architecture of APIs, React apps, and databases for a serverless stack. I recently left my previous role to start a company focused on serverless applications -- NullServe. NullServe aims to provide the tooling and platform necessary for product-teams to build out their ideas quickly and coherently using technology that scales up (and down) based on their needs. NullServe leverages existing cloud platforms to provide the performance and stability customers expect, but it simplifies serverless infrastructure and setup process so that developers can focus on building, not configuring. NullServe is Serverless DevOps as a Service.