Cloud Computing Köln - Seite 2284 von 7049 - Neues zu Cloud Computing, Internet of Things und Technologien

The Air Force Research Laboratory (AFRL) is a global research enterprise supporting two services, the U.S. Air Force and the U.S. Space Force. From laser-guided optics enabling telescopes to see deeper into the universe to fundamental science that has spawned innovations in quantum computing and artificial intelligence, AFRL rapidly scales discovery to deliver leading-edge technologies for the military. As an integral part of the nation’s defense, AFRL engages with world-leading scientists, small businesses, large industry, and other government agencies to build communities that drive innovation. And given the sensitive nature of its work, AFRL needs to maintain high levels of security, even with remote employees. To tackle these challenges, AFRL is deploying Google Workspace among a segment of its workforce of scientists and engineers. A single, secure platform for collaboration and innovationAs a leader in developing cutting-edge technology, AFRL needs flexibility, but also must meet rigorous security standards—while maintaining the agility to onboard new researchers quickly. AFRL teams are using Google Workspace solutions like Google Smart Canvas to simultaneously share, collaborate, and discuss research—eliminating the toil of email chains and hours-long data file exchanges. Through video conferencing service, Google Meet, some AFRL research teams are hosting flexible, virtual meetings to exchange ideas anywhere, anytime. The recent announcements of Workspace Client-Side Encryption, combined with Google’s Zero Trust security approach, provides AFRL additional safeguards, while keeping security measures invisible to end-users. Ultimately, the goal is to accelerate collaboration and innovation amongst AFRL scientists, while meeting the standards defined by the U.S. Defense Information Systems Agency (DISA).“Covid-19 significantly limited the physical presence of researchers in the lab,” said Dr. Joshua Kennedy, research physicist, Materials and Manufacturing Directorate at AFRL. “Google Workspace eliminated what would have otherwise been almost a total work stoppage. In fact, new insights into 2D nanomaterials, critical to future Department of the Air Force capabilities, were discovered using Workspace that would have otherwise been impossible.” Dr. Kennedy is just one of many researchers at AFRL who have reported a positive, tangible impact on their work as a result of using Google Workspace. For example, a recent survey of hundreds of researchers involved in the Google Workspace preliminary deployment revealed an average time savings of three hours per week. For AFRL’s highly trained workforce of PhDs, that means more time to dedicate to the mission.Secure collaboration for a global missionAFRL’s global workforce fuels the organization’s innovations, but its worldwide footprint is the source of one of its biggest challenges: How do you create a collaborative, secure, and adaptive environment for an advanced research organization without hampering its ability to innovate?In early fiscal year 2021, Air Force Research Laboratory commander Maj. Gen. Heather Pringle directed AFRL to prioritize ongoing efforts of digitally transforming AFRL and issued a charter establishing the AFRL Digital Transformation Team. The team’s charter outlines the vision of “One AFRL”—a flexible, synergistic enterprise “that capitalizes on the seamless integration of data and information through the use of modern methods, digital processes and tools and IT infrastructure.”“Our mantra is ‘collaborate to innovate,’” Pringle said. “We want our alpha nerds to be very connected, and we really want to up their proficiency as a digital workforce where data becomes a third language. We’re incorporating digital engineering into everything we do in science and technology and have a data-informed human capital strategy. We started experimenting with Google Workspace to supplement existing capabilities, and it has revolutionized our ability to collaborate with our external partners and build the best teams.”Learn more about how Google Cloud has worked with the U.S. Air Force to solve its toughest sustainment challenges and how Google Cloud is helping the Air Force transform future pilot training.
Quelle: Google Cloud Platform

4. November 2021

da Agency

Introducing GKE image streaming for fast application startup and autoscaling

