New climate model data now in Google Public Datasets

Exploring public datasets is an important aspect of modern data analytics, and all this gathered data can help us understand our world. At Google Cloud, we maintain a collection of public datasets, and we’re pleased to collaborate with the Lamont-Doherty Earth Observatory (LDEO) of Columbia University and the Pangeo Project to host the latest climate simulation data in the cloud. The World Climate Research Programme (WCRP) recently began releasing the Coupled Model Intercomparison Project Phase 6 (CMIP6) data archive, aggregating the climate models created across approximately 30 working groups and 1,000 researchers investigating the urgent environmental problem of climate change. The CMIP6 climate model datasets include rich details on many aspects of the climate system, including historical and future simulations. The data are now accessible in Cloud Storage and will be in BigQuery soon. Along with making CMIP6 available on Google Cloud, the Pangeo Project develops software and infrastructure to make it easier to analyze and visualize climate data using cloud computing.On Google Cloud, this dataset will be continuously updated and available to researchers around the globe to use for their own projects—without the constraints of downloading terabytes or even petabytes of data. The entire archive may eventually contain 20 PB of data, of which about 100 TB of data are currently available in the cloud. You can request data from Pangeo’s CMIP6 Google Cloud Collection in this form.“It’s a very live data set. It’s going to be updated over the next year as the data come online and as people’s needs arise,” says Ryan Abernathey, associate professor of Earth and environmental sciences at Columbia University and LDEO. He emphasizes the practical impact of this project. “What people actually care about most is not the global mean temperature because no one lives in the ‘global mean world.’ People care about the local impacts of drought or extreme rainfall, which can cause severe hardship for society. With these high-resolution simulations of rare events, we get much better information for planning in response to expected changes in the climate.”What you’ll find in the CMIP6 dataThe models in CMIP6’s data range from high-resolution simulations based on historical data from 1850 onward to hypothetical scenarios that manipulate key variables. For example, Abernathey asks, “What if carbon dioxide (CO2) were to instantaneously quadruple its concentration overnight? That’s a very useful experiment, not because it helps us make a detailed projection about the future, but because it helps us probe our physical understanding of how the climate system responds to CO2.” Each of the CMIP6 models includes dozens of variables, ensemble members, and scenarios, leading to large, unwieldy datasets. But Pangeo, an ensemble of open-source Python tools for big data analysis, makes it easier to perform large-scale computations on CMIP6 and other similar large datasets.To help researchers work with the multidimensional datasets of climate research, Abernathey and his colleagues at LDEO and the National Center for Atmospheric Research (NCAR) drew on funding from the National Science Foundation (NSF) and computing support from Google Cloud to develop Pangeo, which is an open-source platform aimed at accelerating geoscience data analysis. Pangeo can be run on nearly any high-performance computing system, including Google Kubernetes Engine (GKE), which supports easy deployment with autoscaling (both up and down) and integration with other Google Cloud tools such as Cloud Storage and BigQuery. The Pangeo community shares expertise, such as use cases for different domain-specific applications, and contributes to the development of open-source tools, like a cloud-optimized data storage format called Zarr.”The CMIP project has grown since its early days, and now is seeing tremendous growth beyond the U.S. and E.U. into the developing world,” says V. Balaji, a computational climate scientist on leave from Princeton University. Currently at the Institut Pierre-Simon Laplace in Paris, Balaji has been involved with all aspects of CMIP, from defining the experiments and running the simulations to analyzing the output and designing the Earth System Grid Federation (ESGF), a network of services that underpin the global data infrastructure enabling this critical research enterprise. “For new entrants, and for academic researchers worldwide, Pangeo in the cloud represents an exciting new opportunity to broaden the user base of very large-scale climate data, without the need to acquire supercomputer-scale storage and analysis facilities,” says Balaji. “It bridges what I call the gap between ‘inspiration-driven’ and ‘industrial strength’ science, enabling a scientist to explore the data and design their own analysis, and immediately apply their findings at very large scale. The progress of Pangeo in the cloud will inform our own architectural choices in designing the future of the global climate data infrastructure.”With these high-resolution simulations of rare events, we get much better information for planning in response to expected changes in the climate.The Pangeo team at LDEO and NCAR recently hosted a hackathon to jumpstart the analysis of the CMIP6 data on Google Cloud for pressing scientific questions. One participant—Henri Drake, a Ph.D. candidate in MIT’s Program in Atmospheres, Oceans, and Climate—created a tutorial for analyzing simulations of global warming in state-of-the-art CMIP6 models, under the worst-case scenario of uncontrolled greenhouse gas emissions. These CMIP6 model projections “reflect millions of lines of model code and represent everything from forest transpiration in the Amazon rainforest and thunderstorms in the U.S. Midwest to the formation of meltwater ponds on Arctic sea ice,” says Drake. “We would need a huge supercomputer to run the simulations from the model source code ourselves. Thankfully, the climate modeling community does this for us by making their output publicly available.”Drake used these tutorials as a teaching assistant for the Climate Change course at MIT to demonstrate the ease of cloud computing for data-intensive climate science research, and also the value of open-source tools like the Pangeo software stack on Google Cloud. “The CMIP6 dataset was already technically publicly available, it just was not very accessible,” says Drake. “The cloud-based data and computation, when combined with the Pangeo software stack, enabled me to make calculations in just a few hours that could have taken weeks using more conventional methods. Using the Pangeo binder, it was easy to make these calculations available to the rest of the world.”The CMIP6 data join many other weather and climate-related datasets available through Google’s Public Dataset program at no charge. By making data more accessible and usable with BigQuery and Cloud Storage, we support academic research by accelerating discoveries and promoting innovative solutions to complex problems. For Abernathey, the benefits of cloud computing are a particularly good match for the needs of scientific research: “With Google Cloud, you’ve essentially got a supercomputer just sitting right there, so you can directly process the data at a very high speed.”Get started with your own project by requesting data here.
Quelle: Google Cloud Platform

