Aktualisierte Deep-Learning-Container für SageMaker Debugger und Tensorflow Server

Für AWS Deep Learning Containers sind ab sofort Fehlerkorrekturen für die Integration von SageMaker in Tensorflow Server und die neuste Version von SageMaker Debugger verfügbar. Sie können die neuen Versionen von Deep Learning Containers in Amazon SageMaker, Amazon Elastic Kubernetes Service (Amazon EKS), in selbstverwalteten Kubernetes-Instances in Amazon EC2 und Amazon Elastic Container Service (Amazon ECS) starten. Eine vollständige Liste der von AWS Deep Learning Containers unterstützten Frameworks und Versionen finden Sie in den Versionshinweisen. 
Quelle: aws.amazon.com

Ankündigung des Exports von Snapshots aus Amazon Relational Database Service (RDS) Snapshot Export zu S3

Sie können jetzt Snapshots aus Amazon Relational Database Service (Amazon RDS) oder Amazon Aurora als Apache Parquet – ein effizientes offenes Spaltenspeicherformat für Analysen – nach Amazon S3 exportieren. Das Parquet-Format wird bis zu 2x schneller exportiert und verbraucht in Amazon S3 bis zu 6x weniger Speicherplatz als Textformate. Sie können die exportierten Daten mit anderen AWS-Services wie Amazon Athena, Amazon EMR und Amazon SageMaker analysieren.
Quelle: aws.amazon.com

Emaar: Improving customer engagement across industries with APIs

Editor’s note: Today’s post comes from Binoo Joseph, CIO, and Venkadesh Sivalingam, integration architect at Emaar. Based in Dubai, Emaar is a real-estate development company operating across a number of verticals, including properties, shopping malls, hospitality, and entertainment. Learn how Emaar develops new customer experiences using APIs.Emaar is known worldwide for our luxurious properties and communities. Our most well-known property is likely the Burj Khalifa, which is the tallest structure in the world at 829 meters. But we’re also involved in many other businesses, including hotels, leisure clubs, shopping malls, events, and entertainment.One thing that ties our businesses together is our commitment to innovation and delivering excellent customer experiences. Traditionally that’s meant creating a variety of front-end applications powered by middleware for our customers to interact with. This might be a web portal where property owners pay service fees, a booking site for restaurant or hotel reservations, or a mobile app guiding visitors around Dubai Mall. Every business had their own workflows for creating and managing the APIs needed to run these customer experiences, but we wanted to enable greater access to information and services for  customers such as tenants, property owners, customers, and partners.We realized in order to innovate faster, we needed to pool resources and share microservices across teams. That meant having a single way of developing, deploying, and securing APIs across all verticals. With that goal, we looked for an API management solution that could bring us security and speed in a flexible hybrid architecture.Apigee checked all the right boxes. Combined with the great support that we got from the local Apigee team, we knew Apigee was the ideal solution for us.Creating APIs in a standard environmentApigee is helping us transform how we work with APIs. We now have a consistent structure for designing and securing APIs, and that consistency enables us to be much more secure in the way we connect with data and deploy them. Our developers focus on microservices, and Apigee gives us full visibility into work across development groups. Teams can share and reuse APIs rather than rebuilding them for every new customer experience, so we can push them out faster for our customers.In just a few months after going live, we exposed around 250 APIs through Apigee. Some APIs connect enterprise and internal systems, but many connect with external customers.Bringing key information to customersOne of the biggest ways we currently use APIs is to connect with customers. Our flagship property app lets property owners manage their properties from anywhere. They can view service requests, pay service fees, and stay up to date with any information from Emaar. With Apigee, we can continue to add new app functionality to keep owners connected and offer more self-service options.We’re also starting to connect our shopping mall tenants with our new APIs. Our flagship shopping center, Dubai Mall, is the world’s largest retail destination with more than 1,300 shopping, dining, and entertainment options, including a cinema, ice rink, and aquarium. We connect with mall visitors through the Dubai Mall app. But to provide customers with the most up-to-date information, we need to communicate with our tenants. Tenants keep us updated about events, traffic, and sales, and we can use that information to push shoppers towards deals.The developer portal plays a role in helping tenants start taking advantage of our APIs quickly, as it’s easy to use and centralizes API documentation. In the short time since we started working with mall tenants, we’ve already onboarded 60 retailers. The speed of integration is also about five to six times faster than it was before we employed the developer portal, making us confident many more retailers will come onboard in the coming months.Looking to future experiences with APIsWith Apigee, we not only have the tools that we need to quickly deploy and secure APIs, but eventually to monetize them. One potential way to do so would be to provide our APIs to aggregator apps and services, which are popular in many of the verticals that we operate in—hotel bookings, restaurant reservations, and tickets to events and attractions. It’s good to know that when we’re ready to monetize, the technology is there for us.Apigee is also opening the doors for us to explore new lines of business. We look forward to seeing how we can use APIs to give our customers engaging and beneficial experiences in the future.
Quelle: Google Cloud Platform

