DEV Community: NullServe

Building Serverless Front-Ends

David J. Felix 🔮 — Fri, 14 Feb 2020 14:56:44 +0000

Foreword

In my last post, I introduced the concepts behind serverless engineering and enumerated some of the technologies used by each “tier” of a three tier application (front-end/back-end/data). The purpose of that post was primarily to illustrate the boundaries of each tier with respect to a serverless design. In this post, I will discuss the front-end tier and how to apply serverless practices to this layer.
To quickly refresh some of the main points, the last post made note that front-end is frequently the easiest to develop serverlessly and many may already be practicing strategies shared by a serverless design. Utilizing the technology discussed in the earlier post, this article will set forth practices and strategies for developers to build with. The primary technologies discussed were:

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

Build

In order to build an application you have to build the application. This is more than just what framework or language is used, but how the build environment is automated and managed. The practice of codifying and automating builds is called “Continuous Integration” (CI); This is commonly used in conjunction with “Continuous Deployment” (CD), which will be discussed later, as “CI/CD”. The benefits of CI/CD in reducing build time, recovery time, build stability and repeatability have been espoused by nearly every corner of software development. To serverless front-end design, CI provides a reliable building and testing point at the most important event in front-end software lifecycle -- code change.

Most front-end developers are already building with serverless-friendly technology. The critical aspect of the build and design process of a serverless front-end application follows one simple rule:

Build and deploy as static assets, ie html, css, js and image files. Avoid using templates which are designed to be evaluated at request time, opt instead to have that presented client-side using a framework and favor build-time template evaluation.

While it’s possible to simply write your application directly in this format, there are a number of frameworks which simplify this process and enable developers to easily target their builds to these assets. If the application is going to be mostly static or based entirely on text or flat, encoded content, it might be good to evaluate static site generators like:

Static site generators can be used to maintain a consistent style and prevent repetition for sites where the content is mostly text or easily repeatable (like a blog or store) and where content doesn’t necessarily change instantly. If some of the content is dynamic, it may still be possible to integrate it with a static site generator, depending on the choice, but with enough dynamic content, it may be time to evaluate a Single Page App (SPA) framework like:

There are many more SPA frameworks and variants on the ones listed which may increase or decrease the complexity of the application, but the idea is the same -- as long as they are not Server-Side Rendered (SSR) frameworks which require a backend server and they target the static build assets listed above, they are a good fit for a serverless front-end. SSR which is "pre-rendered" or targets static assets is fine. While SSR is an important topic for performance, it will be discussed later in the back-end blog post. It is also worth noting that popular web frameworks like Ruby on Rails, Django, Phoenix aren’t listed here, despite their popularity, because they tie their template rendering to a request, not to a build. It is still possible to build a front-end serverless-friendly but doing so would require abandoning the templating engine provided by these frameworks.

Deploy / Redeploy

Once the application is built and the static files are ready for deployment, the Continuous Deployment (CD) practices become the next priority. In serverless designs, CD is important not only to developer convenience and for redeploy repeatability, but also because production servers, themselves, are a service that the developer utilizes. Working with these services should be like writing an API client-side interaction. The primary services, mentioned previously, which are invoked during a deployment are:

Generalized Object Store as a Service
Content Delivery Networks (CDNs)

Some examples of Generalized Object Stores as a Service are:

And examples of CDNs that could be used:

The deciding factors between which service to use for a given artifact breaks down to a few relatively simple rules:

If the file being served needs to be served from a custom domain name with a custom TLS/SSL certificate use a CDN.
If the file is large media or accessed by individual users and not all or most users, use a generalized object store.

It’s recommended from a cost and simplicity standpoint to prefer generalized object stores when they don’t fall into these explicit categories. Fortunately, traditional CDNs operate well over object stores to form a cache and more-modern CDNs integrate their own object store, so transitioning objects between these two is relatively easy.

Developers should build their CD pipeline so that the builds generated in CI are eventually uploaded to an object store or CDN via its API, then CDN cache is invalidated to complete the deployment. Teams can optionally retain old deployments for easier rollbacks, but with a fast CI/CD pipeline that may not be required. There are a number of tools/services which can help your team with building and simplifying this pipeline -- this author started NullServe to do just that.

Justification

While building serverless-ready applications might be a fun exercise in constrained design, it’s also important to many to justify why a change ought to happen and why not the old way. What this article and NullServe are here to show you is that this is the old way, before we brought in backend server bloat that slowed our websites down and made them more complicated. This “old thing” is just re-energized and empowered with a strong ecosystem of APIs and frameworks to support developers who are focused on user-first metrics.

Time to first paint / speed index

Beyond simply reducing bundle size and improving routing / network latency within your infrastructure, the final line of improvement is cache hits and customer proximity. CDNs dramatically improve last mile latency and aid teams in caching resources for customers. Using static site frameworks and SPAs can help to reduce network calls and hopefully reduce bundle size in some cases where the tooling is available. With this design, the app is already built for scale of any size, big or small, so there are no servers to manage to ensure your users get a fast and positive experience.

Time to interactive / Time to first contentful paint

The caching provided by the CDN can also help significantly when it comes to interactivity and contentful paint. While interactivity is largely dependent on framework performance, its ability to fetch data and populate the page is not. Javascript that’s already downloaded is always faster than the same javascript but being downloaded. Fetching data from APIs is one download shorter; in addition, since the services are very loosely coupled with the front-end, the data they send back can be much sparser and focused exclusively on values and not appearance.

Progressive Web App (PWA)

By segregating the visual concerns from the data and service concerns, it’s much easier for a development team to pursue service workers for a PWA experience for low bandwidth or offline customers. Since the deploy is only targeting front-end assets and they’re served from an edge-CDN, performance has already been accounted for by previous effort.

Conclusion

In this post I've declared a rough design for setting up a front-end web application serverlessly and detailed what technology would be used for each aspect. In later posts of this series, I'll outline API and Data considerations.

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.

Introduction to Building Serverlessly

David J. Felix 🔮 — Mon, 16 Dec 2019 17:23:28 +0000

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.