Building Xbox game streaming with Site Reliability best practices

Last month, we started sharing the DevOps journey at Microsoft through the stories of several teams at Microsoft and how they approach DevOps adoption. As the next story in this series, we want to share the transition one team made from a classic operations role to a Site Reliability Engineering (SRE) role: the story of the Xbox Reliability Engineering and Operations (xREO) team.

This transition was not easy and came out of necessity when Microsoft decided to bring Xbox games to gamers wherever they are through cloud game streaming (project xCloud). In order to deliver cutting-edge technology with top-notch customer experience, the team had to redefine the way it worked—improving collaboration with the development team, investing in automation, and get involved in the early stages of the application lifecycle. In this blog, we’ll review some of the key learnings the team collected along the way. To explore the full story of the team, see the journey of the xREO team.

Consistent gameplay requirements and the need to collaborate

A consistent experience is crucial to a successful game streaming session. To ensure gamers experience a game streamed from the cloud, it has to feel like it is running on a nearby console. This means creating a globally distributed cloud solution that runs on many data centers, close to end users. Azure’s global infrastructure makes this possible, but operating a system running on top of so many Azure regions is a serious challenge.

The Xbox developers who have started architecting and building this technology understood that they could not just build this system and “throw it over the wall” to operations. Both teams had to come together and collaborate through the entire application lifecycle so the system can be designed from the start with considerations on how it will be operated in a production environment.

Architecting a cloud solution with operations in mind

In many large organizations, it is common to see development and operation teams working in silos. Developers don’t always consider operation when planning and building a system, while operations teams are not empowered to touch code even though they deploy it and operate it in production. With an SRE approach, system reliability is baked into the entire application lifecycle and the team that operates the system in production is a valued contributor in the planning phase. In a new approach, involving the xREO team in the design phase enabled a collaborative environment, making joint technology choices and architecting a system that could operate with the requirements needed to scale.

Leveraging containers to clearly define ownership

