The course is part of this learning path
This course touches on the similarities and differences between AWS, GCP, and Azure serverless functions. The idea is to give you insight into what using the different offerings look like. The primary learning objective is to help you make an informed decision about which provider to use and if it fits your use case. The 30-minute course covers the three different providers (content largely taken from the comparing cloud platforms course--but cut down for content), deploying a sample application on each, and the ecosystem around deploying serverless applications. The provider lesson uses the same application and demonstrate deploying and other operational characteristics of each provider.
- IT Pros
If you are not already familiar with serverless start with "Getting Started with Serverless Computing” before continuing with this course. You’ll also need some experience with cloud providers as well. Nothing specific is required, though you should have a general idea of how cloud computing works.
- Understand the state of serverless in 2017 List trade-offs between AWS, Google, and Microsoft platforms
- Learn to build, deploy, and run applications on the three platforms
- Learn open source tools for building serverless applications
This Course Includes
30 minutes of high-definition video.
What You'll Learn
Course Intro: What to expect from this course.
Serverless Overview: In this lesson, we’ll introduce you to the key players and prepare you for the hands-on demos in the following lessons.
AWS Lambda: In this lesson, you’ll learn about serverless on Lambda and deploy a Lambda function.
Azure Functions: In this lesson, we’ll discuss serverless Azure functions and learn how to deploy an HTTP function.
Google Cloud Functions: In this lesson, you’ll learn about serverless on Google Cloud and deploy an HTTP trigger function.
Ecosystems and Tools: In this lesson, you’ll learn about serverless framework and Apex.
Conclusion: A summary and review of what you have learned.
Hello, and welcome back to the Serverless Survey course. I'm Adam Hawkins, and I'm an instructor for this lesson. We're talking about two frameworks the ecosystem provides, Serverless and Apex. Our objectives for this lesson are to learn why to use such a tool and to get a feel for each with a short demo. First up, why use a framework? These tools aim to make working with applications easier. Or in other words, they aim to make building and deploying multiple function applications easier. They tend to manage creation, updating, deploying, permissions, and even resources like an F3 bucket. Another benefit is abstracting away the provider. You can write code that's portable between AWS or Azure, for example. Expect to use tools similar to the ones we're covering in this lesson.
Let's start with the Serverless framework. The Serverless framework is a one-stop shop for all of your Serverless needs. It was initially built to improve the workflow around AWF lender functions. Since then, it's grown to support Azure functions and IBM Open It's a full feature toll in that is covers pretty much everything you'll need for service applications. Itconfiguration like environment variables and includes an extendable plug-in system. The team is developing an entirely new Serverless beta platform, as well.
Let's get a feel with a short demo. The Serverless CLI is an MPM package. I've already installed it, so I'm ready to go. Here I'll create a new project from an existing HTTP and Node.js template. This create the project directory with the Serverless ML file and the hello world function. The ML file declares the the functions, triggers, resources and other information related to the project. We can apply this project right away. I've already configured my credentials. You'll need to do that if you haven't already. After it's deployed, invoked a function to test it out. Cool, looks like it's working.
Let's update the code to remove the input event, redeploy and test it. We can also add HTTP integration pretty quick. Open up the service.wmo file and add an HTTP trigger to the function. Here, I'm exposing the function via get to /hello. You can configure many more complex mappings. Refer to the event documentation for more information. Deploy the application again, and the Serverless framework will print out the API gateway URL. We can hit that with curl to test it out.
Pretty quick and easy, right? One last thing. Serverless supports multiple stages or environments. Let's update our function to return a stage environment variable. Then we'll update the serverless.yml configuration file to set the stage environment variable. Here, the value references the default stage or the option to write it on the CLI. This is a Serverless-specific template value. Refer to the documentation for more information on these things. Now deploy the application and test it out. Deploy again with --stage production and test it out. Looks like everything's working. That was easy enough.
There's still much, much more you can do with the Serverless framework. Check out the documentation for more information on providers, events and infrastructure resources. That's it for Serverless. Time to talk about Apex. Apex is different than Serverless. They both support deploying applications with multiple functions, stage and runtime configurations. The difference here is that Apex only supports AWS lender functions and supports alternative runtimes through shims. Apex allows you to write functions in Clojure, Golang and Rust. Notably, Apex does not handle the API gateway LM integration, so you'll need to own that one yourself. Plus Apex fits non-HTTP applications the best.
Let's get a feel with a short demo. Apex is written in goals, so you can drop the provided binary anywhere on your path. They provide a inflation script to do this for you. I've already installed it, so we can get going. Create a new directory for the project, and then run Apex in it. This creates a simple hello world application with boilerplate configuration files. There are configuration files for the project and individual functions for things like runtime, compute resources, and environment variables. These may also be overwritten in different environments. Apex creates a simple directory structure as shown with the tree command. There are configuration files and directories for each function.
The generated function logs the events and returns a hello world message. Now we can deploy the project and invoke the function to test it out. Looks like everything's working. Now let's rework the demo to support multiple environments. Let's start up by changing the project name, a default app environment variable in the project.json. Next, update the function to use the new environment variable. Deploy the project and test it out. Now create the production configuration file. I'll copy over the existing project.json file. There's no fallbacks here. It's running a completely new project configuration. Change the name and change Apex environment. Now deploy with -e production and invoke the function to test it out. And look at that, we get production right back.
Apex also includes commands to stream logs and get metrics. That concludes our short demo. Refer to the documentation for more information. This concludes our short demo of Serverless frameworks. However, this is not an exhaustive list. Open up Google and you'll find plenty. Odds are they tend to fill the same niche, perhaps be written in different languages and aimed to improve the Serverless application workflow. My recommendation is for you to start with Serverless if you want a full feature tool. Go with Apex if you like it more lean and mean or want Golang, Clojure or Rest. That's it for this lesson. The next lesson completes the course. See you there.
About the Author
Adam is backend/service engineer turned deployment and infrastructure engineer. His passion is building rock solid services and equally powerful deployment pipelines. He has been working with Docker for years and leads the SRE team at Saltside. Outside of work he's a traveller, beach bum, and trance addict.