Customers need scale and flexibility from their cloud and this extends into supporting services such as monitoring and logging. Google Cloud’s Monitoring and Logging observability services are built on the same platforms used by all of Google that handle over 16 million metrics queries per second, 2.5 exabytes of logs per month, and over 14 quadrillion metric points on disk, as of 2020. However, you let us know through consistent feedback that the previous construct of Workspaces for Cloud Monitoring was not providing the flexibility needed for your larger scale projects.

Cloud Operation’s New Approach to Multi-Project Monitoring

We’re happy to announce a new model for multi-project monitoring, which replaces the concept of Workspaces. This overhaul is geared toward maximizing the flexibility you have to manage your monitoring environments by introducing Metrics Scopes. Starting today you can associate your Google Cloud projects with multiple Metrics Scopes! Like Workspaces, Metrics Scopes will still be used to store all of the configuration content for dashboards, alerting policies, uptime checks, notification channels, and group definitions. However there is no limit to the number of Metrics Scopes to which you can associate a project. Prior to this change, a project could only be scoped with a single Workspace. Now, there are virtually unlimited possibilities for how you can set up multi-project monitoring. This unlocks a large variety of options, from more granular permissions to mission-focused configurations. At its most simple implementation though: operators/SREs can now create org-wide Metrics Scopes with monitoring configurations focused on infrastructure health. And developers can leverage Metrics Scopes built on a subset of their organization’s projects that allow them to focus on their application’s performance.

How it works

• When you have a collection of projects, Metrics Scopes enable you to view each project’s metrics in isolation as well as in combination with metrics stored by other projects. 
• The Metrics Scope is hosted by a scoping project. This scoping project is the Cloud project that is selected in the Cloud Console project picker.

Example

• In this example, Project-SRE is the name of a scoping project to monitor your fleet. You added two developer teams’ projects: Project-Dev-1 and Project-Dev-2, to Project-SRE’s Metrics Scope. If you select Project-SRE with the Cloud Console project picker and then go to the Monitoring page, you view the metrics for all three projects: 

• If you select Project-Dev-1 with the Cloud Console project picker and then go to the Monitoring page, you view the Metrics Scope for Project-Dev-1 and you can only see the metrics for that project:

What else is new?

• Metrics Scopes can now monitor up to 375 projects (up from 100).
• New projects automatically start working in Cloud Monitoring without the previous 60-second Workspace creation process.
• If you want to monitor more than one project simply add it to your Metrics Scope:

Navigation

• Mentioned earlier, the Project Picker in the Cloud Console can be used to navigate between Metrics Scopes in Cloud Monitoring:

• This is now consistent with many other services across Google Cloud. Specifically, you can see how the project picker stays consistent when navigating from Cloud Monitoring to Cloud Logging:

• Additionally, to make your navigation between Metrics Scopes easy we’ve added the new Metrics Scope Tab and Panel in the UI:

Coming Soon

• The Metrics Scope API is coming within the next quarter! This API will enable you to programmatically manage your monitoring configurations and Metrics Scopes.

Current Workspaces users

If you are already using Workspaces in Cloud Monitoring you may have noticed that they converted to Metrics Scopes weeks ago. There is no additional action required and you can start taking advantage of the additional features of Metrics Scopes today.

Get Started

Companies that are digitally native or in the process of digital transformation have placed an increased operational role on developers and this often creates overlapping sets of responsibilities with Operations and SRE teams. Now multiple developer teams can focus on optimizing the performance of their applications while operators can take a fleet-wide view when maintaining and improving the performance of all of the infrastructure under their purview.For information on configuring a Metrics Scope to include metrics for multiple projects, see Viewing metrics for multiple projects.

When your business is rapidly adding new employees, expanding to new countries, and always focused on staying ahead of the competition, you have to take a hard look at the tools that are slowing you down—and swap them out for better ones that can keep pace with the company. We’re expanding YoungCapital in Germany, which means more offices, more people, and more technology to make the business run smoothly. 

