Full-Stack Development in the Era of Serverless Computing
How serverless technologies are changing what it means to be a full-stack developer.
In the past, front-end developers and front-end development was not viewed as equally important or complex as back-end development. This has changed.
Front-end development is now being taken much more seriously. If you are a front-end developer, it is now likely that you are not only in demand as much as your back-end peers, you may even be more sought after depending on your specialty.
While the back end has jumped forward in automation and ease over the past 10 years, the front end has actually started getting harder as complexity was shifted to the client space.
Because of the rise of SPAs, more complex data concerns, multiple device targets and increased expectations of user experience, client-side development has gotten more complex over the past decade or so
We are entering an era where the front end is becoming increasingly more important. Front-end developers are now shipping robust full-stack applications using almost zero back end code.
As technology progresses, abstractions get better. As you are about to see, being a front-end developer no longer limits you to only building the front-end of your application. Let me explain.
One of these is not like the others.
Let’s take a look at how computing has evolved over the past few decades.
On Premise
In the past, you had to have racks of collocated servers to run your applications that were either on premise or in a data center. If anything broke, you had to physically go to the location of the datacenter and repair on the spot or replace with a new server. This was typically difficult and burdensome to maintain.
Cloud
When cloud computing was introduced, companies and developers began moving their workloads into the cloud and letting their cloud provider of choice handle maintaining the infrastructure.
These workloads still usually run on servers which you had to patch, update, and maintain uptime. Scaling is still left up to the developer or team maintaining the server.
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.
My Name is Nader Dabit .
I am a Developer Advocate at AWS Mobile working with projects like AWS AppSync and AWS Amplify. I’m also the author of React Native in Action, & the editor of React Native Training & OpenGraphQL.