4 ways Anthos delivers ROI to customers, according to new Forrester Consulting Study

In our conversations with technology leaders about Anthos, we quickly get into the strategic questions about long term transformation and selection of the right technology architectures. At the heart of those discussions is an exploration of the potential economic value to their organization. So we commissioned Forrester Consulting to interview a few early adopters of Anthos in order to conduct a comprehensive study on the impact that Anthos, Google Cloud’s application modernization platform had on their IT organization. Today we’re excited to share Forrester’s New Technology Projection: The Total Economic Impact™ of Anthos study, which describes how Anthos can help make operators, developers, and security team more productive and satisfied. Forrester conducted interviews with several early Anthos customers to evaluate the benefits, costs, and risks of investing in Anthos across an organization. Based on their interviews, Forrester identified major financial benefits across four different areas: operational efficiency, developer productivity, security productivity and increased customer advocacy and retention. In fact, Forrester projects that customers adopting Anthos can achieve a range of up to 4.8x Return on Investment (ROI) within three years.Save money, increase customer satisfactionLike you, Anthos customers work with multiple clouds (including on-premises environments) and report that managing a hybrid or multi-cloud platform is incredibly complex. Anthos enables them to modernize in place, build and deploy apps fast, and scale effectively without compromising their security or increasing complexity. Let’s take a deeper look at the ways that Forrester found that Anthos can help you achieve your goals and unlock your business potential. 1. Streamline operational efficiencyAnthos gives operators a single platform to manage applications across environments, saving time on management and speeding up modernization. Anthos Service Mesh simplifies delivery and lifecycle management of microservices and helps ensure the health of the overall application. The composite organization is projected to reduce the time spent on platform management by 40% to 55%, across both on-prem and cloud environments. When you are ready to migrate existing applications to the cloud, Migrate for Anthos makes that process simple and fast. The composite organization is projected to have 58% to 75% faster app migration and modernization process when using Anthos. After you containerize your existing applications you can take advantage of Anthos Google Kubernetes Engine (GKE), both on-prem and in the cloud, and consistently manage your Kubernetes deployments. 2. Accelerated development velocity and increased developer productivityAnthos gives time back to developers by providing consistency across on-prem and various cloud environments. Instead of managing configurations and deployments, developers can focus on what they do best: writing, testing, and pushing code. Developers also enjoy a better experience while using environment-agnostic Anthos capabilities like our Cloud Run serverless solution, Anthos Service Mesh, Anthos Config Management, and Anthos GKE. Ultimately, developers at enterprises in this study projected reduced non-coding time by 23% to 38%. Saving developers time also directly contributes to organizational agility. One Google Cloud financial services customer using Anthos expects to move their updates from a quarterly to a weekly roll-out—a 13x improvement on time-to-market. When developers are freed from the burden of infrastructure management, they can accelerate progress in your organization. 3. Consistent, unified security policy creation and enforcement across environmentsRegardless of where you are in your application modernization journey, keeping your cloud platform reliable and secure is absolutely critical. Just minutes of downtime can mean millions of dollars in lost sales, and one security breach can be a billion dollar mistake. One major concern surrounding moving to the cloud is the difficulty of securing applications across a range of different environments that may not sit solely in your data centers. Anthos Config Management allows you to automate and standardize security policies and best practices across all of your environments. Anthos GKE combines the power of containerization with the ease of management from a single UI and API surfaceConsistent and unified policy creation and enforcement, through Anthos is projected to save security operators 60% to 96% of their time on deployment-related tasks. 4. Improve customer advocacy and retention for lift in top-line revenue Perhaps most importantly, Forrester’s analysis found that Anthos can enhance the customer-facing application performance, and availability, leading to more satisfied customers and a significant financial sales lift. Containerization, microservices, and serverless all provide tools that improve cloud agility and governance. Application downtime is incredibly frustrating for your customers and can result in lost revenue. Anthos is projected to reduce application downtime by 20% to 60% in the composite organization, which also contributed to a better customer experience and increased overall sales. Additionally, productive developers, and efficient operators, can push new features and updates more frequently, enhancing the customer experience across all your applications. Download the Forrester Total Economic Impact study today to hear directly from enterprise engineering leaders and dive deep into the economic impact Anthos can deliver your organization. We would love to partner with you to explore the potential Anthos can unlock in your teams. Please reach out to our sales team to start a conversation about your digital transformation with Google Cloud.
Quelle: Google Cloud Platform

