New disk support capabilities in Azure Storage Explorer

The release of Storage Explorer 1.10.0 brings many exciting updates and new features that we hope can help you be more productive and efficient when working with your Azure Storage Accounts. If you’ve never used Storage Explorer before, make sure to head to our product page, and download it for your favorite operating system. In this post, we’ll go over the newly added support for virtual machine (VM) disk management that was added in the 1.10.0 release.

Easily backup and restore VMs with disk support

Managed disks have been simplifying Azure VM creation and maintenance over page blobs, blob containers and storage accounts. Today, Azure managed disks are the default storage option for Azure IaaS VMs. Recently, we introduced the Direct Upload API that allows you to upload data from on-premises without staging the data in a storage account. Azure Storage Explorer further simplifies those tasks by providing performant upload and download capabilities for creating and accessing managed disks. Here are two example scenarios for how the new features benefit customers like you:

We learned it is common to migrate VMs from on-premises to Azure. With Storage Explorer you can conveniently perform this task using the following steps in the documentation.

Figure 1: Upload a VHD using Storage Explorer

Backup and restore operations are also very common practices in customers’ disaster recovery strategy. A typical scenario is rolling back VMs to last known good version by restoring disks from snapshots after a regional outage or an application upgrade failure.

The workflow is now simplified with managed disks support in Storage Explorer. In the 1.10.0 release you can snapshot a disk just like any other blob to back up the current version. In upcoming releases, we will fully support creating disks from snapshots to complete the end-to-end scenario.

Figure 1: Capturing snapshot of VHDs from an Azure VM

Next steps

Download Storage Explorer 1.10.0 today and start efficiently managing your VMs and disks. If you have any feedback, please make sure to open a new issue on our GitHub repo. If you are experiencing difficulties using the product, please open a support ticket following these instructions.
Quelle: Azure

Designing Your First Application in Kubernetes, Part 3: Communicating via Services

I reviewed the basic setup for building applications in Kubernetes in part 1 of this blog series, and discussed processes as pods and controllers in part 2. In this post, I’ll explain how to configure networking services in Kubernetes to allow pods to communicate reliably with each other.
Setting up Communication via Services 
At this point, we’ve deployed our workloads as pods managed by controllers, but there’s no reliable, practical way for pods to communicate with each other, nor is there any way for us to visit any network-facing pod from outside the cluster. Kubernetes networking model says that any pod can reach any other pod at the target pod’s IP by default, but discovering those IPs and maintaining that list while pods are potentially being rescheduled — resulting in them getting an entirely new IP — by hand would be a lot of tedious, fragile work.
Instead, we need to think about Kubernetes services when we’re ready to start building the networking part of our application. Kubernetes services provide reliable, simple networking endpoints for routing traffic to pods via the fixed metadata defined in the controller that created them, rather than via unreliable pod IPs. For simple applications, two services cover most use cases: clusterIP and nodePort services. This brings us to another decision point:
Decision #3: What kind of services should route to each controller? 
For simple use cases, you’ll choose either clusterIP or nodePort services. The simplest way to decide between them is to determine whether the target pods are meant to be reachable from outside the cluster or not. In our example application, our web frontend should be reachable externally so users can access our web app.
In this case, we’d create a nodePort service, which would route traffic sent to a particular port on any host in your Kubernetes cluster onto our frontend pods (Swarm fans: this is functionally identical to the L4 mesh net).
A Kubernetes nodePort service allows external traffic to be routed to the pods.
For our private API + database pods, we may only want them to be reachable from inside our cluster for security and traffic control purposes. In this case, a clusterIP service is most appropriate. The clusterIP service will provide an IP and port which only other containers in the cluster may send traffic to, and have it forwarded onto the backend pods.
A Kubernetes clusterIP service only accepts traffic from within the cluster.
Checkpoint #3: Write some yaml and verify routing
Write some Kubernetes yaml to describe the services you choose for your application and make sure traffic gets routed as you expect.
Advanced Topics
The simple routing and service discovery above will get pods talking to other pods and allow some simple ingress traffic, but there are many more advanced patterns you’ll want to learn for future applications:

Headless Services can be used to discover and route to specific pods; you’ll use them for stateful pods declared by a statefulSet controller.
Kube Ingress and IngressController objects provide managed proxies for doing routing at layer 7 and implementing patterns like sticky sessions and path-based routing.
ReadinessProbes work exactly like the healthchecks mentioned above, but instead of managing the health of containers and pods, they monitor and respond to their readiness to accept network traffic.
NetworkPolicies allow for the segmentation of the normally flat and open Kubernetes network, allowing you to define what ingress and egress communication is allowed for a pod, preventing access from or to an unauthorized endpoint.

For additional information on these topics, have a look at the Kubernetes documentation:

