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.
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.
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.
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.
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.
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.
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.