One of the first technological decisions the development and xREO teams made together was to implement a microservices architecture utilizing container technologies. This allowed the development teams to containerize .NET Core microservices they would own and remove the dependency from the cloud infrastructure that was running the containers and was to be owned by the xREO team.

Another technological decision both teams made early on, was to use Kubernetes as the underlying container orchestration platform. This allowed the xREO team to leverage Azure Kubernetes Service (AKS), a managed Kubernetes cloud platform that simplifies the deployment of Kubernetes clusters, removing a lot of the operational complexity the team would have to face running multiple clusters across several Azure regions. These joint choices made ownership clear—the developers are responsible for everything inside the containers and the xREO team is responsible for the AKS clusters and other Azure services make the cloud infrastructure hosting these containers. Each team owns the deployment, monitoring and operation of its respective piece in production.

This kind of approach creates clear accountability and allows for easier incident management in production, something that can be very challenging in a monolithic architecture where infrastructure and application logic have code dependencies and are hard to untangle when things go sideways.

Scaling through infrastructure automation

Another best practice the xREO team invested in was infrastructure automation. Deploying multiple cloud services manually on each Azure region was not scalable and would take too much time. Using a practice known as “infrastructure as code” (IaC) the team used Azure Resource Manager templates to create declarative definitions of cloud environments that allow deployments to multiple Azure regions with minimal effort.

With infrastructure managed as code, it can also be deployed using continuous integration and continuous delivery (CI/CD) to bring further automation to the process of deploying new Azure resources to existing data centers, updating infrastructure definitions or bringing online new Azure regions when needed. Both IaC and CI/CD, allowed the team to remain lean, avoid repetitive mundane work and remove most of the risk of human error that comes with manual steps. Instead of spending time on manual work and checklists, the team can focus on further improving the platform and its resilience.

Site Reliability Engineering in action 

The journey of the xREO team started with a need to bring the best customer experience to gamers. This is a great example that shows how teams who want to delight customers with new experiences through cutting edge innovation must evolve the way they design, build, and operate software. Shifting their approach to operations and collaborating more closely with the development teams was the true transformation the xREO team has undergone.

With this new mindset in place, the team is now well positioned to continue building more resilience and further scale the system and by so, deliver the promise of cloud game streaming to every gamer.

Resources

The full story of the xREO team
Additional stories: The DevOps journey at Microsoft
Microsoft Game Stack

Quelle: Azure

Raumfahrt: Die Esa lässt den Weltraum säubern

Es ist voll in der Erdumlaufbahn: Immer mehr Satelliten kreisen im Orbit, und auch immer mehr Weltraumschrott. Die einzige Möglichkeit, des Problems Herr zu werden, ist laut Esa, ihn zu beseitigen. Für 2025 ist die erste europäische Aufräummission geplant. (Weltraumschrott, Raumfahrt)
Quelle: Golem

Announcing the preview of Azure Spot Virtual Machines

We’re announcing the preview of Azure Spot Virtual Machines. Azure Spot Virtual Machines provide access to unused Azure compute capacity at deep discounts. Spot pricing is available on single Virtual Machines in addition to Virtual Machine Scale Sets (VMSS). This enables you to deploy a broader variety of workloads on Azure while enjoying access to discounted pricing. Spot Virtual Machines offer the same characteristics as a pay-as-you-go Virtual Machines, with differences in pricing and evictions. Spot Virtual Machines can be evicted anytime if Azure needs capacity.

The workloads that are ideally suited to run on Spot Virtual Machines include, but are not necessarily limited to, the following:

•    Batch jobs.
•    Workloads that can sustain and/or recover from interruptions.
•    Development and test.
•    Stateless applications that can use Spot Virtual Machines to scale out, opportunistically saving cost.
•    Short-lived jobs which can easily be run again if the Virtual Machine is evicted.

Preview for Spot Virtual Machines will replace the preview of Azure low-priority Virtual Machines on scale sets. Eligible low-priority Virtual Machines will be automatically transitioned over to Spot Virtual Machines. Please refer to the FAQ for additional information. 