Kubernetes Services
Kubernetes Cluster Networking

You can also check out Play with Kubernetes, powered by Docker.
We will also be offering training on Kubernetes starting in early 2020. In the training, we’ll provide more specific examples and hands on exercises.To get notified when the training is available, sign up here:
Get Notified About Training

Designing Your First App in #Kubernetes, Part 3 — Communication via ServicesClick To Tweet

The post Designing Your First Application in Kubernetes, Part 3: Communicating via Services appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

From stamp machines to cloud services: The Pitney Bowes transformation

Editor’s note:James Fairweather, chief innovation officer at Pitney Bowes, has played a key role in modernizing the product offerings at this century-old global provider of innovative shipping solutions for businesses of all sizes. In today’s post, he discusses some key challenges the Pitney Bowes team overcame during its digital transformation, and some of the benefits it has enjoyed from building new digital competencies.Pitney Bowes will celebrate its 100th birthday in April 2020. Over the past century, we’ve enjoyed great success in markets associated with shipping and mailing. Yet, as with so many established and successful enterprises, we faced slowing growth in the markets that served us so well for so long. While package growth was accelerating, the mail market was declining, creating opportunities and challenges.To change our growth trajectory and “build a bridge” to Pitney Bowes’ second century, we needed to offer more value to our clients. We needed to move to growth markets, and that required new digital competencies. In 2015, we began a deliberate journey to transform our services, including shipping and location intelligence, for the digital world and make them available via the cloud. We learned a lot throughout this journey. In this post we’ll take a look at three things, in particular, that led to the success of this project—and will help future projects succeed, as well.Setting expectations and realistic milestonesOrganizations tend to undertake product development with a sense of optimism—and it’s often not particularly realistic. You set out thinking something will take a certain amount of time and that you will incur a specific cost, but estimates in technology and development may be optimistic, and costs almost always incrementally increase throughout the development process. With a digital transformation effort, there’s an additional challenge: You aren’t really heading to a well-defined destination, so the path your team takes can be even more ambiguous. Digital transformation doesn’t have an end state. It’s a process of constant evolution.For these reasons, and more, it’s important to set informed, realistic expectations—in schedule, in budget, in project scope. It’s also critical that you identify milestones along the way, and recognize and celebrate when you reach them.When you’re working on a massive, multi-year corporate transformation, after all, it can be hard to recognize that every little action you take each week, everything you win day-to-day, is a part of your progress, your change. So, it’s really important, as a leader, to bring consistency and execution discipline—and be able to point to the progress being made and celebrate accomplishments.We did our best to follow this advice during our digital transformation. Late 2015 was a critical time for Pitney Bowes as we laid out the technology strategy that would get us to the next century. We were aware of the potential hazards that could arise. You set the strategy, celebrate its publication as an accomplishment… and then nothing happens. To avoid this issue, we broke our strategy out into specific tactics supported by numerous smaller, interim goals. When we started putting big, green checkmarks next to each accomplished milestone, people started realizing that we were making real progress, and were serious about our execution.One key milestone, for example, was implementing an API management platform. This comprised several granular goals: Selecting a partner, training a subset of our 1,100 team members on the platform, and rolling out our first offering that was built on top of that capability. We knew that an API platform would be a key part of our digital transformation for three major reasons. First, we had acquired several companies, but their technologies were difficult to share for use cases across the organization. Every time a team needed to use our geocoding or geoprocessing capability, for example, they had to spin up a new environment. By building these capabilities as APIs across the organization, it made it easy to democratize their usage and speed up development. Secondly, we were running a big enterprise business system platform transformation program and wanted our product teams to be able to consume data from our back-end business systems. This meant that we needed a solid catalog of all these services, so new members of the team could easily find and use them.Finally, we had a couple of business units that wanted to go to market with APIs. They had a business strategy that entailed selling a service or value, with a vision to build a platform or ecosystem around these capabilities. An API platform (specifically, Google Cloud’s Apigee API management platform) is a huge accelerant in enabling all three of these objectives—it’s how you do this well.Reusability and the Commerce CloudThe Apigee platform and team helped us build a key offering that arose from our digital transformation: the Pitney Bowes Commerce Cloud. It’s a set of cloud-based solutions and APIs that are built on our assets and connect our new cloud solutions to our enterprise business systems, such as billing and package management.Today, we have close to 200 APIs delivered from the Commerce Cloud in the areas of location intelligence, shipping, and global ecommerce. The Commerce Cloud isn’t just a success as a customer-facing platform, however. We often talk about whether our development teams themselves have leveraged its services when developing new products. These discussions help us understand whether a product team has thought through the digital capabilities we’ve already built, assessed which capabilities fits into its roadmap, and adopted the right technology, capabilities, and practices to align with our corporate digital transformation strategy.Internal use of these shareable services shaves up to 70% off of our design cycles, because so many decisions are already made. Commerce Cloud adoption means you’ve gotten on the path internally, lowered the friction, and are aligned with the broader company digital transformation strategy. Measuring successWe’re proud of what we’ve accomplished so far at Pitney Bowes. But pride only takes you so far. To determine a project’s success, you need to be able to measure it. We do have some encouraging external measures: our percentage of revenue from new products climbed to roughly 20% of sales in 2018, compared to 5% back in 2012. And our Shipping APIs, which enable customers to integrate U.S. Postal Service capabilities into their own solutions, has gone from a standing start to an over $100 million business in a few years.On top of those external results, our business has transformed. We’re no longer just participating in a one-time sale of a product, software, or services; we’re participating in transactions every day that drive client outcomes. The more you can improve the quality and effectiveness of those services, the more you and your client enjoy the benefits of the commercial relationship. That’s a very big business model transformation for Pitney Bowes.We’ve also sped up our time to market and tightened our service-level agreements. But perhaps most importantly, we’ve developed and adopted a new set of internal processes and a mindset that helps us quickly adapt to changing market conditions. Again, digital transformation isn’t a destination. It’s really a set of processes that enable us to be nimble and keep building a bridge to Pitney Bowes’ future.For more on the Pitney Bowes transformation, check out these videos and this case study.
Quelle: Google Cloud Platform