Create a new OCP application deployment using Ceph RBD volume (Rails + PostgreSQL)

> Note: This example application deployment assumes you already have an OpenShift test cluster or have followed the instructions in the Deploying OpenShift Container Storage 4 to OpenShift 4 Blog to set up an OpenShift Container Platform 4.2.14+ cluster using OpenShift Container Storage 4.

In this Blog the ocs-storagecluster-ceph-rbd storage class will be used by an OCP application + database deployment to create RWO (ReadWriteOnce) persistent storage. The persistent storage will be a Ceph RBD (RADOS Block Device) volume (object) in the Ceph pool ocs-storagecluster-cephblockpool.
To do so we have created a template file, based on the OpenShift rails-pgsql-persistent template, that includes an extra parameter STORAGE_CLASS that enables the end user to specify the storage class the Persistent Volume Claim (PVC) should use. Feel free to download https://raw.githubusercontent.com/red-hat-storage/ocs-training/master/ocp4ocs4/configurable-rails-app.yaml to check on the format of this template. Search for STORAGE_CLASS in the downloaded content.
oc new-project my-database-app
curl <a href=”https://raw.githubusercontent.com/red-hat-storage/ocs-training/master/ocp4ocs4/configurable-rails-app.yaml”>https://raw.githubusercontent.com/red-hat-storage/ocs-training/master/ocp4ocs4/configurable-rails-app.yaml</a> | oc new-app -p STORAGE_CLASS=ocs-storagecluster-ceph-rbd -p VOLUME_CAPACITY=5Gi -f –

After the deployment is started you can monitor with these commands.
oc status
oc get pvc -n my-database-app
This step could take 5 or more minutes. Wait until there are 2 Pods in Running STATUS and 4 Pods in Completed STATUS as shown below.
watch oc get pods -n my-database-app
Example output:
NAME READY STATUS RESTARTS AGE
postgresql-1-deploy 0/1 Completed 0 5m48s
postgresql-1-lf7qt 1/1 Running 0 5m40s
rails-pgsql-persistent-1-build 0/1 Completed 0 5m49s
rails-pgsql-persistent-1-deploy 0/1 Completed 0 3m36s
rails-pgsql-persistent-1-hook-pre 0/1 Completed 0 3m28s
rails-pgsql-persistent-1-pjh6q 1/1 Running 0 3m14s

You can exit by pressing Ctrl+C
Once the deployment is complete you can now test the application and the persistent storage on Ceph. Your HOST/PORT will be different.
oc get route -n my-database-app
Example output:
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
rails-pgsql-persistent rails-pgsql-persistent-my-database-app.apps.cluster-a26e.sandbox449.opentlc.com rails-pgsql-persistent

Copy your rails-pgsql-persistent route (different than above) to a browser window to create articles. You will need to append /articles to the end.
Example http:///articles
Enter the username and password below to create articles and comments. The articles and comments are saved in a PostgreSQL database which stores its table spaces on the Ceph RBD volume provisioned using the ocs-storagecluster-ceph-rbd storageclass during the application deployment.
username: openshift
password: secret
Lets now take another look at the Ceph ocs-storagecluster-cephblockpool created by the ocs-storagecluster-ceph-rbd Storage Class. Log into the toolbox pod again.
TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc rsh -n openshift-storage $TOOLS_POD
Run the same Ceph commands as before the application deployment and compare to results in prior section. Notice the number of objects in ocs-storagecluster-cephblockpool has increased. The third command lists RBDs and we should now have two RBDs.
ceph df
rados df
rbd -p ocs-storagecluster-cephblockpool ls | grep vol

You can exit the toolbox by either pressing Ctrl+D or by executing exit.
Matching PVs to RBDs
A handy way to match persistent volumes to Ceph RBDs is to execute:
oc get pv -o ‘custom-columns=NAME:.spec.claimRef.name,PVNAME:.metadata.name,STORAGECLASS:.spec.storageClassName,VOLUMEHANDLE:.spec.csi.volumeHandle’