We’re excited to announce the general availability of a new feature in Google Kubernetes Engine (GKE): image streaming. This revolutionary GKE feature has the potential to drastically improve your application scale-up time, allowing you to respond to increased user demand more rapidly, and save money by provisioning less spare capacity. We achieve this by reducing the image pull-time for your container from several minutes (in the case of large images) to a couple of seconds (irrespective of container size), and allowing your application to start booting immediately while GKE streams the container data in parallel.The way Kubernetes traditionally works when scaling up your application is that the entire container image must be downloaded onto the node before the application can boot. The bigger your container image, the longer this takes, despite the fact that most applications don’t actually need every byte of data in the container image to start booting (and some data in the container may even never be used). For example, your application may spend a bunch of time connecting to external databases, which barely requires any data from the container image. With image streaming, we asked ourselves, what if we could deliver to your application just the data it needs, when it needs it, rather than waiting for all that extra data to be downloaded first?Image streaming works by mounting the container data layer in containerd using a sophisticated network mount, and backing it with multiple caching layers on the network, in-memory and on-disk. Your container transitions from the ImagePulling status to Running in a couple of seconds (regardless of container size) once we prepare the image streaming mount; this effectively parallelizes the application boot with the data transfer of required data in the container image. As a result, you can expect to see much faster container boot times and snappier autoscaling. Image streaming performance varies, as it is highly dependent on your application profile. In general, though, the bigger your images, the greater the benefit you’ll see. Google Cloud partner Databricks saw an impressive reduction in overall application cold-startup times, which includes node boot-time.“With image streaming on GKE, we saw a 3X improvement in application startup time, which translates into faster execution of customer workloads, and lower costs for our customers by reducing standby capacity.” – Ihor Leshko, Senior Engineering Manager, DatabricksIn addition to parallelizing data delivery, GKE image streaming employs a multi-level caching system: It starts with an in-memory and on-disk cache on the node, and moves up to regionally replicated Artifact Registry caches designed specifically for image streaming which leverage the same technology as Cloud Spanner under the hood.Image streaming is completely transparent as far as your containerized application is concerned. Since the data your container reads is initially streamed over the network, rather than from the disk, raw read performance is slightly slower with image streaming than when the whole image is available on the disk. This effect is more than offset during container boot by the parallel nature of the design, as your container got a lengthy head start by skipping the whole image pull process. However, to achieve equal read performance once the application is running, GKE still downloads the complete container image in parallel, just like before. In other words, while GKE is downloading the container image, you get the parallelism benefits of image streaming; then, once it’s downloaded, you get the same on-disk read performance as before—for the best of both worlds.Getting started with GKE image streamingImage streaming is available today at no additional cost to users of GKE’s Standard mode of operation, when used with images from Artifact Registry, Google Cloud’s advanced registry for container images and other artifacts. Images in Container Registry, or external container registries, are not supported for image streaming optimization (they will continue to work, just without benefiting from image streaming), so now is a great time to migrate them to Artifact Registry if you haven’t already.You can use image streaming on both new and existing GKE clusters. Be sure to enable the Container Filesystem API, use the COS containerd node image variant, and reference container images that are hosted in Artifact Registry. In the UI, simply check the “enable image streaming” checkbox on the cluster creation page.Alternately, from the CLI, here’s how to create an image streaming cluster:You can also upgrade your existing clusters to enable image streaming through the UI, or by running:and then deploy your workload referencing an image from Artifact Registry. If everything worked as expected, you should notice your container entering the “Running” status about a second after the “ContainerCreating” status.To verify that image streaming was engaged as expected, runThe ImageStreaming event as seen in the example output above indicates that image streaming was engaged for this image pull.Since image streaming is only used until the image is fully downloaded to disk, you’ll need to test this on a fresh node to see the full effect. And remember, to get image streaming, you need to enable the API, turn on image streaming in your cluster, use the COS containerd image, and reference images from Artifact Registry. Image streaming does introduce an additional memory reservation on the node in order to provide the caching system, which reduces the memory available for your workloads on those nodes. For all the details, including further information on testing and debugging, check out the image streaming documentation. For more such capabilities register to join us live on Nov 18th for Kubernetes Tips and Tricks to Build and Run Cloud Native Apps.
Quelle: Google Cloud Platform

3. November 2021

da Agency

Service Directory cheat sheet

Most enterprises have a large number of heterogeneous services deployed across different clouds and on-premises environments. It is complex to look up, publish, and connect these services, but it is necessary to do so for deployment velocity, security, and scalability. That’s where Service Directory comes in! Service Directory is a fully managed platform for discovering, publishing, and connecting services, regardless of the environment. It provides real-time information about all your services in a single place, enabling you to perform service inventory management at scale, whether you have a few service endpoints or thousands. Click to enlargeWhy Service Directory?Imagine that you are building a simple API and that your code needs to call some other application. When endpoint information remains static, you can hard-code these locations into your code or store them in a small configuration file. However, with microservices and multi-cloud, this problem becomes much harder to handle as instances, services, and environments can all change.Service Directory solves this! Each service instance is registered with Service Directory, where it is immediately reflected in Domain Name System (DNS) and can be queried by using HTTP/gRPC regardless of its implementation and environment. You can create a universal service name that works across environments, make services available over DNS, and apply access controls to services based on network, project, and IAM roles of service accounts.Service Directory solves the following problems:Interoperability: Service Directory is a universal naming service that works across Google Cloud, multi-cloud, and on-premises. You can migrate services between these environments and still use the same service name to register and resolve endpoints.Service management: Service Directory is a managed service. Your organization does not have to worry about the high availability, redundancy, scaling, or maintenance concerns of maintaining your own service registry.Access control: With Service Directory, you can control who can register and resolve your services using IAM. Assign Service Directory roles to teams, service accounts, and organizations.Limitations of pure DNS: DNS resolvers can be unreliable in terms of respecting TTLs and caching, cannot handle larger record sizes, and do not offer an easy way to serve metadata to users. In addition to DNS support, Service Directory offers HTTP and gRPC APIs to query and resolve services.How Service Directory works with Load BalancerHere’s how Service Directory works with Load Balancer:In Service Directory, Load Balancer is registered as a provider of each serviceThe client performs a service lookup via Service DirectoryService Directory returns the Load Balancer addressThe client makes a call to the service via Load Balancer.Using Cloud DNS with Service DirectoryCloud DNS is a fast, scalable, and reliable DNS service running on Google’s infrastructure. In addition to public DNS zones, Cloud DNS also provides a managed internal DNS solution for private networks on Google Cloud. Private DNS zones enable you to internally name your virtual machine (VM) instances, load balancers, or other resources. DNS queries for those private DNS zones are restricted to your private networks. Here is how you can use Service Directory zones to make service names available using DNS lookups.The endpoints are registered directly with Service Directory using the Service Directory API. This can be done for both Google Cloud and non-Google Cloud services.Both external and internal clients can look up those services at: https://servicedirectory.googleapis.comTo enable DNS requests, create a Service Directory zone in Cloud DNS that is associated with a Service Directory namespace.Internal clients can resolve this service via DNS, HTTP, or gRPC. External clients (clients not on the private network) must use HTTP or gRPC to resolve service names.For a more in-depth look into Service Directory check out this documentation. For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev Related ArticleIntegrating Service Directory with GKE: one registry for all your servicesYou can now register Google Kubernetes Engine (GKE) services in Service Directory, Google Cloud’s managed service registry.Read Article
Quelle: Google Cloud Platform

The move follows a pair of BuzzFeed News investigations revealing widespread and sometimes unsanctioned use of the company’s facial recognition software by law enforcement agencies around the world.