I was a frontend for most of my career, and when I wanted to become a fullstack developer, my first thought was, "I gotta learn about the cloud!"
So the cloud became my starting point because why should I bother with how things were done ten years ago?
I learned that AWS is the market leader and even offers some certifications, so I focused on AWS. My idea was when I learned to take those certs; I will get a good insight into the basics along the way.
And it was held valid; I got a good overview of AWS and how to build applications with its services.
But when you are a frontend dev, there are quicker ways to get started.
I would still recommend taking the certs in the long run, but they take weeks to prepare, even with adequate learning resources and cover stuff you will probably never use when starting with cloud-native technology.
Sure it's nice to know about the in's and out's of EC2, but as a frontend dev, you're better off to go "cloud-native" right from the start.
What Does "Cloud-Native" Mean?
I saw some parallels with the cloud and veganism.
If people stop eating meat products, they usually try to do 1:1 replacements for meat-based dishes. They do these dishes as they would typically do, leave the meat products away and try to get the same result with plant or fungi based ingredients.
This certainly works to some extent, and the meat replacement industry gets better every day, but it misses out on the possibility of doing dishes that don't include meat right when they were created.
Same with the cloud. Companies used servers or VMs and building monoliths, so cloud providers had to offer them the technology they could use as a drop-in replacement.
Devs started to install their SQL databases and monolithic app servers on those cloud VMs and saved a bit of money because they didn't have to all the maintenance anymore.
But there is more to get if they embrace cloud-native technology instead of merely VMs.
So what is this cloud-native tech?
It's technology made specifically to run in cloud environments.
Cloud-native tech should scale horizontally instead of vertically like a monolith usually does.
Cloud-native tech should be as "on-demand" priced as possible. Renting for one month could be cheaper than buying a server, but renting for one hour could be less expensive than renting for a month. Paying for a function execution could be less expensive than renting a whole VM for an hour.
Cloud-native tech should be easy to set up and maintain. After all, if you run a VM, you still have to install security patches, etc.
There are many more points, but I think these are the most important ones.
The problem with this cloud-native approach is, you lose some flexibility.
You can install all of your software "as is" on a VM, but you can't do this with a Lambda function. You also can't use an S3 bucket to store your SQL database files.
What Does that Mean for Fullstack Development?
The VM based approach is the more classical one that got the most learning resources on the web. The one created for people who know SQL databases, people who know load balancers and web servers.
But it's also the much harder one to start when you come from the frontend.
When you come from frontend development, you have to learn new technology anyway, so why not get an edge on all the people out there who do things "the old way" and embrace the cloud?
No paying for servers you don't use, installing OS updates or security patches, no sharding of SQL databases, and no horizontal scaling issues. All out-of-the-box.
The Serverless Cloud
In today's cloud jargon, "serverless" is the word that describes cloud-native technologies that are cloud provider-specific, but also give you the best developer experience on a specific cloud provider.
Google Firebase allows you to build fullstack applications in the Google cloud by using most of your frontend skills. It locks you into their eco-system, but you also save much time and (maintenance) money using it.
In comparison, Kubernetes (K8s) isn't cloud provider-specific while still trying to be cloud-native, just native to all the clouds.
K8s allows you to build fullstack applications in every cloud, but you won't get too far with just your frontend skills. It opens you up to every cloud, but you have to pour more time in setup and maintenance.
Shortest Path from Frontend to Fullstack
Learn serverless technology.
The different cloud providers all offer some serverless technology that helps you to get up and running quickly.
My personal favorite is AWS Amplify because I like the AWS cloud, and I think it follows the right approach. In contrast to Google Firebase, it's not an entirely new service. While it comes with a deployment service that certainly helps with the heavy lifting, it mostly leverages command-line tools that ease working with existing AWS services. This brings you the full power of AWS, and it's not much harder than using the Rails CLI.
But there are many other serverless technologies from AWS and other providers that help you get up and running.
AWS also has the CDK, an "Infrastructure as Code" framework that allows you to define your cloud infra with JavaScript and TypeScript, among other languages. This relieves you from learning yet another programming language to get started.
As I mentioned, Google has the Firebase eco-system, I haven't used it, but it seems to be a solid, albeit rather distinctive, foundation to get started.
Azure has a new service called Static Web Apps in preview, that promises "streamlined full-stack development from source code to high global availability."
Cloudflare offers the Cloudflare Workers eco-system. All edge-deployed (low-latency) functions as a service and key-value store for static websites with a dynamic touch.
Netlify resides at one level above the big cloud providers. They try to build the missing parts between the "core cloud-native services" and the frontend, so you don't have to worry about them.
FaunaDB is a database as a service. It can be used from every device that has an internet connection and allows for global replication. While not a fully-fledged serverless offering with all bells and whistles, it solves one of the biggest problems you get when going fullstack, deploying a reliable database.
Auth0 is the big authentication player out there. They also offer (small) function as a service and storage capabilities; they can't do everything you need but could be enough for your use-cases.
Want to go Full Stack? Go Serverless!
There are many serverless technologies out there that help on the way to becoming a fullstack developer. Some even allowed to get a fully-fledged app deployed within minutes.
But don't let that fool you; these are just the first steps you will take on your way to become a prolific fullstack developer.
If you want to go deeper, I would recommend reading the "Well-Architected" documents by AWS (especially their serverless lense (pdf), Azure, and GCP. They touch all the essential points a fullstack application has to consider and show solutions regarding the services a specific cloud provider offers.
How to secure your app? How to do continuous delivery? These documents got you covered.
Top comments (11)
Thank you for the great article. Very informative! I am a complete newbie on this serverless topic. Just some curious questions - where do AWS Lambda and Google Cloud Function sit in this picture? They are a part of Amplify and Firebase respectively but allow us to actually define some code that gets executed on server side? or should they be considered as separate service offerings? Is it a correct understanding that Firebase (/Amplify) won't allow us to define any of our code in backend (beyond providing us a means to access the database) and that's where Google Clound Function (/Lambda) differ?
Glad you like it!
Amplify as a service only consists of a mobile UI testing/snapshot service and a deployment service. Otherwise Amplify uses existing AWS services.
AWS Lambda and Google Cloud Functions are "Function as a Service" products/offerings, same goes for Azure Functions and Cloudflare Workers.
Lambda is part of Amplify in the sense that Amplify uses Lambda to do some things. For example, you can use Lambda to return some calculation from an API endpoint.
Firebase is a bit more self-contained and comes with more of its "own" serivces, but it integrates well with existing Google Cloud infrastructure. For example, there is a service called Cloud Functions for Firebase that lets you write "server side code" that gets executed when Firebase events happen.
Thank you
I'm going FullStack... but still sudying. At the moment I can't see why I should learn serverless first, because of job's market. SQL is still a must to use, with a framework like Laravel.
In future, serverless will be a super fun stuff to learn. Not only it's fast, but the AWS and Google UI to their servers, are super cool and easy to understand.
Nice article.
Keep your eyes on a goal, check what job you want and learn for that if getting employed is your main focus.
I wish you all the best!
Thank you for all the great information. I am thinking about AWS certs
They are really good to find your way around. If you plan to go all in on AWS, do them!
Thank you
Maybe I can pick your brain sometime
Interesting article AWS is an area I need to improve in.
Cool article, I'm in the reverse camp, coming from a cloud background and backend development to figuring out how frontend works. For me, the frontend is way more challenging.
Yes, understandable.
I it seems so harmless at first sight, but so many things that make it complicated, haha.