Example output:
NAME PVNAME STORAGECLASS VOLUMEHANDLE
ocs-deviceset-0-0-gzxjb pvc-1cf104d2-2033-11ea-ac56-0a9ccb4b29e2 gp2
ocs-deviceset-1-0-s87xm pvc-1cf33c42-2033-11ea-ac56-0a9ccb4b29e2 gp2
ocs-deviceset-2-0-zcjk4 pvc-1cf4f825-2033-11ea-ac56-0a9ccb4b29e2 gp2
db-noobaa-core-0 pvc-3008e684-2033-11ea-a83b-065b3ec3da7c ocs-storagecluster-ceph-rbd 0001-0011-openshift-storage-0000000000000001-3c0bb177-2033-11ea-9396-0a580a800406
postgresql pvc-4ca89d3d-2060-11ea-9a42-02dfa51cba90 ocs-storagecluster-ceph-rbd 0001-0011-openshift-storage-0000000000000001-4cbba393-2060-11ea-9396-0a580a800406
rook-ceph-mon-a pvc-cac661b6-2032-11ea-ac56-0a9ccb4b29e2 gp2
rook-ceph-mon-b pvc-cde2d8b3-2032-11ea-ac56-0a9ccb4b29e2 gp2
rook-ceph-mon-c pvc-d0efbd9d-2032-11ea-ac56-0a9ccb4b29e2 gp2
lab-ossm-hub-data pvc-dc1d4bdc-2028-11ea-ad6c-0a9ccb4b29e2 gp2

The second half of the VOLUMEHANDLE column mostly matches what your RBD is named inside of Ceph. All you have to do is append csi-vol- to the front like this:
Get the full RBD name of our postgreSQL PV in one command
oc get pv pvc-4ca89d3d-2060-11ea-9a42-02dfa51cba90 -o jsonpath='{.spec.csi.volumeHandle}’ | cut -d ‘-‘ -f 6- | awk ‘{print “csi-vol-“$1}’

> Note: You will need to adjust the above command to use your PVNAME name
Example output:
csi-vol-4cbba393-2060-11ea-9396-0a580a800406
Now we can check on the details of our RBD from inside of the tools pod:

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc rsh -n openshift-storage $TOOLS_POD rbd -p ocs-storagecluster-cephblockpool info csi-vol-4cbba393-2060-11ea-9396-0a580a800406

Example output:
rbd image ‘csi-vol-4cbba393-2060-11ea-9396-0a580a800406′:
size 5 GiB in 1280 objects
order 22 (4 MiB objects)
snapshot_count: 0
id: 95e4f3973e8
block_name_prefix: rbd_data.95e4f3973e8
format: 2
features: layering
op_features:
flags:
create_timestamp: Tue Dec 17 00:00:57 2019
access_timestamp: Tue Dec 17 00:00:57 2019
modify_timestamp: Tue Dec 17 00:00:57 2019

> Note: You will need to adjust the above command to use your RBD name

Resources and Feedback
To find out more about OpenShift Container Storage or to take a test drive, visit https://www.openshift.com/products/container-storage/.
If you would like to learn more about what the OpenShift Container Storage team is up to or provide feedback on any of the new 4.2 features, take this brief 3-minute survey.
The post Create a new OCP application deployment using Ceph RBD volume (Rails + PostgreSQL) appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

What’s happening in BigQuery: New federated queries, easier ML, and more metadata

