loading...

The Full Stack Serverless Manifesto

dabit3 profile image Nader Dabit ・4 min read

Full Stack Serverless applications incorporate the following three characteristics:

  1. Decoupled frontends
  2. Infrastructure as code
  3. Serverless technologies for maximum scalability with minimum devops

By combining Serverless technologies with end to end full stack architectures, developers are able to pick up, replicate, deploy to the cloud, and iterate on sophisticated scalable cloud applications in a way that, in the past, was not possible to do or accessible for the majority of developers.

Because many Serverless technologies like AWS Amplify, CDK, and the Serverless Framework (among others) are lowering the barrier to entry in building cloud applications with IAC (Infrastructure as Code), there is a new generation of traditionally front-end developers that can use their existing web and mobile skillset to build the types of applications that were traditionally out of their reach.

When I say use their existing skillset, I'm assuming that the typical front end or full stack developer is familiar with the following:

  1. JavaScript, TypeScript, or Python
  2. Interacting with a CLI
  3. A basic understanding of interacting with RESTful and / or GraphQL APIS

Full Stack Serverlesss applications can be shared and deployed as an end to end project without much concern about the developer's local environment because all of the infrastructure is running in the cloud. They can be put down, shared, iterated on, and picked back up with ease.

Back end infrastructure can be created and destroyed within only a few minutes enabling developers to not have to worry about incurring much development cost. Because the services are Serverless, whatever development costs incurred will be low anyway.

Why Serverless

Full Stack Serverless relies heavily on the Serverless philosophy for building out back end functionality. This means that the following are taken into consideration:

  1. Developer velocity is valued above service ownership
  2. Focus on creating business value vs re-inventing the wheel
  3. Total cost of ownership should be understood at a fundamental level (Pay per compute -> variable vs capital expense)
  4. Code is a liability
  5. If it's available as a service, then it should never be built from scratch
  6. Serverless functions fill in the gaps that managed services do not cover

Research also suggests that cloud computing is becoming more and more Serverless, meaning that Serverless is more future-proof than Serverful.

In Cloud Programming Simplified: A Berkeley View on Serverless Computing, the predictions for the future of cloud computing were this:

  • We expect new BaaS storage services to be created that expand the types of applications that run well on Serverless computing. Such storage will match the performance of local block storage and come in ephemeral and durable variants. We will see much more heterogeneity of computer hardware for Serverless computing than the conventional x86 microprocessor that powers it today.
  • We expect Serverless computing to become simpler to program securely than Serverful computing, benefiting from the high level of programming abstraction and the fine-grained isolation of cloud functions.
  • We see no fundamental reason why the cost of Serverless computing should be higher than that of Serverful computing, so we predict that billing models will evolve so that almost any application, running at almost any scale, will cost no more and perhaps much less with Serverless computing.
  • The future of Serverful computing will be to facilitate BaaS. Applications that prove to be difficult to write on top of Serverless computing, such as OLTP databases or communication primitives such as queues, will likely be offered as part of a richer set of services from all cloud providers.
  • While Serverful cloud computing won’t disappear, the relative importance of that portion of the cloud will decline as Serverless computing overcomes its current limitations.
  • Serverless computing will become the default computing paradigm of the Cloud Era, largely replacing Serverful computing and thereby bringing closure to the Client-Server Era.

In the above paper they redefined the term Serverless to be this:

Put simply, Serverless computing = FaaS + BaaS.

The definition of Serverless is no longer only Functions as a service, but now also encompasses backends as a service (Baas). You will also often see Serverless discussed more as a philosophy, strategy, or a spectrum where the end goal is to be "Serverless" vs a black and white description of what Serverless means or is.

In addition to the traditional advantages of Serverless technologies, there is another main reason why Serverless technologies are preferred over Serverful:

Lower barrier to entry for traditionally non-back-end developers

Because developers are leveraging managed services for functionality like authentication and databases and not having to manage infrastructure, it is a lower barrier to entry for new developers than traditional Serverful cloud computing.

For more of my previous thoughts on what Full Stack Serverless means and represents, check out my early 2019 post titled Full-Stack Development in the Era of Serverless Computing

Discussion

pic
Editor guide
Collapse
ibrahimcesar profile image
Ibrahim Cesar

Just read your book and I share the same principles. This manifesto is under a creative commons license or copyrighted? Asking because if open, I want to translate to Brazilian Portuguese

Collapse
zilti profile image
Daniel Ziltener