As we scale, Google Cloud tools like Chromebooks and G Suite help us grow our business efficiently. They free us up from sluggish, time-intensive technology that’s hard to maintain and repair, and give us the freedom to work together in faster, smarter ways.

Free from hours of device setup. Some months, there are as many as 40 new employees starting at YoungCapital—and as we continue to expand that number will continue to rise, especially now that we’ve opened three new offices in Germany. With our old Windows desktops, setting up new computers could take up to an hour per employee (which can add up to about 40 hours a month for IT). Today, using Chrome Enterprise tools, it takes about five minutes to get an Acer Spin or Pixelbook ready to hand off to a new hire—saving us more than three months per year of device setup time.

Free from VPNs. Our previous Windows machines required a complicated virtual private network (VPN) for accessing corporate files outside of the office. Using a VPN was complicated for our employees because the software wasn’t intuitive; if an employee had trouble signing into the VPN while at home or traveling, they could not log in and work as quickly as they needed to. With Chromebooks, all you need is an online connection to sign into G Suite to access files and work from anywhere. 

From our perspective, Chromebooks are resistant to threats like ransomware and phishing attacks, giving us confidence that our data can stay secure. With Chrome Enterprise Upgrade, our IT admins can strengthen security even further: for example, by enabling advanced security features that help block vulnerabilities, locking down lost or stolen devices right away, and setting device security policies in the cloud so devices everywhere are safer. 

Free from infrastructure. We used to have to invest in servers, and then add more time and money to keep them running. Now we don’t have to run the business on infrastructure or hire people to maintain it—we can just use Google’s cloud. NextNovate is helping us make the most of Google Cloud Platform, like integrating some of our proprietary applications with G Suite and building our own add-ons. For example, we created a button for Gmail that connects to our job candidate database; when candidates email us, we can click on the button and see their profiles and work experience. 

Free from multiple passwords and logins. Chrome Browser and G Suite with single sign-provider SAML are the portal to all the productivity apps our employees need. Once people log in to G Suite, they don’t have to remember a bunch of other user names and passwords. The IT team loves it too, because we don’t have to spend hours zeroing out passwords and creating new ones.

Free to manage cross-country devices easily in the cloud. Our four-person IT support team, which keeps our systems humming, hasn’t grown, even though we’ve doubled the number of employees. When we were on Windows devices, we fielded roughly 1,800 IT support requests every month. Now we get about 1,300 requests a month, from a much bigger employee base. This translates to nearly 30% fewer requests for our lean support team, which reduces their workload significantly even though we have roughly 20% more employees—all made possible with Chrome Enterprise. 

Being free of slow, high-maintenance technology doesn’t just make the IT department happy—people are actually changing how they work. They no longer send files to each other by email or struggle to keep track of versions; they store everything in Google Drive and work together in Google Docs on a single document at the same time. And instead of traveling to other offices, connecting with each other in video conferences on Hangouts Meet has become a completely natural way to do business.

With Chromebooks and G Suite, we’re ready for anything: more new markets, more employees, and more-flexible ways to work together and shake up the staffing industry.

Where should you run your workload? It depends…Choosing the right infrastructure options to run your application is critical, both for the success of your application and for the team that is managing and developing it. This post breaks down some of the most important factors that you need to consider when deciding where you should run your stuff!

What are these services?

• Compute Engine – Virtual machines. You reserve a configuration of CPU, memory, disk, and GPUs, and decide what OS and additional software to run.
• Kubernetes Engine – Managed Kubernetes clusters. Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. You create a cluster and configure which containers to run; Kubernetes keeps them running and manages scaling, updates and connectivity.
• Cloud Run – A fully managed serverless platform that runs individual containers. You give code or a container to Cloud Run, and it hosts and auto scales as needed to respond to web and other events.
• App Engine – A fully managed serverless platform for complete web applications. App Engine handles the networking, application scaling, and database scaling. You write a web application in one of the supported languages, deploy to App Engine, and it handles scaling, updating versions, and so on. 
• Cloud Functions – Event-driven serverless functions. You write individual function code and Cloud Functions calls your function when events happen (for example, HTTP, Pub/Sub, and Cloud Storage changes, among others). 