BigQuery, Google Cloud’s petabyte-scale data warehouse, lets you ingest and analyze data quickly and with high availability, so you can find new insights, trends, and predictions to efficiently run your business. Our engineering team is continually making improvements to BigQuery so you can get even more out of it. Recently added BigQuery features include new federated data sources, BigQuery ML transforms, integer partitions, and more.Read on to learn more about these new capabilities and get quick demos and tutorial links so you can try them yourself.Query Orc and Parquet files directly with BigQueryParquet and ORC are popular columnar open source formats for large-scale data analytics. As you make your move to the cloud, you can use BigQuery to analyze data stored in these formats. Choosing between keeping these files in Cloud Storage vs. loading your data into BigQuery can be a difficult decision. To make it easier, we launched federated query support for Apache ORC and Parquet files in Cloud Storage from BigQuery’s Standard SQL interface. Check out a demo:This new feature joins other federated querying capabilities from within BigQuery, including storage systems such as Cloud Bigtable, Google Sheets, and Cloud SQL, as well as AVRO, CSV, and JSON file formats in Cloud Storage—all part of BigQuery’s commitment to building an open and accessible data warehouse. Read more details on this launch.  Your turn: Load and query millions of movie recommendations Love movies? Here’s a way to try query federation: analyze over 20 million movie ratings and compare analytic performance between Cloud SQL, BigQuery federated queries, and BigQuery native storage. Launch the code workbook and follow along with the video. Don’t have a Google Cloud account? Sign up for free.New data transformations with BigQuery MLThe success of machine learning (ML) models depends heavily on the quality of the dataset used in training. Preprocessing your training data during feature engineering can get complicated when you also have to do those same transformations on your production data at prediction time. We announced some new features in BigQuery ML that can help preprocess and transform data with simple SQL functions. In addition, because BigQuery automatically applies these transformations at the time of predictions, the productionization of ML models is greatly simplified.Binning data values with ML.BUCKETIZEOne decision you will face when building your models is whether to throw away records where there isn’t enough data for a given dimension. For example, if you’re evaluating taxi cab fares in NYC, do you throw away rides to latitude and longitudes that only appear once in the data? One common technique is to bucketize continuous values (like lat/long) into discrete bins. This will help group and not discard infrequent dropoff locations in the long tail:BigQuery provides out-of-the-box support for several common machine learning operations that do not require a separate analysis pass through the data. For example, here’s an example of bucketizing the inputs, knowing the latitude and longitude boundaries of New York:BigQuery ML now supports running the same preprocessing steps at serving time if you wrap all of your transformations in the new TRANSFORM clause. This saves you from having to remember and implement the same data transformations you did during training on your raw prediction data. Check out the blog post to see the complete example for NYC Taxi cab fare prediction and read more in the BigQuery ML preprocessing documentation. Use flat-rate pricing with BigQuery ReservationsBigQuery Reservations is now in beta in U.S. and E.U. regions. BigQuery Reservations allows you to seamlessly purchase BigQuery slots to take advantage of flat-rate pricing and manage BigQuery spending with complete predictability.BigQuery Reservations allows you to:Purchase dedicated BigQuery slots by procuring commitments in a matter of secondsProgrammatically and dynamically distribute committed BigQuery slots to reservations for workload management purposesUse assignments to assign Google Cloud projects, folders, or your entire organization to reservationsQuickly analyze metadata with INFORMATION_SCHEMAAs a data engineer or analyst, you are often handed a dataset or table name with little or no context of what’s inside or how it is structured. Knowing what tables and columns are available across your datasets is a critical part of exploring for insights. Previously, you could select a preview of the data or click each table name in the BigQuery UI to inspect the schema. Now, with INFORMATION_SCHEMA, you can do these same tasks at scale with SQL. How can you quickly tell how many tables are in a dataset? What about the total number and names of columns and whether they are partitioned or clustered? BigQuery natively stores all this metadata about your datasets, tables, and columns in a queryable format that you can quickly access with INFORMATION_SCHEMA:As you can see, with INFORMATION_SCHEMA.COLUMNS there is a list of every column and its data type for all tables in the baseball dataset. Let’s expand the previous query to aggregate some useful metrics like:Count of tablesNames of tables Total number of columnsCount of partitioned columnsCount of clustered columnsTry the above query with different public datasets like github_repos or new_york or even your own Google Cloud project and dataset. Your turn: Analyze BigQuery public dataset and table metadata quickly with INFORMATION_SCHEMAPractice analyzing dataset metadata with this 10-minute demo video and code workbook. And check out the documentation for INFORMATION_SCHEMA for reference. Partition your tables by an integer rangeBigQuery natively supports partitioning your tables, which makes managing big datasets easier and faster to query. You can decide which of your timestamp, date, or range of integers of your data to segment your table by. Creating an integer range partitioned tableLet’s assume we have a large dataset of transactions and a customer_id field that we want to partition by. After the table is set up, we will be able to filter for a specific customer without having to scan the entire table, which means faster queries and more control over costs.We’ll use the BigQuery CLI for this example. Here we create an integer range partitioned table named mypartitionedtable in mydataset in your default project.The partitioning is based on a start of 0, end of 100, and interval of 10. That means we have customer IDs from 0 to 100 and want to segment them in groups of 10 (so IDs 0-9 will be in one partition, and so on.). Note that new data written to an integer range partitioned table will automatically be partitioned. This includes writing to the table via load jobs, queries, and streaming. As your dataset changes over time, BigQuery will automatically re-partition your data too.Using table decorators to work with specific partitions You can use table decorators to quickly access specific segments of your data. For example, if you wanted all the customers in the first partition (0-9 ID range) add the $0 suffix to the table name:This is particularly useful when you need to load in additional data—you can just specify the partitions using decorators. For additional information about integer range partitions, see Integer range partitioned tables.In case you missed itFor more on all things BigQuery, check out these recent posts, videos and how-tos:New features for BigQuery Audit Logs are now generally available Persistent SQL UDFs are now generally available Check out the new book BigQuery: The Definitive Guide, by Jordan Tigani and Valliappa LakshmananTo keep up on what’s new with BigQuery, subscribe to our release notes. You can try BigQuery with no charge in our sandbox. And let us know how we can help.
Quelle: Google Cloud Platform

