A few weeks ago Google announced a lot of promising technological developments at Google Cloud Next ’18 in San Francisco. Google Cloud Next is a two-day conference to learn about the latest (Google) cloud technologies and how the industry is adapting, innovating, and growing with the cloud. It includes talks, labs, and bootcamps. One of those interesting announcements concerned Cloud Functions, which directly compete with services like , , and . Google first announced Cloud Functions back in 2016 and is now generally available with support for additional programming languages (Node.js 6 & 8 and Python 3.7). More info about this announcement can be found . AWS Lambda Azure Functions IBM Cloud Functions here But what is a Google Cloud Function exactly? A Google Cloud Function is what we call a Function-as-a-Service (FaaS). Does this mean that you now run code without servers? Not exactly, computing still requires servers. What serverless really means is that as a developer, you can write and deploy code without the hassle of managing the underlying infrastructure. FaaS is family of the serverless computing category. serverless Instead of running an over-provisioned server infrastructure, you’re just running a piece of code or function. The serverless computing service takes your functions as input, performs logic, returns your output, and then shuts down. And as such, you are only billed for the resources used during the execution of those functions. **Event-driven**Runs code in response to events. Scales automatically without hassle. Scalable Cloud Functions don’t hold any in-memory state. Stateless No worries about provisioning and maintaining servers. No management **Short lifespan**Cloud Function execution time is limited. FaaS is a real technology, it completely abstracts away servers. NoOps FaaS use cases Cloud Functions are very well suited to build event-driven architectures. They can react to events like file changes in your storage, messages in your queue, or any HTTP request really. Here are some examples of what you can do with these Cloud Functions: The modular and scalable nature of Cloud Functions makes them ideal for implementing pieces of logic in a microservice based architecture. Each function can be independently deployed and managed. Microservices **Data processing**A Cloud Function can execute your code in response to changes in data. Like generating a thumbnail after an image was uploaded to a storage bucket or processing of incoming logs. **Internet of Things**IoT devices generate data that needs to be ingested and processed. With Cloud Functions, you can process real-time data as it comes in, analyze that data to gain insights and get notifications for special conditions. **Video and image analysis**You can easily combine a FaaS with other services. With the Google Cloud Video Intelligence API and the Cloud Vision API we can extract relevant semantic information from videos and images. A company can automate their GitHub workflows by listening to webhook events. For example every time an issue is created on GitHub you could post the issue details to Slack just by triggering a Cloud Function. Extending SaaS applications The cool thing is that you can create endless solutions with Cloud Functions and perfectly combine them with hybrid-cloud solutions. The real benefits It’s very easy to run your code in the cloud, you can completely focus on writing code and forget about the server management hassle. No servers to manage With one command you are able to deploy a Cloud Function to a production ready environment. Easy to deploy No scaling management needed, Cloud Functions automatically scale your application. The function’s code runs in parallel and only processes the incoming triggers. Auto scaling It’s very transparent towards cost, you only pay when your code runs. It can be a real cost saver over a pre-provisioned cloud virtual machine. Pay-per-use Just like wireless internet has wires somewhere, serverless architectures still have servers somewhere. serverless.com The drawbacks **Architectural complexity**Cloud Functions can add extra complexity to your project, making the complete architecture somewhat harder to understand. **Debugging**There are a lot of tools out there like emulators and cloud monitoring tools to debug Cloud Functions. But overall, they can still be hard to debug, you have to trust whatever tools the cloud providers are offering. **Vendor lock-in**Functions run anywhere but getting them to run and connect to other services depends per provider, you have to play by their rules. **Can be daunting to control**It’s not trivial to keep track of all your deployed Cloud Functions. You will need to sync monitoring, analytics and deployment scripts with your existing system. Final thoughts Are Cloud Functions going to take over the world? Should we only write Cloud Functions from now on? Personally, I think they are pretty damn awesome, it’s another step forward to embrace the true power of cloud-native components. My prediction is that in the next couple of years we will see a greater shift towards serverless and Function-as-a-Service. Serverless really helps a development team to focus on their code instead of worrying about their infrastructure that needs to be provisioned, maintained and scaled. Of course, you shouldn’t replace every traditional architecture with Cloud Functions and there will always be arguments for not implementing them. It really helps to start from a microservice mindset before implementing Cloud Functions in your current system. In short, the future is serverless, but it will take some time to shift our way of thinking. 🤟 Originally published at inthepocket.com .
