Januar 2019 - Seite 80 von 89 - Cloud Computing Köln

The Asia Pacific market is important for Google Cloud, and we are making long-term investments to support our growing business there. In just the past 18 months, we have expanded the number of GCP regions in APAC from three to six. With each additional region, we deliver lower latency to our customers and bring our technical innovations even closer to where they do business. Today, we’re thrilled to announce more progress: our sixth APAC region opened today in Hong Kong, with another coming to Jakarta, Indonesia in the future.A cloud made for Hong KongOur Hong Kong region is officially open for business. This new region—our eighteenth overall—will give both local and large multinational companies doing business in Hong Kong and Southeast Asia faster access to their data and applications.In a recent whitepaper published by Google Hong Kong, 54% of respondents based in Hong Kong indicated that they are planning to launch a cloud computing initiative, an increase of 13% from 2017. The Hong Kong GCP region (asia-east2) is designed to support our flourishing customer base in the area. It has three availability zones, enabling customers to distribute their workloads and storage to run at higher availability. Hybrid cloud customers can seamlessly integrate new and existing deployments with help from our regional partner ecosystem, and via two dedicated interconnect points of presence.Made for speedThe launch of the Hong Kong region brings speedier access to GCP products and services for organizations doing business in the area. Hosting applications in the new region can improve latency for end users in Hong Kong by up to 14ms. Customers in Vietnam and the Philippines will also benefit from a 25-30% improvement in latency. Visit www.gcping.com to see how quickly you can access the Hong Kong region from wherever you happen to be.Services that are presently not available within the Hong Kong region can still be utilized via the Google Network, and can be combined with other GCP services deployed around the world. For detailed information about our data storage capabilities, see our Service Specific Terms.Next up in APAC: JakartaLast month, we announced a new region for Indonesia to our customers there. Today, we are officially announcing it to the world: a new GCP region will be available in Jakarta, Indonesia. The region will be designed for high availability with three availability zones as well.Jakarta will become the eighth GCP region in Asia Pacific, joining Hong Kong, Mumbai, Sydney, Singapore, Taiwan and Tokyo, plus the soon-to-be-launched region in Osaka. Visit our locations page for updates on the availability of additional services and regions.Google Cloud: the world’s largest global private networkOur private, software-defined network provides a fast and reliable link between each region around the world. With more than 100 points of presence around the world, Google Cloud Platform ensures that your content is delivered quickly when every millisecond counts. Customers can quickly deploy and scale across multiple regions with products designed for organizations with a global footprint. What our customers are saying”We’ve made a decision on applications hosting to partner with Google on building some next-gen applications in the full Google stack, top to bottom using Google tools, which is a big departure from our previous architecture. It’s very exciting because I think we’ve got the confidence that the tools they have are going to be great for productivity with developers.”— Darryl West, Group Chief Information Officer, HSBC”We’re excited that GCP is launching in Hong Kong as it will help the ecosystem continue to grow. This launch is very important to us as Google has been a great partner to us as it will improve our service performance, and will contribute to the growth of our business in many different areas.”— Tony Wong, Chief Executive Officer, Shopline“Google Cloud Platform has a network of global data centers with deep connectivity that enables us to put our infrastructure close to our customers. In addition, the ability to horizontally scale our global database using tools such as Cloud Spanner eliminates any limits on our geographic expansion.”— Teddy Chan, Chief Executive Officer and Chief Technology Officer, AfterShip”Google Cloud remains to be a strong partner in Klook’s continuous growth. By using Google big data and analytics, we have been able to draw insights from our data so we can provide better services to travelers worldwide instead of spending time on infrastructure.”— Bernie Xiong, Chief Technology Officer and Co-Founder, KlookGetting startedFor additional details, please visit our Hong Kong region page where you’ll get access to free resources, whitepapers, the “Cloud On-Air” on-demand video series and more. If you’re new to GCP, check out Best Practices for Compute Engine Region Selection. Our locations page provides updates on the availability of additional services and regions. As always, be sure to contact us to request early access to new regions and help us prioritize where we build next.
Quelle: Google Cloud Platform

6. Januar 2019

da Agency

Cloud Functions pro tips: Building idempotent functions