Exploring an Apache Kafka to Pub/Sub migration: Major considerations

The fastest way to migrate a business application into Google Cloud is to use the lift and shift strategy—and part of that transition is migrating any OSS, or third-party services that the application uses. But sometimes it can be more efficient and beneficial to leverage Google Cloud services instead. One of the services that customers often think about migrating is Apache Kafka, a popular message distribution solution that performs asynchronous message exchange between different components of an application. While following the lift and shift strategy, the native solution is to migrate to a proprietary managed Kafka cluster or to leverage a managed partner service of Confluent Cloud. But in many cases, our Pub/Sub messaging and event distribution service can successfully replace Apache Kafka, with lower maintenance and operational costs, and better integration with other Google Cloud services.Kafka is designed to be a distributed commit log. In other words, it includes the functionality of both a message system and storage system, providing features beyond that of a simple message broker. These features include log compaction, partitioned ordering, exactly-once delivery, the ability to browse committed messages, long message retention times and others often complicate the migration decision. The migration task is easier when Kafka is simply used as a message broker or event distribution system. But it is also possible to migrate from Kafka to Pub/Sub when the former is used for data streaming. In this post, we compare some key differences between Kafka and Pub/Sub to help you evaluate the effort of the migration. Then, in an upcoming post, we’ll show you how to implement some Kafka functionality with the Pub/Sub service as well as to accomplish the migration itself.Pub/Sub Key AdvantagesDespite the fact that Apache Kafka offers more features, many applications that run in Google Cloud can benefit from using Pub/Sub as their messaging service. Some of Pub/Sub’s benefits include:Zero maintenance costs – Apache Kafka is highly customizable and flexible, but that can translate to expensive, often manual maintenance. In contrast, running Pub/Sub does not require any manpower. Lower operational costs – Running Kafka OSS in Google Cloud incurs operational costs, since you have to provision and maintain the Kafka clusters.  In addition, infrastructure costs might be higher in some circumstances since they are based on allocated resources rather than used resources. In contrast, Pub/Sub pricing is based on pay-per-use and the service requires almost no administrationNative integration with other Google Cloud services, e.g. Cloud Functions, Storage or Stackdriver – To use Kafka with these services, you need to install and configure additional software (connectors) for each integration. A push mechanism – In addition to the conventional message pulling mechanism, Pub/Sub retrieves messages posted to a topic via push delivery.Implicit scaling – Pub/Sub automatically scales in response to a change in load. In contrast, Kafka’s topic partitioning requires additional management, including making decisions about resource consumption vs. performance.Integrated logging and monitoring – Pub/Sub is natively integrated with Stackdriver, with no external configurations or tooling required. Kafka provides monitoring using the JMX plugin. When you deploy Kafka on Google Cloud, you’ll need to do additional development to integrate Kafka logs into Stackdriver logging and monitoring, maintain multiple sources of logs and alerts.Key differences affecting migration decisions It’s not easy to know upfront how complex it will be to migrate from Kafka to Pub/Sub. Here’s a decision tree that suggests solutions to potential migration blockers.If you use exactly-once message delivery Kafka’s exactly-once message delivery guarantee comes with a price: a degradation in performance. You can use it in production environments if you’re not expecting high message throughput and you don’t need to scale under load. A more effective way to achieve exactly once processing at high scale might be to make your message processing idempotent or use Dataflow to deduplicate the messages. These approaches can be used with Kafka too. If you consume messages that were published longer than seven days agoThere are few business reasons to postpone message processing. One of the most common is processing of messages that for some reason were not processed at a time they were posted by a publisher, for example, due to commit failure.  One of the use cases is the dead letter queue pattern where messages that cannot be processed by current applications are stored until it is modified to accommodate them. In Kafka you implement a dead letter queue using Kafka Connect or Kafka Streams. Pub/Sub now has a native dead letter queue too. This functionality is in alpha. Follow the Pub/Sub release notes to see when it will be generally available. Alternatively, you can implement dead letter queue logic using a combination of Google Cloud services. This post shows you how, using Dataflow and a Google Cloud database.When you use Kafka to store messages over long time periods, the migration guidelines are to store the posted messages in a database such as Cloud Bigtable or the BigQuery data warehouse.If you use log compaction,random message access or message deletionBeing able to overwrite or delete messages is functionality that you usually find in a storage service rather than in a message distribution service. Kafka’s log compaction ensures that Kafka will always retain at least the last known value for each message key within the log of data for a single topic partition. There is no equivalent feature in Pub/Sub and compaction requires explicit reprocessing of messages or incremental aggregation of state. Pub/Sub does provide the ability to discard messages automatically after as little 10 minutes. You can consider using seek functionality to random message access. Also the seek to a timestamp allows to discard the acknowledged messages manually after a retention period between 10 minutes and 7 days.If you use keyed message orderingOne of Kafka’s flagship features is its partition message ordering, sometimes referred to as keyed message ordering. Compared to Kafka, Pub/Sub offers only best-effort ordered message delivery. The feature is often cited as a functional blocker for migrating to another message distribution solution. However, the problem is not that clear-cut. Let’s briefly review message ordering in Kafka. Kafka promises to order messages within a single partition of a topic. This means that when a producer sends messages to a topic in some order, the broker writes the messages to the topic’s partition in that order, and all consumers read them in that order too.A broker distributes messages among partitions randomly. Because topics usually have many partitions, it is hard to maintain the ordering of the messages. To solve that problem, Kafka offers keyed messages—a mechanism that allows a single producer to assign unique keys to published messages. All messages that come with a specific key go to the same partition. A consumer can process the messages with the same key chronologically by reading them from that partition.Kafka’s ordering provides partial message ordering within a topic. Total topic ordering can be achieved with Kafka by configuring only one partition in the topic. However, this configuration takes out parallelism and usually is not used in production. Pub/Sub documentation reviews different use cases for message ordering and proposes solutions using additional Cloud services. You can also use third-party solutions if you don’t want to use these Google Cloud services. In addition, Pub/Sub has an “ordering key” feature (in limited alpha) that guarantees that messages successfully published by a single publisher for the same ordering key will be sent to subscribers in that order. Follow the Pub/Sub release notes to see when it will be generally available.What’s next?If you are considering a migration from Apache Kafka to Pub/Sub, we hope that this post helps to evaluate the change and offers comparison of unique features of both tools. In our next post, we’ll review implementation complexity of the migration and how to resolve it using the mentioned unique Pub/Sub features.ResourcesKafka reference documentationSpotify on replacing Kafka with Pub/SubImplement exactly-once delivery using Google Cloud DataflowError handling strategy using Cloud Pub/Sub and Dead Letter queuePub/Sub product pageMessage ordering documentationPub/Sub FAQ
Quelle: Google Cloud Platform

