On our blog, we've already served you a couple of posts regarding Serverless architecture. So far, we have only discussed technical topics and the patterns/principles of serverless. Today I'd like to drop a few words about the managerial perspective and how being serverless affects everyday life in the company.

Introduction

If you have seen any of our recent articles, you might know we're using almost the entire serverless ecosystem provided by Amazon Web Services. On top of that, we are using our own JavaScript / TypeScript powered set of tools/libraries, called Purple Stack, that helps us with routine development tasks. This approach brings us many apparent benefits, but there are also a few points to consider if you are thinking of adopting serverless on your project or in your organization.

When building software products on a serverless ecosystem, the overall process is different from traditional software development. For example, your software is no longer a monolithic app with a complex OOP structure nor a fleet of microservices as it usually is. Instead, your app is now a list of independent functions that accept specific data and give you an output. Furthermore, these functions are triggered in different ways, for example, by the HTTP request, messaging queue, or other functions. As you might imagine, this has significant implications on the software architecture that is usually "flat" and less complex.

Why are we talking about software architecture? Conway's law says that the structure of any software-producing organization tends to follow the technical design of their products (and vice versa). In traditional software companies, it is not uncommon to see infrastructure/backend/frontend teams keep within their social circles even though they work on the same product. Using a serverless stack affects team structure and dynamics too. By using serverless, you're skipping multiple technical layers at the same time. Typically, you don't need any infrastructure specialists/ architects. As we're using TypeScript all across the stack, it naturally happens that all of our teams are pretty small, secure end-to-end delivery, and consist of full-stack developers.

Truly full-stack teams that work

When talking about full-stack programmers, they might have a preference for either backend or frontend programming. It has shown, over time, that it is not a big issue for a senior backend developer to learn React, at least to a level at which they can connect existing components to backend data sources. At the same time, it is not a big issue for React developers to learn the basics of serverless backend programming. Partly, this is because the structure of the serverless backend is not very complicated and local tooling for BE and FE are almost identical, in our case. Nevertheless, of course, team leaders need to keep in mind the strengths and weaknesses of their particular members when assigning backend complex refactoring to backend newbies.

Such teams are very flexible, productive and it, by and large, resolves some of the typical problems of multi-layered apps development. For example, frontend developers do not need to wait for the backend developer to finish some API endpoint or data source; a single developer typically edits both the frontend and the backend code. As no need for infrastructure setup (technically, part of the app itself) is needed, even a small team can build and maintain much bigger projects.

Resilience and scalability

Whoever deals with any cloud or physical infrastructure setup knows how hard it is and how much effort it takes to set up everything correctly. You might be a bit skeptical at this point. Are you not? Are you guys letting programmers build your production infrastructure? I asked myself the same questions when I joined Purple; after a couple of months, I admitted that it worked. It is impressive how well it works.

Firstly, we had no single downtime caused by infrastructure failure or improper setup. The serverless infrastructure setup is part of the codebase of the app itself. It is not a typical IaC approach, as we know from Ansible or Terraform world, where you typically maintain separate repo; it defines how your serverless services behave instead. We discourage our developers from running serverless apps locally on their machines, even though it is technically possible (in a way) as their development environment is the same as production, just in a different namespace. Therefore, any failure in the setup gets noticed very quickly and before affecting anything in the production environment.

If you run an online service in a (more) traditional way such as AWS EC2, ECS, or Kubernetes and your traffic might grow in hundreds or thousands of percent, sooner or later, you will need to update/optimize its setup. It might include auto-scaling limitations, networking changes, caches, storage, and so on. It is usually a complex and expensive activity that requires specific skills and knowledge, and there is always some risk that something will go wrong.

With serverless, you need not worry about this. It often happens that serverless apps built as a proof of concept are now handling millions of visitors without any changes in their infrastructure setup. It is one of the primary benefits serverless has. Once you set up your serverless stack, it simply works; you most likely won't need to touch the setup for a very long time.

Economic perspective and vendor lock-in

Comparing the costs of a serverless stack with a traditional cloud or on-premises infrastructure is not easy to quantify. It depends on many factors, and hence there is no simple answer. In most cases, running your product serverless will be cheaper than, for example, EC2. Nevertheless, surprisingly, running a real-world product on AWS Serverless is not drastically cheaper in terms of monthly bills for AWS services. It is mainly because a long list of proprietary AWS services will be needed, with AWS Lambda. You can, of course, use your custom substitutions, but you'll neglect many benefits the AWS ecosystem offers.

It leads us to another topic which is vendor lock-in. As we have already stated that the serverless setup is usually part of your product's codebase, moving away from Amazon's universe is possible, technically. Common standard across vendors, such as Kubernetes, does not exist where you can move your setup between vendors relatively quickly. Tools such as the Serverless Framework give you a particular abstraction layer in the serverless world. However, moving from one mainstream serverless provider to another is not so simple.

The question is whether you need to migrate between providers. In Purple, we knew right from the beginning that once we go forward with AWS serverless, it will be hard to move away from it. Nevertheless, our conscious decision was to go forward in any case because of benefits such as reliability, the pace of work, speed, availability worldwide, and many more just outweighed all the downsides mentioned after having run, for years, in AWS serverless. We see no single reason to leave AWS and move elsewhere. Everything works smoothly. As there is no need to employ any dedicated infrastructure staff, the total operational expenses decrease effectively.

Programmers with solid Serverless skills are rare.

One non-technical aspect needing consideration is the availability of software engineers who can work with the serverless stack in your region. We found out that most of the senior-level backend engineers, who work with Node.js, have just a little experience with AWS Lambda or no experience at all. We don't blame them as serverless is a relatively new technology on the market and not mainstream yet.

On the other hand, we found out that jumping into the serverless world was a matter of 1-2 months, even for someone who had never done it before, especially when surrounded by experienced colleagues who were always there to help.

We have managed to convert this downside into a hiring advantage, in our case. Again, this is because we are one of the very few companies in Central Europe building their online products on state-of-the-art serverless stacks. This message, along with our unique team culture, is communicated to our candidates in Purple. We have even open-sourced our production-ready serverless stack because it gives our candidates a clear idea about what they might expect in our company.

Summary

We had to overcome particular downsides, but building online products using a serverless stack was exciting for the entire engineering staff, a fantastic developer experience, and intangible productivity, which brought some benefits on a non-technical level. Thus, serverless is not another hype that promises to change the world, but it is a functional approach that makes sense from many perspectives. The only significant disadvantage (at the time of writing) is the lack of experienced serverless developers on the market. However, I expect this to change soon, as more and more people are becoming familiar with this exciting way of building software.