In a previous blog post we discussed how to use retries to make your serverless system resilient to transient failures. What we didn’t mention is that if you’re going to retry a function, it needs to be able to run more than once without producing unexpected results or side effects.In computer science, this refers to the notion of idempotence, meaning that operation results remain unchanged when an operation is applied more than once. Likewise, a function is considered idempotent if an event results in the desired outcome even if the function is invoked multiple times for a given event. In other words, if you want your functions to behave correctly upon retries, you have to make them idempotent. In this post, we’ll show you how to do that.Exploring idempotent functionsTo better understand idempotency, let’s analyze a workflow. In this example, we have a function that processes incoming data, writes the results to one storage system, and then to another one.Success scenario: a write sequence to two different datastoresThe problem arises when, as you may expect, an upload to one of the storage systems fails. For example, imagine the second upload fails; this can result in data loss or inconsistency.Error scenario: the write to the second datastore failsWe already know how to handle such a failure—apply retries. But is it always safe to apply a retry? In this example, executing the function a second time stores the output in the second storage system (if the upload succeeded) but also results in writing a duplicate record or object into the first storage system. This could be unexpected by other systems, and result in further problems. Let’s discuss how to prepare a function for retried executions to avoid this kind of data duplication.Here, retrying your function may introduce a duplicate record.First, let’s look at a non-idempotent background function. It performs two uploads—first, it adds a document to Cloud Firestore, our flexible, scalable NoSQL database, and then uploads the document to another storage system off GCP. In a possible scenario when the upload to Cloud Firestore succeeds but the second upload fails, retrying the function results in a duplicate document, with the same contents, in the Cloud Firestore database. Of course, we don’t want duplicates, as they could cause confusion, accounting problems, and further inconsistencies.Use your event IDsOne way to fix this is to use the event ID, a number that uniquely identifies an event that triggers a background function, and— this is important—remains unchanged across function retries for the same event.Use event identifiers to avoid unwanted side-effects such as duplicationTo use an event ID to solve the duplicates problem, the first thing is to extract it from the event context that is accessed through function parameters. Then, we utilize the event ID as a document ID and write the document contents to Cloud Firestore. This way, a retried function execution doesn’t create a new document, just overrides the existing one with the same content. Similarly, some external APIs (e.g., Stripe) accept an idempotency key to prevent data or work duplication. If you depend on such an API, simply provide the event ID as your idempotency key.There! Now that you’ve applied this event ID mechanism, you shouldn’t see any more duplicates—in Cloud Firestore, or in another system that accepts idempotency keys.But what if the system you call does not support idempotency? Consider the following example. Here, we call Sendgrid, the email delivery service, to send an email from the function. But the call isn’t idempotent so retrying the function may result in duplicate emails. What can you do to avoid this problem?The general solution here is note when a system has handled an event, by recording its event ID. This way, you reduce the chance of unwanted retried calls to other services. In this example, we record the event ID in Cloud Firestore, but you can use another database or storage system as well. On each function execution, check whether the given event has already been recorded. If not, run the code and store the event ID in Cloud Firestore.A new lease on retriesWhile this approach eliminates the vast majority of duplicated calls on function retries, there’s a small chance that two retried executions running in parallel could execute the critical section more than once. To all but eliminate this problem, you can use a lease mechanism, which lets you exclusively execute the non-idempotent section of the function for a specific amount of time. In this example, the first execution attempt gets the lease, but the second attempt is rejected because the lease is still held by the first attempt. Finally, a third attempt after the first one fails re-takes the lease and successfully processes the event.Using a lease mechanism to handle non-idempotent codeTo apply this approach to your code, simply run a Cloud Firestore transaction before you send your email, checking to see if the event has been handled, but also storing the time until which the current execution attempt has exclusive rights to sending the email. Other concurrent execution attempts will be rejected until the lease expires, eliminating all duplicates for all intents and purposes.By now, you can see that there are multiple ways to make a function idempotent, and doing so is an important part of handling failures and improving the reliability of your system. First, you can ensure that mutations can happen more than once without changing the outcome. You can also record event IDs that have been processed, query database state in a transaction before mutating the state, and supply an idempotency key if you’re calling APIs that support them. To learn more, check out cloud.google.com/functions/ and you can also find all the code we used in this blog post on GitHub. Stay tuned for the next post in the series, where we’ll demonstrate how to use retries and idempotency as part of a simple restaurant order-processing system.
Quelle: Google Cloud Platform

6. Januar 2019

da Agency

The Google Cloud Adoption Framework: Helping you move to the cloud with confidence

Cloud computing is maturing at a scale and speed that can be hard to keep up with. In fact, it can seem as if every week a public cloud provider is announcing a new feature that will run your applications and store your data more scalably, reliable, or securely. And it’s not always easy to know where to start.The Google Cloud Professional Services team was created to help our customers make their way successfully to the cloud. Along the way, we’ve seen the sorts of things that can trip organizations up, as well as patterns developing around what makes other organizations successful. Most recently, we’ve seen a shift in the outcomes our customers want to achieve with the cloud. For the first 10 years, getting to the cloud has been about tactical cost cutting initiatives—building your “mess for less” in the cloud. Over recent years, our customers have begun to ask us much bigger, more strategic, even visionary questions: “How can I use machine learning to provide a better customer service?” “How do I do predictive inventory planning?” Or “How do I enable dynamic pricing?”These are the types of questions that excite us at Google—and we want to help you answer them. But getting to the point where your organization can really thrive in the cloud often requires deep, comprehensive transformation. That can be a tough pill to swallow. And if you’re the one leading that transformation, being able to communicate your plan in a simple, logical way can be critical to inspiring confidence in your vision.All these reasons and more are why we’ve developed the Google Cloud Adoption Framework. Built on our experience working with enterprise customers, it can help you determine where you are on your cloud journey today, and where you’d like to be.Although we share a broad range of insights in our framework, one of the most important is this: Getting started in cloud is all about striking the right balance.We’ve seen two types of company cultures play out, time and again, in our customer base. For example, many of our cloud-native customers have a bias for action. They do many things well: self-sufficiency in pushing workloads into production, highly collaborative teams, and continuous learning and experimentation, just to name a few. But in their desire to move fast, we’ve seen some underestimate the value of putting guardrails in place early to contain the inevitable sprawl of data and compute resources. This omission not only adds cost to their monthly cloud hosting bill, but can also result in security and data privacy challenges in the long-term. In this case, they’ve prioritized speed in the short-term over long-term sustainability.The opposite can be true for many enterprises new to the cloud. These enterprises often gravitate towards replicating their tried and true governance and operating model in the cloud, spending a lot of time designing process and policies (which are important), but too little time moving actual workloads into the cloud. Without production workloads, they don’t develop the experience needed to manage increasingly complex and business-critical use cases. And without early successes, they can be reluctant to increase investment and ultimately lose momentum in their cloud strategy.The ideal is balancing the pace of change across your people, process, and technology. That way, you can learn continuously, lead effectively, scale efficiently, and secure your environment comprehensively—the four capabilities we’ve observed that drive success in cloud.These are just some of the insights and best practices we can share to help you get started. To learn more, download the white paper.
Quelle: Google Cloud Platform