Six things to consider when using Video Indexer at scale

Your large archive of videos to index is ever-expanding, thus you have been evaluating Microsoft Video Indexer and decided that you want to take your relationship with it to the next level by scaling up.
In general, scaling shouldn’t be difficult, but when you first face such process you might not be sure what is the best way to do it. Questions like “are there any technological constraints I need to take into account?”, “Is there a smart and efficient way of doing it?”, and “can I prevent spending excess money in the process?” can cross your mind. So, here are six best practices of how to use Video Indexer at scale.

1. When uploading videos, prefer URL over sending the file as a byte array

Video Indexer does give you the choice to upload videos from URL or directly by sending the file as a byte array, but remember that the latter comes with some constraints.

First, it has file size limitations. The size of the byte array file is limited to 2 GB compared to the 30 GB upload size limitation while using URL.

Second and more importantly for your scaling, sending files using multi-part means high dependency on your network, service reliability, connectivity, upload speed, and lost packets somewhere in the world wide web, are just some of the issues that can affect your performance and hence your ability to scale. 

When you upload videos using URL you just need to give us a path to the location of a media file and we will take care of the rest (see below the field from the upload-video API).

To upload videos using URL via API you can check this short-code sample or you can use AzCopy for a fast and reliable way to get your content to a storage account from which you can submit it to Video Indexer using SAS URL.