Building ML models for everyone: understanding fairness in machine learning

Fairness in data, and machine learning algorithms is critical to building safe and responsible AI systems from the ground up by design. Both technical and business AI stakeholders are in constant pursuit of fairness to ensure they meaningfully address problems like AI bias. While accuracy is one metric for evaluating the accuracy of a machine learning model, fairness gives us a way to understand the practical implications of deploying the model in a real-world situation. Fairness is the process of understanding bias introduced by your data, and ensuring your model provides equitable predictions across all demographic groups. Rather than thinking of fairness as a separate initiative, it’s important to apply fairness analysis throughout your entire ML process, making sure to continuously reevaluate your models from the perspective of fairness and inclusion. This is especially important when AI is deployed in critical business processes, like credit application reviews and medical diagnosis, that affect a wide range of end users. For example, the following is a typical ML lifecycle:Below, in yellow, are some ways ML fairness can be applied at various stages of your model development:Instead of thinking of a deployed model as the end of the process, think of the steps outlined above as a cycle where you’re continually evaluating the fairness of your model, adding new training data, and re-training. Once the first version of your model is deployed, it’s best to gather feedback on how the model is performing and take steps to improve its fairness in the next iteration.In this blog we’ll focus on the first three fairness steps in the diagram above: identifying dataset imbalances, ensuring fair treatment of all groups, and setting prediction thresholds. To give you concrete methods for analyzing your models from a fairness perspective, we’ll use the What-if Tool on models deployed on AI Platform. We’ll specifically focus on the What-if Tool’s Fairness & Performance tab, which allows you to slice your data by individual features to see how your model behaves on different subsets.We’ll be using this housing dataset from Kaggle throughout this post to show you how to perform fairness analysis in the What-if Tool. As you can see in the preview below, it includes many pieces of data on a house (square feet, number of bedrooms, kitchen quality, etc.) along with its sale price. In this exercise, we’ll be predicting whether a house will sell for more or less than $160k.While the features here are specific to housing, the goal of this post is to help you think about how you can apply these concepts to your own dataset, which is especially important when the dataset deals with people. Identifying dataset imbalancesBefore you even start building a model, you can use the What-if Tool to better understand dataset imbalances and see where you might need to add more examples. With the following snippet, we’ll load the housing data as a Pandas DataFrame into the What-if Tool:When the visualization loads, navigate to the Features tab (note that we’ve done some pre-processing to turn categorical columns into Pandas dummy columns):Here are some things we want to be aware of in this dataset:This dataset is relatively small, with 1,460 total examples. It was originally intended as a regression problem, but nearly every regression problem can be converted to classification. To highlight more What-if Tool features, we turned it into a classification problem to predict whether a house is worth more or less than $160k.Since we’ve converted it to a classification problem, we purposely chose the $160k threshold to make the label classes as balanced as possible—there are 715 houses less than $160k and 745 worth more than $160k. Real world datasets are not always so balanced. The houses in this dataset are all in Ames, Iowa and the data was collected between 2006 and 2010. No matter what accuracy our model achieves, it wouldn’t be wise to try generating a prediction on a house in an entirely different metropolitan area, like New York City.Similar to the point above, the ”Neighborhood” column in this data is not entirely balanced—North Ames has the most houses (225) and College Circle is next with 150.There may also be missing data that could improve our model. For example, the original dataset includes data on a house’s basement type and size which we’ve left out of this analysis. Additionally, what if we had data on the previous residents of each house? It’s important to think about all possible data sources, even if it will require some feature engineering before feeding it into the model. It’s best to do this type of dataset analysis before you start training a model so you can optimize the dataset and be aware of potential bias and how to account for it. Once your dataset is ready, you can build and train your model and connect it to the What-if Tool for more in-depth fairness analysis.Connecting your AI Platform model to the What-if ToolWe’ll use XGBoost to build our model, and you can find the full code on GitHub and AI Hub. Training an XGBoost model and deploying it to AI Platform is simple:Now that we’ve got a deployed model, we can connect it to the What-if Tool:Running the code above should result in the following visualization:If you select Partial dependence plots on the top left, you can see how individual features impact the model’s prediction  for an individual data point (if you have one selected), or globally across all data points. In the global dependence plots here, we can see that the overall quality rating of a house had a significant effect on the model’s prediction (price increases as quality rating increases) but the number of bedrooms above ground did not:For the rest of this post we’ll focus on fairness metrics.Getting started with the Fairness tabOn the top left of the visualization, select the Performance & Fairness tab. This is what you’ll see first:There’s a lot going on! Let’s break down what we’re looking at before we add any configuration options. In the “Explore overall performance” section, we can see various metrics related to our model’s accuracy. By default the Threshold slider starts at 0.5. This means that our model will classify any prediction value above 0.5 as over $160k, and anything less than 0.5 will be classified as less than $160k. The threshold is something you need to determine after you’ve trained your model, and the What-if Tool can help you determine the best threshold value based on what you want to optimize for (more on that later). When you move the threshold slider you’ll notice that all of the metrics change:The confusion matrix tells us the percentage of correct predictions for each class (the four squares add up to 100%). ROC and Precision / Recall (PR) are also common metrics for model accuracy. We’ll get the best insights from this tab once we start slicing our data. Applying optimization strategies to data slicesIn the Configure section in the top left of the What-if Tool, select a feature from the Slice by dropdown. First, let’s look at “GarageType_Attchd”, which indicates whether the garage is attached to the house (0 for no, 1 for yes):Notice that houses with an attached garage have a higher likelihood that our model will value them at more than $160k. In this case the data has already been collected, but let’s imagine that we wanted our model to price houses with attached and unattached garages in the same way. In this example we care most about having the same percentage of positive classifications across classes, while still achieving the highest possible accuracy within that constraint. For this we should select Demographic parity from the Fairness section on the bottom left:You’ll notice that our threshold sliders and accuracy metrics change when we set this strategy:What do all these changes mean? If we don’t want the garage placement to influence our model’s price, we need to use different thresholds for houses depending on whether their garage is attached. With these updated thresholds, the model will predict the house to be worth over $160k when the prediction score is .99 or higher. Alternatively, a house without an attached garage should be classified as over $160k if the model predicts 0.52 or higher.If we instead use the “Equal opportunity” strategy, it will optimize for high accuracy predictions within the positive class and ensure an equal true positive rate across data slices. In other words, this will choose the thresholds that ensure houses that are likely worth over $160k are given a fair chance of being classified for that outcome by our model. The results here are quite different:Finally, the “Equal accuracy” strategy will optimize for accuracy across both classes (positive and negative). Again, the resulting thresholds are different from either of the outcomes above:We can do a similar slice analysis for other features, like neighborhood and house type, or we can do an intersectional analysis by slicing by two features at the same time. It’s also important to note that there are many definitions of the fairness constraints used in the What-if Tool; the ones you should use largely depend on the context of your model. TakeawaysWe used the housing dataset in our demo, but this could be applied to any type of classification task. What can we learn from doing this type of analysis? Let’s take a step back and think about what would have happened if we had not done a fairness analysis and deployed our model using a 0.5 classification threshold for all feature values. Due to biases in our training data, our model would be treating houses differently based on their location, age, size, and other features. Perhaps we want our model to behave this way for specific features (i.e. price bigger houses higher), but in other cases we’d like to adjust for this bias. Armed with the knowledge of how our model is making decisions, we can now tackle this bias by adding more balanced training data, adjusting our training loss function, or adjusting prediction thresholds to account for the type of fairness we want to work towards. Here are some more ML fairness resources that are worth checking out:ML Fairness section in the Google’s Machine Learning Crash CourseGoogle I/O talk on ML FairnessResponsible AI practicesInclusive ML GuideHuman-centered AI guidebookCode for the housing demo shown in this post in GitHub and AI HubIs there anything else you’d like to see covered on the topics of ML fairness or explainability? Let me know what you think on Twitter at @SRobTweets.
Quelle: Google Cloud Platform