What level of abstraction do you need?

• If you need more control over the underlying infrastructure (for example, the operating system, disk images, CPU, RAM, and disk) then it makes sense to use Compute Engine. This is a typical path for legacy application migrations and existing systems that require a specific OS. 
• Containers provide a way to virtualize an OS so that multiple workloads can run on a single OS instance. They are fast and lightweight, and they provide portability. If your applications are containerized then you have two  main options. 
  • You can use Google Kubernetes Engine, or GKE, which gives you full control over the container down to the nodes with specific OS, CPU, GPU, disk, memory, and networking. GKE also offers Autopilot, when you need the flexibility and control but have limited ops and engineering support. 
  • If, on the other hand, you are just looking to run your application in containers without having to worry about scaling the infrastructure, then Cloud Run is the best option. You can just write your application code, package it into a container, and deploy it.  
• If you just want to code up your HTTP-based application and leave the scalability and deployment of the app to Google Cloud then App Engine — a serverless, fully-managed option that is designed for hosting and running web applications — is a good option for you. 
• If your code is a function and just performs an action based on an event/trigger, then deploying it with Cloud Functions makes sense. 

What is your use case? 

• Use Compute Engine if you are migrating a legacy application with specific licensing, OS, kernel, or networking requirements. Examples: Windows-based applications, genomics processing, SAP HANA.
• Use GKE if your application needs a specific OS or network protocols beyond HTTP/s. When you use GKE, you are using Kubernetes, which makes it easy to deploy and expand into hybrid and multi-cloud environments. Anthos is a platform specifically designed for hybrid and multi-cloud deployments. It provides single-pane-of-glass visibility across all clusters from infrastructure through to application performance and topology. Example: Microservices-based applications. 
• Use Cloud Run if you just need to deploy a containerized application in a programming language of your choice with HTTP/s and websocket support. Examples: websites, APIs, data processing apps, webhooks.
• Use App Engine if you want to deploy and host a web based application (HTTP/s) in a serverless platform. Examples: web applications, mobile app backends
• Use Cloud Functions if your code is a function and just performs an action based on an event/trigger from Pub/Sub or Cloud Storage. Example: Kick off a video transcoding function as soon as a video is saved in your Cloud Storage bucket.

Need portability with open source? 

If your requirement is based on portability and open-source support take a look at GKE, Cloud Run, and Cloud Functions. They are all based on open-source frameworks that help you avoid vendor lock-in and give you the freedom to expand your infrastructure into hybrid and multi-cloud environments.  GKE clusters are powered by the Kubernetes open-source cluster management system, which provides the mechanisms through which you interact with your cluster. Cloud Run for Anthos is powered by Knative, an open-source project that supports serverless workloads on Kubernetes. Cloud Functions use an open-source FaaS (function as a service) framework to run functions across multiple environments. 

What are your team dynamics like?

If you have a small team of developers and you want their attention focused on the code, then a serverless option such as Cloud Run or App Engine is  a good choice because you won’t have to have a team managing the infrastructure, scale, and operations. If you have bigger teams, along with your own tools and processes, then Compute Engine or GKE makes more sense because it enables you to define your own process for CI/CD, security, scale, and operations. 

What type of billing model do you prefer? 

Compute Engine and GKE billing models are based on resources, which means you pay for the instances you have provisioned, independent of usage. You can also take advantage of sustained and committed use discounts. 

Cloud Run, App Engine, and Cloud Functions are billed per request, which means you pay as you go. 

Conclusion

It’s important to consider all the relevant factors that play a role in picking appropriate compute options for your application. Remember that no decision is necessarily final; you can always move from one option to another.

To explore these points in more detail, please take a look at the “Where Should I Run My Stuff?” video.

For more #GCPSketchnote, follow the GitHub repo &  thecloudgirl.dev. For similar cloud content follow us on Twitter at @pvergadia and @briandorsey