2. Increase media reserved units if needed

Usually in the proof of concept stage when you just start using Video Indexer, you don’t need a lot of computing power. Now, when you want to scale up your usage of Video Indexer you have a larger archive of videos you want to index and you want the process to be at a pace that fits your use case. Therefore, you should think about increasing the number of compute resources you use if the current amount of computing power is just not enough.

In Azure Media Services, when talking about computing power and parallelization we talk about media reserved units (RUs), those are the compute units that determine the parameters for your media processing tasks. The number of RUs affects the number of media tasks that can be processed concurrently in each account and their type determines the speed of processing and one video might require more than one RU if its indexing is complex. When your RUs are busy, new tasks will be held in a queue until another resource is available.

We know you want to operate efficiently and you don’t want to have resources that eventually will stay idle part of the time. For that reason, we offer an auto-scale system that spins RUs down when less processing is needed and spin RUs up when you are in your rush hours (up to fully use all of your RUs). You can easily enable this functionality by turning on the autoscale in the account settings or using Update-Paid-Account-Azure-Media-Services API.

To minimize indexing duration and low throughput we recommend you start with 10 RUs of type S3. Later if you scale up to support more content or higher concurrency, and you need more resources to do so, you can contact us using the support system (on paid accounts only) to ask for more RUs allocation.

3. Respect throttling

Video Indexer is built to deal with indexing at scale, and when you want to get the most out of it you should also be aware of the system’s capabilities and design your integration accordingly. You don’t want to send an upload request for a batch of videos just to discover that some of the movies didn’t upload and you are receiving an HTTP 429 response code (too many requests). It can happen due to the fact that you sent more requests than the limit of movies per minute we support. Don’t worry, in the HTTP response, we add a retry-after header. The header we will specify when you should attempt your next retry. Make sure you respect it before trying your next request.

4. Use callback URL

Have you ever called customer service and their response was “I’m now processing your request, it will take a few minutes. You can leave your phone number and we’ll get back to you when it is done”? The cases when you do leave your number and they call you back the second your request was processed are exactly the same concept as using callback URL.

Thus we recommend that instead of polling the status of your request constantly from the second you sent the upload request, you can just add a callback URL, and wait for us to update you. As soon as there is any status change in your upload request, we will send a POST notification to the URL you sent.

You can add a callback URL as one of the parameters of the upload-video API (see below the description from the API). If you are not sure how to do it, you can check the code samples from our GitHub repo. By the way, for callback URL you can also use Azure Functions, a serverless event-driven platform that can be triggered by HTTP and implement a following flow.

5. Use the right indexing parameters for you

Probably the first thing you need to do when using Video Indexer, and specifically when trying to scale, is to think about how to get the most out of it with the right parameters for your needs. Think about your use case, by defining different parameters you can save yourself money and make the indexing process for your videos faster.

We are giving you the option to customize your usage in Video Indexer by choosing those indexing parameters. Don’t set the preset to streaming it if you don’t plan to watch it, don’t index video insights if you only need audio insights, it is that easy.

Before uploading and indexing your video read this short documentation, check the indexingPreset and streamingPreset parts to get a better idea of what your options are.

6. Index in optimal resolution, not highest resolution

Not too long ago, we were in times when HD videos didn't exist. Now, we have videos of varied qualities from HD to 8K. The question is, what video quality do you need for indexing your videos? The higher the quality of the movie you upload means the higher the file size, and this leads to higher computing power and time needed to upload the video.

Our experiences show that, in many cases, indexing performance has almost no difference between HD (720P) videos and 4K videos. Eventually, you’ll get almost the same insights with the same confidence.

For example, for the face detection feature, a higher resolution can help with the scenario where there are many small but contextually important faces. However, this will come with a quadratic increase in runtime (and therefore higher COGS) and an increased risk of false positives.

Therefore, we recommend you to verify that you get the right results for your use case and to first test it locally. Upload the same video in 720P and in 4K and compare the insights you get. Remember, No need to use a cannon to kill a fly.

Have questions or feedback? We would love to hear from you. Use our UserVoice page to help us prioritize features, leave a comment below or email VISupport@Microsoft.com for any questions.

We want to hear about your use case, and we can help you scale.
Quelle: Azure