Editor’s note: Today’s post comes from Rustem Feyzkhanov, a machine learning engineer at Instrumental. Rustem describes how Cloud Functions can be used as inference for deep learning models trained on TensorFlow 2.0, the advantages and disadvantages of using this approach, and how it is different from other ways of deploying the model.
TensorFlow is an established framework for training and inference of deep learning models. Recent updates to version 2.0 offer a number of enhancements, including significant changes to eager execution. But one of the challenges with this new framework is deploying TensorFlow 2.0 deep learning models. Google Cloud Functions offer a convenient, scalable and economic way of running inference within Google Cloud infrastructure and allows you to run the most recent version of this framework.
This post will explain how to run inference on Cloud Functions using TensorFlow 2.0.
We’ll explain how to deploy a deep learning inference including:
How to install and deploy Cloud Functions
How to store a model
How to use the Cloud Functions API endpoint
The components of our system
Google Cloud Platform (GCP) provides multiple ways for deploying inference in the cloud. Let’s compare the following methods for deploying the model:
Compute Engine cluster with TF serving
Cloud AI Platform Predictions
Cloud Functions
TensorFlow Serving Typically you might use a cluster as inference for the model. In this case, TF servingwould be a great way to organize inference on one or more VMs —then, all you need to do is add a load balancer on top of the cluster. You can use the following products to deploy TF serving in AI Platform:
Great response time as the model will be loaded in the memory
Economy of scale, meaning cost per run will decrease significantly when you have a lot of requests
AI Platform Predictions AI Platform provides an easy way to serve pre-trained models through AI Platform Predictions. This has many advantages for inference when compared to the cluster approach:
Codeless inference makes getting started easy
Scalable infrastructure
No management of infrastructure required
Separate storage for the model, which is very convenient for tracking versions of the model and for comparing their performance
Note: You can use Cloud Functions in combination with AI Platform Predictions (you can learn more in this post).
Cloud Functions When comparing Deep Learning VMs and AI Platform Predictions, the full serverless approach provides the following advantages:
Simple code for implementing the inference, which at the same time allows you to implement custom logic.
Great scalability, which allows you to scale from 0 to 10k almost immediately
Cost structure which allows you only to pay for runs, meaning you don’t pay for idle servers.
Ability to use custom versions of different frameworks (Tensorflow 2.0 or PyTorch)
In summary, please take a look at this table:
Since Google Cloud also provides some free invocations of Cloud Functions per month, this kind of setup would be perfect for a pet project or for a start-up that wants to get early customer feedback on a prototype. Also, it would be useful in cases where you have to process peak loads. The downside would be that in cases where the model is too big, the cold start could take some time and it would be very hard to achieve real-time performance. Also we need to keep in mind that serverless infrastructure doesn’t provide economy of scale, meaning the price of an individual run won’t go down when you have a large number of requests, so in these types of cases, it may be cheaper to use a cluster with TF serving as inference.
As we can see, Compute Engine pricing per hour looks extremely attractive (with utilizing preemptible instances or commitment use, the price will be even lower), but the catch here is that cost of instance is per one second, with a minimum of one minute. Cloud Functions, on the other hand, have billing per 100ms without a minimum time period. This means Cloud Functions are great for short, inconsistent jobs, but if you need to handle a long, consistent stream of jobs, Compute Engine might be a better choice.
Architecture Overview
Our system will be pretty simple. We will train the model locally and then upload it to Google Cloud. Cloud Functions will be invoked through an API request and will a download model and a test image from Cloud Storage.
There are several things to consider when you design a system to use serverless infrastructure as an inference.
First of all, keep in mind differences between cold invocation, when the function needs time to download and initialize the model, and warm invocation, when function uses a cached model. Increasing the ratio of warm invocations to cold invocations not only allows you to increase processing speed, it also decreases the cost of your inference. There are multiple ways you can increase the ratio. One way could be warming up functions so they will be warm when a high load comes in. Another way is to use Pub/Sub to normalize a load so that it will be processed by warm containers.
Secondly, you can use batching to optimize the cost and speed of processing. Because a model can run on the whole batch instead of running separately on each image, batching allows you to decrease the difference between cold and warm invocation and improve overall speed.
Finally, you can have some part of your model saved as part of your libraries. This allows you to save time downloading the model during cold invocation. You could also try to divide the model into layers and chain them together on separate functions. In this case, each function will send an intermediate activation layer down the chain and neither of the functions would need to download the model.
Cost In the demo which we will deploy we use 2GB Cloud Function. Cold invocation takes 3.5s and warn invocation takes 0.5s. In terms of pricing we get 0.0001019$ per cold invocation and 0.0000149$ per warm invocation. It means that for 1$ we get ~10k cold invocations and ~65k warm invocations. With free tier provided by Google Cloud you would get for free ~20k cold invocations and ~140k warm invocations per month. Feel free to check the pricing for your use cases using pricing calculator.
TensorFlow 2.0 example
First, let’s install Tensorflow 2.0 beta on your computer. You can install it either on your system python or by creating a virtual environment:
Let’s use fashion MNIST with TensorFlow 2.0b as an example. Here is how the code for training and exporting model weights would look like:
We will need to store the model separately from the code as there is a limit on local file size on the Cloud Functions. You can upload them to the Cloud Storage bucket along with the test image.
Cloud Functions
One of the main upsides of Cloud Functions is that you don’t have to manually generate the package. You can just use a requirements.txt file and list all used libraries there. Also, remember to have the model as a global variable in your python code so it will be cached and reused in warm invocations of Cloud Functions.
Therefore we will have two files:
requirements.txt
and main.py
Deployment through the command line
You can easily deploy and run Cloud Functions using gcloud.
The response would be:
Deployment through the web console
First, let’s start from the Cloud Functions dashboard. To create a new Cloud Function, choose the “Create function” button. In the “Create function” window, set the function’s name (“tensorflow2demo”), allocated memory (2 GB in our case for the best performance), trigger (HTTP trigger in our case) and runtime (python 3.7).
Next, set the main.py and requirements.txt files. You can just copy the code and libraries from the files at the repo. Finally, w push the “Create” button and initialize the creation of the function.
Once the function is deployed, you can test it in the “Testing” section of theCloud Functions dashboard. You can also customize incoming events and see output as well as logs.
As you can see, our pretrained model successfully classified image as trousers. If we run the functions one more time, we will see that it will run a lot faster because we saved the model to the cache and won’t need to reload it during warm invocation.
Conclusion
With this post, you should now be able to create a TensorFlow 2.0 endpoint on GCloud Functions. Setting the project up is easy, and can save a lot of time when compared to the traditional approach of using a cluster of VMs. As you can see, Cloud Functions provide an easy way to start with contemporary frameworks and deploy pre-trained models in a matter of minutes.
As a hobby, I port a lot of libraries to make the serverless friendly. Feel free to check my repos with other examples like headless chrome or pandas with numpy on Cloud Functions. They all have an MIT license, so feel free to modify and use them for your project.
Learn more about Cloud Functions here, and consider starting a free trial.
Acknowledgements: Gonzalo Gasca Meza, Developer Programs Engineer contributed to this post.
The emergence of the cloud and the edge as the new frontiers for computing is an exciting direction—data is now dispersed within and beyond the enterprise, on-premises, in the cloud, and at the edge. We must enable intelligent analysis, transactions, and responsible governance for data everywhere, from creation through to deletion (through the entire lifecycle of ingestion, updates, exploration, data prep, analysis, serving, and archival).
Our commitment to innovation is reflected in our unique collaborative approach to product development. Product teams work in synergy with research and advanced development groups, including Cloud Information Services Lab, Gray Systems Lab, and Microsoft Research, to push boundaries, explore novel concepts and challenge hypotheses.
The Azure Data team continues to lead the way in on-premises and cloud-based database management. SQL Server has been identified as the top DBMS by Gartner for four consecutive years. Our aim is to re-think and redefine data management by developing optimal ways to capture, store and analyze data.
I’m especially excited that this year we have three teams presenting their work: “Socrates: The New SQL Server in the Cloud,” “Automatically Indexing Millions of Databases in Microsoft Azure SQL Database,” and the Gray Systems Lab research team’s “Event Trend Aggregation Under Rich Event Matching Semantics.”
The Socrates paper describes the foundations of Azure SQL Database Hyperscale, a revolutionary new cloud-native solution purpose-built to address common cloud scalability limits. It enables existing applications to elastically scale without fixed limits without the need to rearchitect applications, and with storage up to 100TB.
Its highly scalable storage architecture enables a database to expand on demand, eliminating the need to pre-provision storage resources, providing flexibility to optimize performance for workloads. The downtime to restore a database or to scale up or down is no longer tied to the volume of data in the database and database point-in-time restores are very fast, typically in minutes rather than hours or even days. With read-intensive workloads, Hyperscale provides rapid scale-out by provisioning additional read replicas instantaneously without any data copy needed.
Azure SQL Database also introduced a new serverless compute option: Azure SQL Database serverless. Serverless allows compute and memory to scale independently and on-demand based on the workload requirements. Compute is automatically paused and resumed, eliminating the requirements of managing capacity and reducing cost, and is an efficient option for applications with unpredictable or intermittent compute requirements.
Index management is a challenging task even for expert human administrators. The ability to create efficiencies and fully automate the process is of critical significance to business, as discussed in the Data team’s presentation on the auto-indexing feature in Azure SQLDatabase.
This, coupled with the identification of how to achieve optimal query performance for complex real-world applications, underpins the auto-indexing feature.
The auto-indexing feature is generally available and generates index recommendations for every database in Azure SQL Database. If the customer chooses, it can automatically implement index changes on their behalf and validate these index changes to ensure that performance improves. This feature has already significantly improved the performance of hundreds of thousands of databases.
Discover the benefits of the auto-tuning feature in Azure SQL Database.
In the world of streaming systems, the key challenges are supporting rich event matching semantics (e.g. Kleene patterns to capture event sequences of arbitrary lengths), and scalability (i.e. controlling memory pressure and latency at very high event throughputs).
The advanced research team focused on supporting this class of queries at a very high scale and compiled their findings in Event Trend Aggregation Under Rich Event Matching Semantics. The key intuition is to incrementally maintain the coarsest grained aggregates that can support a given query semantics, enabling control of memory pressure and attainment of very good latency at scale. By carefully implementing this insight, a research prototype was built that achieves six orders of magnitude speed-up and up to seven orders of magnitude memory reduction compared to state-of-the-art approaches.
Microsoft has the unique advantage of a world-class data management system in SQL Server and a leading public cloud in Azure. This is especially exciting at a time when cloud-native architectures are revolutionizing database management.
There has never been a better time to be part of database systems innovation at Microsoft, and we invite you to explore the opportunities to be part of our team.
Most modern-day businesses employ analytics pipelines for real-time and batch processing. A common characteristic of these pipelines is that data arrives at irregular intervals from diverse sources. This adds complexity in terms of having to orchestrate the pipeline such that data gets processed in a timely fashion.
The answer to these challenges lies in coming up with a decoupled event-driven pipeline using serverless components that responds to changes in data as they occur.
An integral part of any analytics pipeline is the data lake. Azure Data Lake Storage Gen2 provides secure, cost effective, and scalable storage for the structured, semi-structured, and unstructured data arriving from diverse sources. Azure Data Lake Storage Gen2’s performance, global availability, and partner ecosystem make it the platform of choice for analytics customers and partners around the world. Next comes the event processing aspect. With Azure Event Grid, a fully managed event routing service, Azure Functions, a serverless compute engine, and Azure Logic Apps, a serverless workflow orchestration engine, it is easy to perform event-based processing and workflows responding to the events in real-time.
Today, we’re very excited to announce that Azure Data Lake Storage Gen2 integration with Azure Event Grid is in preview! This means that Azure Data Lake Storage Gen2 can now generate events that can be consumed by Event Grid and routed to subscribers with webhooks, Azure Event Hubs, Azure Functions, and Logic Apps as endpoints. With this capability, individual changes to files and directories in Azure Data Lake Storage Gen2 can automatically be captured and made available to data engineers for creating rich big data analytics platforms that use event-driven architectures.
The diagram above shows a reference architecture for the modern data warehouse pipeline built on Azure Data Lake Storage Gen2 and Azure serverless components. Data from various sources lands in Azure Data Lake Storage Gen2 via Azure Data Factory and other data movement tools. Azure Data Lake Storage Gen2 generates events for new file creation, updates, renames, or deletes which are routed via Event Grid and Azure Function to Azure Databricks. A databricks job processes the file and writes the output back to Azure Data Lake Storage Gen2. When this happens, Azure Data Lake Storage Gen2 publishes a notification to Event Grid which invokes an Azure Function to copy data to Azure SQL Data Warehouse. Data is finally served via Azure Analysis Services and PowerBI.
The events that will be made available for Azure Data Lake Storage Gen2 are BlobCreated, BlobDeleted, BlobRenamed, DirectoryCreated, DirectoryDeleted, and DirectoryRenamed. Details on these events can be found in the documentation “Azure Event Grid event schema for Blob storage.”
Some key benefits include:
Seamless integration to automate workflows enables customers to build an event-driven pipeline in minutes.
Enable alerting with rapid reaction to creation, deletion, and renaming of files and directories. A myriad of scenarios would benefit from this – especially those associated with data governance and auditing. For example, alert and notify of all changes to high business impact data, set up email notifications for unexpected file deletions, as well as detect and act upon suspicious activity from an account.
Eliminate the complexity and expense of polling services and integrate events coming from your data lake with third-party applications using webhooks such as billing and ticketing systems.
Next steps
Azure Data Lake Storage Gen2 Integration with Azure Event Grid is now available in West Central US and West US 2. Subscribing to Azure Data Lake Storage Gen2 events works the same as it does for Azure Storage accounts. To learn more, see the documentation “Reacting to Blob storage events.” We would love to hear more about your experiences with the preview and get your feedback at [email protected]
Earlier this year, we announced Cloud Run, a managed serverless compute platform for stateless containers. Cloud Run abstracts away infrastructure management, and makes it easy to modernize apps. It allows you to easily run your containers either in your Google Kubernetes Engine (GKE) cluster with Cloud Run on GKE or fully managed with Cloud Run.
Cloud Run has lots of great features and you can read the full list on the webpage. But in conversations with customers, three key features of the fully managed version of Cloud Run stand out:
Pay for what you use pricing Once above the always free usage limits, Cloud Run charges you only for the exact resources that you use.
For a given container instance, you are only charged when:
The container instance is starting, and
At least one request or event is being processed by the container instance
During that time, Cloud Run bills you only for the allocated CPU and memory, rounded up to the nearest 100 milliseconds. Cloud Run also charges for network egress and number of requests.
As shared by Sebastien Morand, Team Lead Solution Architect at Veolia, and Cloud Run developer, this allows you to run any stateless container with a very granular pricing model:
“Cloud Run removes the barriers of managed platforms by giving us the freedom to run our custom workloads at lower cost on a fast, scalable and fully managed infrastructure.”
Concurrency > 1 Cloud Run automatically scales the number of container instances you need to handle all incoming requests or events. However, contrary to other Functions-as-a-Service (FaaS) solutions like Cloud Functions, these instances can receive more than one request or event at the same time.
The maximum number of requests that can be processed simultaneously to a given container instance is called concurrency. By default, Cloud Run services have a maximum concurrency of 80.
Using a concurrency higher than 1 has a few benefits:
You get better performance by reducing the number of cold starts (requests or events that are waiting for a new container instance to be started)
Optimized resource consumption, and thus lower costs: If your code often waits for network operations to return (like calling a third-party API), the allocated CPU and memory can be used to process other requests in the meantime.
Secure event processing with Cloud Pub/Sub and Cloud IAM
Your Cloud Run services can receive web requests, but also other kinds of events, like Cloud Pub/Sub messages. We’ve seen customers leverage Cloud Pub/Sub and Cloud Run to achieve the following:
Publish and process their own custom events from their Cloud Run services.
The messages are pushed to your Cloud Run container instances via the HTTP protocol. And leveraging service accounts and Cloud IAM permissions, you can securely and privately push messages from Cloud Pub/Sub to Cloud Run without having to expose your Cloud Run service publicly. Only the Cloud Pub/Sub subscription that you have set up is able to invoke your service.
You can achieve this with the following steps:
Deploy a Cloud Run service to receive the messages (it listens for incoming HTTP requests, and returns a success response code when the message is processed)
Create a Cloud Pub/Sub topic
Create a new service account and grant it the “Cloud Run Invoker” role on your Cloud Run service
Create a push subscription and give it the identity of the service account.
Read more about using Cloud Pub/Sub push with Cloud Run here, and follow this tutorial for a step-by-step example.
Run, don’t walk, to serverless containers These are just a few of the neat things that developers appreciate about Cloud Run. To learn about all the other things to love about Cloud Run, check out these Cloud Run Quickstarts.
Developers love serverless. With serverless, you can focus on code, deploy it, and let the platform take care of the rest—all while only paying for exactly what you use. But traditional serverless solutions can limit what programming languages you can use, or require you to organize our code around functions.
At Google Cloud Next 2019, we launched Cloud Run, a serverless compute platform that lets you run any stateless request-driven container on a fully managed environment. In other words, with Cloud Run, you can take an app—any stateless app—containerize it, and Cloud Run will provision it, scale it up and down, all the way to zero!
Check out how easy it is to get started and deploy your first container to the fully managed version of Cloud Run:
Cloud Run is unique among serverless platforms, and brings a number of benefits:
Do less work with a fully managed solution: With Cloud Run, you can forget about provisioning or managing infrastructure—it does that for you. Cloud Run automatically and quickly scales up or down based on your incoming traffic, and even scales down to zero. In addition, each Cloud Run service gets a stable and secure HTTPS endpoint, and you can easily add your own custom domain for which we automatically provision an SSL certificate. And if you need an easy way to serve static content or cache responses, Cloud Run integrates with Firebase Hosting.
Pay exactly for what you use: Cloud Run charges you for the resources you use only when your containers are processing requests or events, billed to the nearest 100 milliseconds.
Serve web traffic, or process Pub/Sub events: Run publicly accessible web services or APIs, or securely push Pub/Sub events to private Cloud Run microservices.
Leverage the power of containers: Containers have become an industry standard for packaging and deploying code, and let you write your code in your favorite language, with whatever framework or binary library that works for you. If you’re not familiar with containers, don’t be scared; Cloud Run includes official base images for all the most popular languages, and there are examples of Dockerfiles in the documentation.
Enjoy the portability that comes with Knative: Cloud Run implements the Knative serving API, an open-source project to run serverless workloads on top of Kubernetes. That means you can deploy Cloud Run services anywhere Kubernetes runs. And if you need more control over your services (like access to GPU or more memory), you can also deploy these serverless containers in your own GKE cluster instead of using the fully managed environment.
On a run since Google Cloud Next’19 Since it launched in April, Cloud Run has gotten a terrific reception from developers. Early adopters tell us that deploying their favorite apps on Cloud Run “just works.”
“Cloud Run allows us to access, process and serve large amounts of imagery data stored in Google Cloud Storage, with the freedom to use our own custom toolchains and without having to worry about scaling the service to the real time load.” – Thomas Bonfort, R&D Earth Observation Software Engineer at Airbus, and Cloud Run alpha tester
Early Cloud Run alpha testers and then beta users have provided valuable feedback to help us shape and improve the product. Today, we are pleased to launch several new features to address your top requests:
Cloud SQL support With one configuration change, you can now securely and privately connect your Cloud Run services to Cloud SQL instances. Read more in the documentation.
Metrics at a glance As Cloud Run developers, you have been able to benefit from out-of-the-box integration with Stackdriver Logging and Monitoring. But you do not always need the full power of Stackdriver tools. Starting today, the Cloud Run user interface features several key performance indicators, such as:
Comparing the average number of requests per second in the Cloud Run service list
Observing request counts, request latencies, CPU and Memory allocation in a dedicated tab of the Cloud Run service view
New regions Initially offered only in the U.S., we’ve also seen great adoption of Cloud Run among developers in other parts of the world. That’s why we are very happy to announce that we will start Cloud Run’s regional expansion within the next few weeks, starting by opening new regions in Europe and Asia.
Learn more Take our quickstart to deploy your first container to Cloud Run in seconds. For a deep dive on Cloud Run’s features and characteristics, check out my session at Google Cloud Next 2019:
We can’t wait to see what you’ll build with Cloud Run!
Kubernetes is taking the app development world by storm. Earlier this month, we shared that the Azure Kubernetes Service (AKS) was the fastest growing compute service in Azure’s history. Customers like Siemens Healthineers, Finastra, Maersk, and Hafslund are realizing the benefits of using AKS to easily deploy, manage and scale applications without getting into the toil of maintaining infrastructures. As the community and adoption grows, Kubernetes itself is evolving, adding more enterprise-friendly features and extending to more scenarios. The release of production-level support for Windows Server containers is a true testament to the evolution.
Today, we’re excited to announce the preview of Windows Server containers in Azure Kubernetes Service (AKS) for the latest versions, 1.13.5 and 1.14.0. With this, Windows Server containers can now be deployed and orchestrated in AKS enabling new paths to migrate and modernize Windows Server applications in Azure.
Our customers have applications running on Linux and on Windows. The ability to manage Windows and Linux containers side by side in the same Kubernetes cluster with the exact same APIs, tools and support is what you have been asking us to support, which opens an abundance of new scenarios. For example, you can now add Windows node pools to existing Virtual Network; or deploy a Linux container running a reverse proxy or Redis cache and an IIS application in a Windows container in the same Kubernetes cluster and even as part of the same application – all with consistent monitoring experience and deployment pipelines.
Running Windows Server containers in AKS (preview) also means you can keep taking advantage of many existing Azure services and features that are helping make Kubernetes application development and management much easier, such as:
Manage the lifecycle of Linux and Windows containers easily through Azure Container Registry, which pre-stages all container base images. To reduce network latency or meet rigorous compliance needs, Container Registry can automatically geo-replicate the container images to the data center close to where your users are.
Deliver applications faster on any OS with a standardized deployment pipeline. Azure DevOps integration with AKS helps automate validation, testing, canary and ultimately production easily in just a few steps.
Gain insights into the performance and health of your Kubernetes cluster and workloads with a comprehensive monitoring experience using Azure Monitor.
Now is the time to get started with Windows Server containers in Azure Kubernetes Service (preview) and we look forward to your feedback on these new features and experiences! If you are new to Kubernetes, check out these short Kubernetes whiteboard videos with Brendan Burns, one of the co-founders of Kubernetes, so you can learn how it works for both Windows and Linux!
We would like to take the moment to thank every contributor and customer, without whom, today’s announcement would not be possible. We are proud to be part of the broader and vibrant Kubernetes community.
Optimizing compute resource allocation to achieve performance goals while controlling costs can be a challenging balance to strike especially for database workloads with complex usage patterns. To help address these challenges, we are pleased to announce the preview of Azure SQL Database serverless. SQL Database serverless (preview) is a new compute tier that optimizes price-performance and simplifies performance management for databases with intermittent and unpredictable usage. Line-of-business applications, dev/test databases, content management and e-commerce systems are just some examples across a range of applications that often fit the usage pattern ideal for SQL Database serverless. SQL Database serverless is also well-suited for new applications with compute sizing uncertainty or workloads requiring frequent rescaling in order to reduce costs. The serverless compute tier enjoys all the fully managed, built-in intelligence benefits of SQL Database and helps accelerate application development, minimize operational complexity, and lower total costs.
Compute auto-scaling
SQL Database serverless automatically scales compute for single databases based on workload demand and bills for compute used per second. Serverless contrasts with the provisioned compute tier in SQL Database which allocates a fixed amount of compute resources for a fixed price and is billed per hour. Over short time scales, provisioned compute databases must either over-provision resources at a cost in order to accommodate peak usage or under-provision and risk poor performance. Over longer time scales, provisioned compute databases can be rescaled, but this solution may require predicting usage patterns or writing custom logic to trigger rescaling operations based on a schedule or performance metrics. This adds to development and operational complexity. In serverless, compute scaling within configurable limits is managed by the service to continuously right-size resources. Serverless also provides an option to automatically pause the database during inactive usage periods and automatically resume when activity returns.
Pay only for compute used
In SQL Database serverless, compute is only billed based on the amount of CPU and memory used per second. While the database is paused only storage is billed, providing additional price optimization benefit.
Consider a line-of-business application or a dev/test database that is idle at night, but needs multi-core bursting headroom throughout the day. In this example, the application is using serverless configured to allow auto-pausing and auto-scaling up to four vcores and has the following usage pattern over a 24 hour period:
As can be seen, database usage corresponds to the amount of compute billed which is measured in units of vcore seconds and sums to around 46k vcore seconds over the 24 hour period. Suppose the compute unit price for the serverless database is around $0.000073/vcore/second. Then the compute bill for this one day period is just under $3.40. This is calculated by multiplying the compute unit price by the total number of vcore seconds accumulated. During this time period, the database was auto-paused while idle and enjoyed the benefit of bursting episodes up to 80 percent of four vcores without customer intervention. In this example, the price savings using serverless is significant compared to a provisioned compute database configured with the same four vcore limit.
Note that pricing is discounted for preview. In this example, pricing is based on the East US region in May 2019 and subject to change. For the most up-to-date pricing, please visit the Azure SQL Database pricing page.
Price-performance trade-offs
When using SQL Database serverless there are price-performance trade-offs to consider. These trade-offs are related to the compute unit price and the impact on application performance due to compute warm-up after periods of low or idle usage.
Compute unit price
The compute unit price is higher for a serverless database than for a provisioned compute database since serverless is optimized for workloads with intermittent usage patterns. If CPU or memory usage is high enough and sustained for long enough, then the provisioned compute tier may be less expensive.
Compute warm-up after low usage
While a serverless database is online, memory is gradually reclaimed if CPU or memory usage is low enough for long enough. When workload activity returns, disk IO may be required to rehydrate data pages into the SQL buffer pool or query plans may need to be recompiled. This memory management policy to reclaim cache based on low usage is unique to serverless and done to control customer costs, but can impact performance. Memory reclamation based on low usage does not occur in the provisioned compute tier for single databases or elastic pools where this kind of impact can be avoided.
Compute warm-up after pausing
The latency to pause and resume a serverless database is usually around one minute or less during which time the database is offline. After the database is resumed, memory caches need to be rehydrated which adds additional latency before optimal performance conditions return. The idle period that must elapse before auto-pausing occurs can be configured to compensate for this performance impact. Alternatively, auto-pausing can be disabled for workloads sensitive to this impact and still benefit from auto-scaling. Compute minimums are billed while the database is online regardless of usage, and so disabling auto-pausing can increase costs.
Learn more
Azure SQL Database serverless is supported in the General Purpose tier for single databases.
Things are changing for the modern business. API-first development and microservices architecture is opening the door to new innovations. Many of these new approaches are possible in part due to the evolution of serverless technology, which eliminates the need for the management of infrastructure.
Fully managed infrastructure allows for allocating resources to solving a business problem, rather than managing the IT infrastructure. This results in more agility, reduced operating cost, and shorter time-to-market, which is important for organizations of any size.
Serverless is for all, no matter the size
The benefits serverless offers is independent of the size of the company. For example:
Startups need to quickly assess product-market fit and build prototypes to test their hypotheses.
With limited resources, startups can build, measure, and iterate their way to success with execution-based pricing models.
Unlocks a new generation of startups, all built on the idea that a small group of people with a limited budget can be disruptive.
As they evolve, they’ll benefit from serverless much in the same way as larger organizations do.
Enterprises need to adapt to constantly evolving customer requirements to stay competitive with agile, fast moving startups.
Serverless enables a business to grow without worrying about managing infrastructure and the planning associated with it.
Promotes move to architectural patterns that increase the flexibility and agility of software development.
Provides the ability to compete at the same level as more nimble players, while consistently growing the business.
Both benefit equally from a serverless approach, for different reasons.
Improved, stronger integration for API-first applications
Over the past year, API Management has collaborated with Azure Functions to build a stronger integration between the two services. Over the past year, API Management has collaborated with Azure Functions to build a stronger integration between the two services. Our goal is to increase developers’ productivity and provide better, more impactful experiences for creating serverless, API-first applications.
To achieve that goal, we are announcing that two new capabilities are now generally available:
Azure API Management simplifies publishing of APIs as well as their consumption by clients. It allows for abstraction of APIs from their implementation. APIs are governed through policies, managed from a unified plane, optimized through caching, and published for frictionless consumption through a developer portal.
API Management is the front door for your application. Azure Functions provide serverless compute and eliminate the initial friction associated with implementing new applications. Functions allow for agile assembly of prototypes and production-grade solutions.
Moving into the future
The proliferation of APIs and the API economy has given rise to new opportunities for businesses of all sizes. API-first development is now a necessary approach to ensure future success. This is why we are excited about the investments we’ve made this year and how we are making API architectures easier to adopt by leveraging serverless technology.
When we ask developers why they choose Cloud Functions, “simplicity” comes up a lot: write a few lines of code, deploy and… voilà! You’ve got a serverless, auto-scaling, pay-per-use function running on Google Cloud.
A big part of that simplicity comes from being able to write Cloud Functions in your favorite programming language. That’s why we’re excited about our recent language support announcements at Google Cloud Next ‘19:
Python 3.7, Go 1.11 and Node.js 8 runtimes are now generally available.
Node.js 10 runtime is now in public beta.
Go 1.12 and Java 8 runtimes are in private alpha (sign up to test Go 1.12 and Java 8).
Let’s take a closer look at one of the generally available runtimes:
Serverless + Python on Cloud Functions Over the past six months, we’ve spoken to many established and up-and-coming customers who have used these runtimes to build on Cloud Functions. One customer, infarm, uses Cloud Functions and Python 3 to support its distributed network of efficient vertical farms:
The event driven interface was an especially good fit for our alerting stack, taking in more than 2.6 million plant- and farm-related measurements per day to prevent our crops from being affected by potential incidents. We rely on Google’s monitoring and alerting capabilities to monitor 400+ farms across Europe. – Nicolas Delaby, Lead Engineer, infarm
By opting for serverless on Google Cloud, infarm can focus on its mission: to help cities develop self-sufficient food production while improving agricultural safety, quality, and lowering their environmental footprint. Notice how that mission doesn’t include “managing my server infrastructure” or “learning new programming languages”?
Use Cloud Functions to process IoT data Python and data processing go hand-in-hand. A common architectural pattern that we’ve observed among customers that use IoT devices is to have each device push sensor readings to a message bus. For example, one of infarm’s modular farms might have multiple IoT devices, each sending sensor data as messages to a Cloud Pub/Sub topic. When a message is delivered to the topic, it triggers a function, which performs a task. That task can be as simple as redirecting messages to a persistent datastore like Cloud SQL, to enriching data before inserting it in BigQuery, to performing complex processing.
Cloud Functions is a great choice for single purpose, repeated data processing use cases. Because Cloud Functions scales automatically based on load, it’s also a good fit for a project that will continue to grow into the future. As infarm adds new IoT devices, Cloud Functions scales up to meet that increased load.
A world of Python packages Cloud Functions supports Python’s rich ecosystem of packages, which unlocks a huge variety of use cases. The Cloud Functions Python 3.7 runtime uses the open-source Python distribution so you can easily add packages to your Cloud Functions using `pip`. These dependencies are installed automatically when you deploy your function. Customers use this functionality to access Google Cloud APIs from Cloud Functions using the idiomatic `google-cloud-python` package. Others are using packages like NumPy and SciPy to create data processing pipelines.
Try Python 3.7 on Cloud Functions today You don’t need to be on a visionary mission to reinvent food production to start writing functions with Python 3.7 today—check out the docs to get started.
Learning how to build a serverless deployment pipeline on Google Cloud Platform
Several years ago I worked with a team to build a production CI/CD pipeline for an AWS project. At that time, none of the major cloud vendors offered their own CI/CD services, so we then used the open source GO CD server.
Although we were successful, the project was tedious and took several months. For this reason, I’ve been interested to try out integrated alternatives as they become available.
Lately, much of my production work has involved constructing and testing cloud-based data pipelines at scale for bioinformatics research. I have been thinking for awhile now about how best to use new cloud-based CI/CD services in automating these complex pipeline deployments.
Picturing Automated Deployment
As I worked through a well-written tutorial on GCP CI/CD today, I was surprised to be unable to find any sort of diagram of the process. Although I was able to complete the tutorial successfully, I was still left feeling like I was not fully comprehending the solution architecture applications.
GCP cloud-native CI/CD Tutorial Steps
Next, I attempted to draw my own version of what I completed in the tutorial. Quickly sketching considerations from my production experience and trying to combine that with what I had learned from completing the tutorial was unsatisfying. The result is shown below.
My initial thoughts around cloud-native CI/CD
A clear path through the complexity of the steps involved wasn’t yet apparent to me. After sketching, I tried thinking about each service or set of services that would be involved in building this type of pipeline.
Considering GCP Services
I started by trying to understand the GCP Tool Services offerings and how each service would relate to building a CI/CD solution for the type of data pipelines my teams have been building.
There are a number of tools. Below is my summarized understanding of each of the GCP services listed on the Tools menu. Note that all of these services are serverless.
GCP Tools
Cloud Build— to create build pipelines with steps & triggers; outputs artifacts (images…)
Then I watched a few presentations from the recent GCP:Next conference. The most useful to me were the following:
“CI CD Across Multiple Environments” — interesting, but showed combining non GCP tools (Jenkins, HashiCorp Vault…) with GCP tools, so added even more complexity to potential scenarios.
Although these presentations and doing the tutorial were helpful in my understanding of how I might use these services for my customers, I still couldn’t visualize what I would actually build. To that end, I made an attempt to diagram one possible CI/CD architecture for a use case that I’ve been working on for awhile now.
Visualizing CI/CD for GCP Data Pipelines
Here’s my attempt to design a solution for one of my customers. I’ll describe the application architecture first. The use case is bioinformatics research via a specialized machine learning library for genomics, VariantSpark.
Below is a diagram of solution architecture on GCP K8:
CSIRO’s VariantSpark on GCP K8
You’ll note that this is a Data Lake with the K8 cluster processing data from GCS. Managed Jupyter Notebooks are part of the solutions as this is the preferred environment for research work.
Shown below is my first draft of how I imagine my team could use GCP CI/CD services to build a pipeline to deploy a VariantSpark K8 cluster on GCP.
GCP CI/CD Pipeline for VariantSpark K8 Deployment
Because VariantSpark in an open source library, there are continual improvements to it. However, because VariantSpark is a research tool, it uses major and minor version numbers in release so that it can be cited in reproducible bioinformatics research papers.
So the process to build a cluster first requires determining which version of the VariantSpark JAR file is desired for the base container image. The pipeline may needs to perform a maven build on the source GitHub Repo for VariantSpark.
Cloud Build artifacts include Docker Images, Kubernetes Clusters and more
GCP Source Repositories can mirror GitHub Repos. Cloud Build can use triggers on Source Repositories to trigger builds. Cloud Build includes builder (task) for various types of images including maven. Cloud Build builders also include docker and kubectl, so the VariantSpark JAR file could be built as part of the docker image and that image could be used to spawn a GKE cluster.
Additionally, GCP Deployment Manger could serve a YAML-deployment which details other GCP service configurations that are needed for a GKE cluster. It also seems possible to use GCP Private Catalog for research groups who have GCP Organizational Accounts to offer a VariantSpark GKE deployment template.
Next Steps
Now that I’ve learned the fundamentals of these services, I am looking forward to working with research and DevOps teams world-wide to build serverless CI/CD pipelines for bioinformatics.
Lynn Langit is a big data and cloud architect, a Google Cloud Developer Expert, an AWS Community Hero, and a Microsoft MVP for Data Platform.
Cloud-based CI/CD on GCP was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.
Lean how modern application developers can use the new Data API to create and connect to an Aurora Serverless Database
In this article with screencast videos, we’ll go over the three ways to create an Aurora Serverless Database with Data API. We’ll also cover the four ways to connect to your Data API enabled Aurora Serverless Database.
Let’s quickly go over what Amazon Aurora offers, why a serverless database, and answer, what is the Data API and why should I care?
About Amazon Aurora
Amazon Aurora is a MySQL and PostgreSQL-compatible relational database built for the cloud, that combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open source databases.
Why Amazon Aurora Serverless? Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora (MySQL-compatible edition). The database will automatically start up, shut down, and scale capacity up or down based on your application’s needs. It’s a simple, cost-effective option for infrequent, intermittent, or unpredictable workloads.
What is Amazon Aurora Serverless Data API? The Data API is a new managed API layer on top of an Aurora Serverless database, allowing you to connect directly with your MySQL or PostgreSQL database. It also allows you to execute SQL statements from any application over HTTP without using a MySQL driver, plugin, or need to manage a connection pool or VPC.
Think of the Data API as a fully-managed API for interacting with your relational data. As the Data API is connected to your Serverless Cluster, you also get inherited auto-scaling, available, and backups of your database along with pausing of the database while not in use.
Three Ways to Create an Aurora Serverless Database w/ Data API:
My personal favorite is Option 2 CloudFormation for deployment as you can deploy predictable resources (not missing a step vs manual creation) and you can add additional AWS services and permissions in the CloudFormation template.
Option #1: Amazon RDS Console — Manual The RDS Console is a quick way to deploy your resources and be done in just a few minutes following these instructions:
Create a new Aurora Serverless Cluster:
Launch the Amazon RDS Console.
Select Amazon Aurora engine.
Select MySQL 5.6-compatible (the only option for serverless) and select Next.
Select Serverless for the capacity type and provide a cluster name and master credentials and select Next.
Leave all defaults and choose Create database.
Screencast for creating an Aurora Serverless Cluster via the RDS Console
Enable the Data API (for an existing Aurora Serverless Cluster): We are going to enable the Data API for the newly created Aurora serverless cluster manually via the RDS Management Console. Hopefully, this is temporary until we can enable the Data API via a CloudFormation template using the EnableHTTPEndpointAPI parameter once this puppy is out of BETA. In the meantime …
Select your cluster (even though it says database)
Select the Modify button on the upper right
Select “Data API” under the Network & Security section
Select Continue button
Select “Apply immediately” under Scheduling of modifications
Select “Modify cluster” radio button
Option #2: CloudFormation — Automated CloudFormation is the best way to deploy a consistent environment in an automated way. This solution consists of creating a CloudFormation stack based on the CloudFormation template provided in this GitHub repo here.
The template has all the parameters defined for deploying an Aurora Serverless Database in just a few clicks. In addition to creating a serverless database, the template also creates an AWS Lambda function (written in Node.js 8.10) to access your Data API enabled database using the new AWS RDSDataService API. More on the Lambda function later when we connect to a Data API enabled database in Solution 3 below.
The CloudFormation template will provision the following resources:
Aurora Serverless (MySQL) Cluster
Aurora Serverless (MySQL) Database
AWS Lambda function for connecting to your database via Data API using the AWS RDSDataService API.
IAM Policies for Lambda execution of RDSDataService API, CloudWatch Logs, and read only from AWS Secrets to get database master credentials.
Get Started with CloudFormation Follow the two (2) steps as outlined in this GitHub repo for deploying the resources in your AWS account.
The first step will deploy the resources via a CloudFormation Stack, and the second step walks through enabling the Data APIfor the created Aurora Serverless Database.
Step 1: Deploy CloudFormation Stack via GitHub repo here.
Step 2: Enable Data API following GitHub Step 2 instructions here.
Option #3: AWS CLI or SDK — Scripted The AWS CLI or AWS SDK can be used to create your resources with just a few lines. Here’s a full AWS CLI statement for creating a new Aurora Serverless Cluster:
Once the Aurora Serverless Cluster has been created, follow Step 2: Enable Data API from the previous section and you now have an Aurora Serverless database with Data API enabled.
Four Ways to Connect to Your Database Using the Data API
In the Connect to Database window, select your cluster, provide your master user, master password, and database name (optional).
Select Connect to database.
Note: When you provide the cluster credentials the first time, the service will create an AWS Secret automatically for you, then each subsequent access to this cluster via the Query Editor, the service will use this AWS Secret to pull in the master user credentials for this cluster.
Once in the Query Editor, select the Clear button and type:
use MarketPlace;
select * from Customers;
Select Run.
Here’s the result if you have a Customers table with data:
SQL statement in RDS Console — Query Editor
TIP: The Query Editor is a nice tool to have when you need to verify the contents of the table or just perform some quick SQL statements.
Solution #2: AWS CLI Modify the provided AWS CLI script with your own cluster arn, secrets arn, database name, and the SQS select statement of your choice.
Solution #3: AWS Lambda function Once you deploy an Aurora Serverless Data API enabled database, you can easily connect and execute any SQL statement against the database with a simple AWS Lambda function using the RDSDataService API.
This function does not need to be inside an Amazon VPC and it doesn’t need to have any MySQL drivers or worry about connection pooling. Just make SQL statements as HTTP request and Aurora Serverless takes care of the rest!
Get Started Using a Lambda function to connect via Data API:
You can use the deploy Option #2 — CloudFormation above that provisions a database, a Lambda function, and fills out the environment variables to get you started OR… you can copy this code and deploy to Lambda directly.
If you do this manually, you’ll need to fill-in the Lambda environment variables to match your Aurora Serverless environment like Cluster Arn, DB name, and AWS Secrets arn.
Here’s the entire code to make SQL statement against your Aurora Serverless Data API enabled database. Again, make sure to provide the environment variables and then pass in something like:
{ “sqlStatement”: “SELECT * FROM ” }
The Lambda function will then make a connection to your database using the master credentials pulled from AWS Secrets and return a JSON response. It’s that easy!
Note: As of April 25, 2019 the Data API (beta) is only available to US-EAST-1 region serverless databases. Also, the function uses the RDSDataService API that is not currently available (beta) in the default Node 8 engine for Lambda, so you’ll need to build and deploy the function to Lambda as a zip file.
Solution #4: AWS AppSync When building a GraphQL API via AWS AppSync, you now have direct access to your serverless Data API enabled database as a datasource, and… AppSync will generate a GraphQL schema for you, based on the existing database table design!
For this solution, we’ll use the new add-graphql-datasourcepluginfor the AWS Amplify CLI that automatically takes your serverless database table(s) and creates/updates a GraphQL schema, generates the appropriate mutations, queries, and subscriptions, and sets your database as a GraphQL DataSource to an existing GraphQL API. Yes, please.
Before we use the plugin, we want to make sure our Aurora serverless database has at least one table. If a database doesn’t exist, let’s create those now by using the RDS Query Editor in the RDS Console and then we’ll switch over to the Amplify CLI + add-graphql-datasource plugin.
Here, we are going to use the RDS Query Editor to create a database and sample table to get us started. If you already have a database and table from previous steps, move onto the [Amplify CLI — Installing the CLI] section below.
In the Connect to Database window, select your cluster, provide your master user, master password, and database name (optional).
Select Connect to database.
In the query editor window, run the following commands:
Create database ‘MarketPlace’ if you haven’t already.
CREATE DATABASE MarketPlace;
Create a new Customers table.
USE MarketPlace; CREATE TABLE Customers ( id int(11) NOT NULL PRIMARY KEY, name varchar(50) NOT NULL, phone varchar(50) NOT NULL, email varchar(50) NOT NULL );
Now that we have a database and a Customers table, we can now use the add-graphql-datasource plugin to generate a GraphQL schema, add the database as a datasource, and add mutations, queries, and subscriptions based on the [Customers] table.
Here’s how the add-graphql-datasource plugin works:
Amplify CLI — Installing the CLI If you haven’t installed the AWS Amplify CLI before, here’s a quick shortcut. If you have the AWS CLI installed, the Amplify CLI will utilize those credentials and therefore amplify configure is not necessary.
Amplify CLI — Init Launch Mac Terminal in the root of your iOS project folder. Now, we’ll initialize our AWS backend project using the following Amplify command.
$ amplify init
You will be guided through the process of setting up the project.
Amplify CLI — Add API
$ amplify add api
Amplify CLI — Add GraphQL DataSource
$ amplify api add-graphql-datasource
Now, let’s create a new customer in the Customers table using the Queries tool in the AppSync Console.
AppSync Queries — in action
We can then query the Customers table from the Query Editor in the RDS Console to double check.
Amazon RDS Query Editor — Aurora Serverless Data API SQL Statement
Now that we have the schema, mutations, queries, subscriptions, and our serverless Aurora database as a datasource for our GraphQL API, we can start using a mobile or web client with the generated code to interact with this structured data!
Conclusion
Although the Data API and the RDSDataService API are currently in beta, there’s so much buzz and potential here for modern application developers.
The Data API allows any developer to take advantage of structured collections of data by having more control over the database, less management, no drivers or connection pools, and executing SQL statements as HTTP requests is a game changer.
I’ll update this article as this service feature progresses.
A general critique of Cloud Run relative to FaaS and managed API services — and how this is different from AWS Lambda
This week, at Google Cloud Next, GCP announced an interesting new service: Cloud Run. My thoughts about the new Cloud Run service are a bit more complicated than this Twitter thread, so I’ve expanded on them in this blog and welcome your comments.
Don’t focus too much on the packaging format. Container images are an industry standard for packing bits in a tarball vs Lambda’s use of zip files and layers. https://t.co/LdNCUZixw1
In this article, I’ll compare Google’s Cloud Run with AWS Lambda and API Gateway because I am most familiar with those services and provider. But my thoughts below are a general critique of Cloud Run relative to FaaS including Google Cloud Functions and managed API services in general — regardless of the provider.
What is Cloud Run?
Google’s Cloud Run allows you to hand over a container image with a web server inside, and specify some combination of memory/CPU resources and allowed concurrency. The logic inside your container must be stateless.
Cloud Run then takes care of creating an HTTP endpoint, receiving requests and routing them to containers, and making sure enough containers are running to handle the volume of requests. While your containers are handling requests, you are billed in 100 ms increments.
How is this different than AWS Lambda?
This sounds a lot like Lambda. How is it different? You are handling multiple requests within a single container. At a fundamental level, Cloud Run is just serving as a very fancy load balancer.
All of the web logic is inside your container; auth*, validation, error handling, the lot of it. But instead of just measuring resource utilization or other metrics that are a proxy for load, Cloud Run understands requests and uses that directly as a measure of load to know how to scale and route.
Note: if you’re using GCP IAM and you’re running on the managed version of Cloud Run, the service can do the auth for you. There’s no custom authorizers, nor do I expect there to be in the future, because why not just put it in your web server?
In Lambda, while you can set up API Gateway to do no validation or auth and pass everything through to your Lambda, you’d be missing out on a wealth of managed features that perform these functions for you.
What’s the Good?
So what’s good about Cloud Run?
It’s going to make it very, very simple for people who are running containerized, stateless web servers today to get serverless benefits.
Better scaling and fine-grained billing.
It’s also dead simple to test locally, because inside your container is a fully-featured web server doing all the work.
What’s the Bad?
So what’s bad about Cloud Run? Inside your container is a fully-featured web server doing all the work!
The point of serverless is to focus on business value, and the best way to do that is to use managed services for everything you can — ideally only resorting to custom code for your business logic.
If we try to compare Cloud Run to what’s possible inside a Lambda function execution environment, we’re missing the point.
The point is that the code you put inside Lambda, the code that you are liable for, can be smaller and more focused because so much of the logic can be moved into the services themselves.
The FaaS Model: Handling each request in isolation
API Gateway allows you to use custom authentication. That means that your code, in a Lambda that does nothing else, can reject the request.
You don’t have to even think about that request touching your downstream web handling code.
You don’t have to pay for invocation of the request-handler Lambda.
You aren’t paying for evaluating auth on every request since that custom authentication response is cached by API Gateway.
API Gateway allows you to perform schema validation on incoming requests. If the request fails validation, your Lambda doesn’t get invoked. Your code doesn’t have to worry about malformed requests.
Note: The API Gateway model validation is sadly a little more complicated than I’ve described above. Expect a post from myself and Richard Boyd on this topic in the near future.
The FaaS model is that each request is handled in isolation. Some people complain about this. I’ve even heard someone claim that AWS is pushing Lambda because users’ inability to optimize resource usage across requests is lucrative for them — which is about the most outlandish conspiracy theory I’ve heard this side of flat-earthers.
But the slightly less efficient usage model comes with benefits: you never have to worry about cross-talk effects. In Lambda, I don’t have to think about whether one request might have an impact on another. Everything’s isolated. This makes it easy to reason about, and removes one more thing I need to think about in the development process.
Security is hard, and the ability to scope your code’s involvement with it as small as possible is a huge win. Beyond the security implications, it’s also fewer moving parts that are your responsibility.
Cloud Run is also not the same as Lambda’s custom runtimes. Beyond the fact that custom runtimes should be a last resort, they don’t require running a server. Instead, you only need an HTTP client, which makes it more clear that what your code is doing is not acting as a tiny web server.
Cloud Run is not FaaS
All this is to say that Cloud Run should not be seen as equivalent, or even analogous, to pure FaaS — Cloud Run fundamentally involves significantly more code ownership. Cloud Run is still a valid rung on the serverless ladder, but there are many more above this service.
And that gets to my biggest concern. Cloud Run, and GCP in general, are providing people with a system that is going to make them complacent with traditional architecture, and not push them to gain the immense benefits of shifting (however slowly) to service-full architecture that offloads as many aspects of an application as possible to fully managed services.
Google’s strategy is to push Kubernetes as the solution to cloud architecture. And for good reason: Kubernetes is really good at solving people’s pain points while staying within the familiar architecture paradigm. And Google is doing a great job creating a Kubernetes layer on top of every possible base infrastructure.
But Kubernetes keeps us running servers. It removes the infrastructure notion of server, but encourages us to keep running application servers, like the ones inside Cloud Run containers.
Google’s ability to put Kubernetes on-prem is going to satisfy developers, and this will potentially come at the cost of delaying organizational moves to the public cloud. The difference from an application development perspective will be less apparent and will hide the higher total cost of ownership for being on-prem.
While Cloud Run is going to enable better usage of existing web server infrastructure, it’s also going to provide a safety blanket for developers intimidated by the paradigm shift of FaaS and service-full architecture. This will further delay the shift to the more value-oriented approach to development.