Pricing

Unlike low-priority Virtual Machines, prices for Spot Virtual Machines will vary based on capacity for a size or SKU in an Azure region. Spot pricing can give you insights into the availability and demand for a given Azure Virtual Machine series and specific size in a region. The prices will change slowly to provide stabilization, thus allowing you to better manage budgets. In the Azure portal, you will have access to the current Azure Virtual Machine Spot prices to easily determine which region or Virtual Machine size best fits your needs. Spot prices are capped at pay-as-you-go prices.
 

Deployment

Spot Virtual Machines are easy to deploy and manage. Deploying a Spot Virtual Machine is similar to configuring and deploying a regular Virtual Machine. For example, in the Azure portal, you can simply select Azure Spot Instance to deploy a Spot Virtual Machine. You can also define your maximum price for your Spot Virtual Machines. Here are two options: 

You can choose to deploy your Spot Virtual Machines without capping the price. Azure will charge you the Spot Virtual Machine price at any given time, giving you peace of mind that your Virtual Machines will not be evicted for price reasons.
 
Alternatively, you can decide to provide a specific price to stay in your budget. Azure will not charge you above the maximum price you set and will evict the Virtual Machine if the spot price rises above your defined maximum price.
 

There are few other options available to lower costs.

If your workload does not require a specific Virtual Machine series and size, then you can find other Virtual Machines in the same region that may be cheaper.
If your workload is not dependent on a specific region, then you can find a different Azure region to reduce your cost.

Quota

As part of this announcement, to give better flexibility, Azure is also rolling out a separate quota for Spot Virtual Machines that is separate from your pay-as-you-go Virtual Machine quota. The quota for Spot Virtual Machines and Spot VMSS instances is a single quota for all Virtual Machine sizes in a specific Azure region. This approach will give you easy access to a broader set of Virtual Machines.
 

Handling Evictions

Azure will try to keep your Spot Virtual Machine running and minimize evictions, but your workload should be prepared to handle evictions as runtime for an Azure Spot Virtual Machines and VMSS instances is not guaranteed. You can optionally get a 30-second eviction notice by subscribing to scheduled events. Virtual Machines can be evicted due to the following reasons:

Spot prices have gone above the max price you defined for the Virtual Machine. Azure Spot Virtual Machines get evicted when the Spot price for the Virtual Machine you have chosen goes above the price you defined at the time of deployment. You can try to redeploy your Virtual Machine by changing prices.
Azure needs to reclaim capacity.

In both scenarios, you can try to redeploy the Virtual Machine in the same region or availability zone.

Best practices

Here are some effective ways to best utilize Azure Spot Virtual Machines:

For long-running operations, try to create checkpoints so that you can restart your workload from a previous known checkpoint to handle evictions and save time.
In scale-out scenarios, to save costs, you can have two VMSS, where one has regular Virtual Machines and the other has Spot Virtual Machines. You can put both in the same load balancer to opportunistically scale out.
Listen to eviction notifications in the Virtual Machine to get notified when your Virtual Machine is about to be evicted.
If you are willing to utilize pay-as-you-go prices, then use Eviction type to “Capacity Eviction only”, in the API provide “-1” as max price as Azure never charges you more than the Spot Virtual Machine price.
To handle evictions, build a retry logic to redeploy Virtual Machines. If you do not require a specific Virtual Machine series and size, then try to deploy a different size that matches your workload needs.
While deploying VMSS, select max spread in portal management tab or FD==1 in the API to find capacity in a zone or region.

Learn more

Spot Virtual Machine details
Spot Virtual Machine pricing: Windows and Linux
Create Spot Virtual Machines in Portal
Create Spot Virtual Machines in Azure CLI
Create Spot Virtual Machines in Azure PowerShell
Create Spot Virtual Machines in Azure Resource Manager templates
Create Spot VMSS in Azure Resource Manager templates
Planned Azure Batch support for Spot Virtual Machines 

Quelle: Azure