"Full Stack Serverlesss applications can be shared and deployed as an end to end project without much concern about the developer's local environment because all of the infrastructure is running in the cloud"

So, just like when using a local VM, e.g. a Vagrantbox

"We expect Serverless computing to become simpler to program securely than Serverful computing"

It won't be, because it is just a program running on an OS. It doesn't matter if you put a Dockerfile around it and call it "Serverless". There's still just as much Server there as otherwise. If you're a horribly bad programmer who knows nothing about the most basic security things, Docker won't help you.

"We see no fundamental reason why the cost of Serverless computing should be higher than that of Serverful computing"

Because it is a waste of resources and has a ton of overhead.

Collapse
ibrahimcesar profile image
Ibrahim Cesar

"So, just like when using a local VM, e.g. a Vagrantbox"

I don't think this an accurate representation. A VM or a container works with many dependencies that still needs to be maintained by the dev team, e.g., OS of choice, tweaks in ports, custom environments likes timezones etc; A Lambda, per example, you just need to choose a runtime target, a memory size and you are done besides of course the lib dependencies of your code. You even don't need provision the Vagrant config that in the real world in my experience is really messy sometimes with developers getting problems on their own VMs.

"There's still just as much Server there as otherwise. "

For sure. But in this model you don't have the overhead to manage, patch and so on. Serverless naming is somewhat misleading. In reality, as I see, is just an abstraction for the infrastructure. For small teams, per example, is not practical create a CI/CD pipeline. You just don't have time or even someone with all the know how to build, and the most important, maintain. Some of the serverless managed services provided this out of the box. I'm not trying to convince you otherwise of your choices and as Mark Richards and Neal Ford put in "Fundamentals of Software Architecture: An Engineering Approach", "Everything in software architecture is a trade-off", adding that if someone doesn't seem a trade off in a decision is because it just not found it yet. So, for sure there are trade off and some teams and individuals will likely run bare metal and manage all the things, but I wouldn't dismiss so bluntly a very large set of offerings and possibilities developers can leverage with the serverless ecosysteam.

Collapse
zilti profile image
Info Comment marked as low quality/non-constructive by the community. View code of conduct
Daniel Ziltener

"You even don't need provision the Vagrant config that in the real world in my experience is really messy sometimes with developers getting problems on their own VMs."

In our company we just use a bogstandard Vagrantbox from app.vagrantup.com (OpenSUSE Leap 15.2 to be exact; we just had to switch unfortunately from FreeBSD because a tool we need doesn't run on it) and use the same Ansible file to provision it as we use for the live servers. This means we get to provision the dev box, the staging server and the live server all with the same config, despite them using different platforms (VirtualBox, Google Compute Engine). (I can even deploy the entire "server landscape" consisting of build1, build2, feature1, feature2, staging, live, plus the postgresql server, with just one Ansible command ;) )

What are potential problems you've run into with that? Genuinely curious, maybe we have something to look out for.

What we do use, though, is a hosted PostgreSQL server, to see how it'll work. So far it's doing fine, the downside being we don't get to decide when e.g. it gets updated.

"But in this model you don't have the overhead to manage, patch and so on."

idk, running sudo zypper up isn't much of an overhead - and in the worst case, you just destroy and redeploy the server :)

Running sudo zypper up is basically the tradeoff to being able to decide what exactly the software stack we want to use looks like. E.g. there's no OpenSUSE Leap 15.2 available on Google Cloud.

"For small teams, per example, is not practical create a CI/CD pipeline. You just don't have time or even someone with all the know how to build, and the most important, maintain."

I know, gatekeeping and all, but... I wouldn't hire a developer who's too incompetent to write a simple CI/CD pipeline for e.g. GitLab CI (after all, a dev should be capable of doing DevOps aka SCCM). It took me all of 30 minutes to write the script that compiles our product, runs the tests, scps it over to the server and restarts the service there using systemctl. And in the end, a Dockerfile is nothing but yet another CI pipeline to maintain.

Who knows, maybe I am totally out of the loop. Or maybe I am oldfashioned for thinking that a good dev should know a bit about the system / platform in use. But that's my view on it all; we are getting way too abstracted, and our projects and tools more and more sit atop a shaky, badly-maintained pile of not always suitable other tools.

Thread Thread
ibrahimcesar profile image
Ibrahim Cesar

Well thanks for say in a polite way I and my co-workers are incompetent.

I think we have very different visions of is a CI/CD pipeline, and ways to treat people.