Do you want to fire up a bunch of techies? Talk about multicloud! There is no shortage of opinions. I figured we should tackle this hot topic head-on, so I recently talked to four smart folks—Corey Quinn of Duckbill Group, Armon Dadgar of Hashicorp, Tammy Bryant Butow of Gremlin, and James Watters of VMware—about what multicloud is all about, key considerations, and why you should (or shouldn’t!) do it.

Five important insights came out of these discussions. If you’re on a multicloud journey or considering one, keep reading.

Do: Choose to do multicloud for the right reasons

Don’t do multicloud because Gartner says so, implores Corey Quinn. Before embarking on a multicloud, define a “why” focused on business value journey, says Armon Dadger. For example, you might want to use services from each public cloud because of their differentiated services, according to Tammy Bryant Butow. Armon also calls out regulatory reasons, existing business relationships, and accommodating mergers and acquisitions. On the topic of M&A, Corey points out that if you acquire a company that uses another cloud, it’s usually expensive and difficult to consolidate. It can be smarter to stay put.

Don’t: Over-engineer for workload or data portability

Thinking that you’ll build a system that moves seamlessly among the various cloud providers? Hold up, says our group of experts. Armon points out that aspects of your toolchain or architecture may be multicloud—think of some of your workflows or global network routing—but that shifting workloads or data is far from simple. Corey says that trying to engineer for “write once, run anywhere” can slow you down, and ignores the inherent uniqueness that’s part of each platform. Specifically, Corey calls out the per-cloud stickiness of identity management, security features, and even network functionality. And data gravity is still a thing, says James, that causes some to dismiss multicloud outright.

If you’re using multiple public clouds, you take advantage of the distinct value each offers, Armon says. Use native cloud services where possible so that you see the benefits from useful innovations, built-in resilience, and baked-in best practices. The value from that cloud-infused workload may outweigh the benefits of seamless portability.

Do: Recognize different stakeholder interests and needs

James smartly points out that many multicloud debates happen because people are arguing from different perspectives. Context matters. If you’re an infrastructure engineer who invests heavily in a given cloud’s identity and access management model, multicloud looks tricky. Or if you’re a data engineer with petabytes of data homed in a particular cloud, multicloud may look unrealistic. James highlights that many developers default to multicloud because their local tools—where all the work happens—are multicloud. A developer’s IDE and preferred code framework(s) aren’t tied to any given cloud. Be aware that groups within your organization will come at multicloud from distinct directions. And this may impact your approach!

Don’t: Go it alone

Corey talks about the importance of asking others what worked, and what didn’t. Tammy offers her best practices around sharing results from experiments. It’s about sharing knowledge and tapping into it for community benefit. Others have probably tried what you’re trying, and can help you avoid common pitfalls. If you’ve just made an architectural choice that didn’t work out, share it, and help others avoid the pain. 

Read research from analysts, go to conferences or watch videos to observe case studies, and join online communities that offer a safe place to share mistakes and learn from others.

Do: Experiment first using techniques like multi-region deployments

If you think you can operate systems across clouds, how about you first try doing it across regions in a specific cloud, suggests Corey. Getting a system to properly work across cloud regions isn’t trivial, he says, and that experience can help you uncover where you have architectural or operational constraints that will be even worse across cloud providers.

This is great guidance if your multicloud aspirations involve using multiple clouds to power one application—versus the more standard definition of multicloud where you use different clouds for different applications—but can also surface issues in your support process or toolchain that fail when faced with distributed systems. Start with muti-region deployments and chaos engineering experiments before aggressively jumping into multicloud architectures.

The Google Cloud take

Do the things above. It’s great advice. I’ll add three more things that we’ve learned from our customers.

1. Don’t fear multicloud. You’re already doing it. You don’t single-source everything. As Corey mentioned, you probably already have one cloud for productivity tools, another for source code, another for cloud infrastructure. You’ll use software and application services from a mix of providers for a single app. You have that experience in your team and have been doing that for decades. What people do rightly worry about is using more than one infrastructure service beneath an application, as that can introduce latency, security, and logistical hurdles. Make sure you know which model your team is considering.
2. Embrace the right foundational components, including Kubernetes. Will everything run on Kubernetes? Of course not. Don’t try to do that. But it also represents the closest thing we have to a multicloud API. Companies are using Kubernetes to stripe a consistent experience across clouds. And this isn’t just to orchestrate containers, but also to manage infrastructure and cloud-native services. Also, consider where you need other fundamental consistency across clouds, including areas like provisioning and identity federation.
3. Use Google Cloud as your anchor. Here’s a fundamental question you have to decide for yourself: Are you going to bring your on-premises technology and practices to the cloud, or bring cloud technology and practices on-prem? We sincerely believe in the latter. Anchor to where you’re trying to get to. We offer Anthos as a way to build and run distributed Kubernetes fleets in Google Cloud and across clouds. By using a cloud-based backplane instead of an on-prem one, you’re offloading toil, leveraging managed services for scale and security, and introducing modern practices to the rest of your team.

We learned a lot about multicloud through these discussions, and it seems like others did too. That’s why we’re going to do a second round of interviews with a new crop of experts so that we can keep digging deeper into this topic. Stay tuned!

For many enterprises, the venerable mainframe is home to decades’ worth of data about the company’s customers, processes and operations. And it goes without saying that the business would like access to that mainframe data — to report on it, to analyze it with big data analysis tools, or to use it as the basis of new machine learning and artificial intelligence initiatives.

At Google Cloud, we are eager to work with organizations to help them transform their mainframe assets for the cloud era. Of course, we can help them modernize their mainframe applications by migrating them to the cloud. At the same time, working with partners and customers, we’ve developed another, more lightweight approach that can help them start to leverage the cloud for their mainframe assets much more quickly than performing a full-fledged migration. We call this approach data-first digitization.   

In this rapidly evolving digital ecosystem, it’s imperative to understand the difference between ‘modernization’ and ‘digitization.’ With modernization you start with the current state and look forward, and rely on mainframe application migration approaches such as rehosting (emulation), refactoring (automated code transformation), reengineering — or simply replacing a custom application with a commercial package. With digitization, you start with the future state that you want to achieve, and work back to what is required to get there.

This data-first digitization approach includes a mainframe data-first integration framework comprising in-house and partner products and tools to migrate heterogeneous data sources from the mainframe to Google Cloud Storage. Once mainframe data has been copied to Cloud Storage, it can then be integrated and leveraged by Google Cloud tools such as BigQuery, AI and machine learning prodcuts  and Smart and Stream analytics platforms. The integration framework covers both bulk batch data transfers and real-time data replication (change data capture).

Data-first digitization is based on the tenet that ‘applications are transient, data is permanent.’ By bringing data first to Google Cloud instead of traditional ways of modernizing applications (for example, with Gartner’s 7 options to Modernize), this allows organizations to leapfrog to new business models, use cases and innovative ways to serve end customers. For example:

• Making decisions with smart and stream analytics platforms and AI/ML engines. These tools need data to make decisions. Google is a pioneer in extracting information and value from the raw structured and unstructured data, and this approach opens up mainframe data for use by BigQuery and AI/ML models. 
• Building new reporting applications. With access to mainframe data, you can use Google cloud products like Looker and Appsheet to build net-new reporting applications, expediting the process of retiring mainframe reporting applications, and accelerating your overall transformation.

In our experience, taking a data-first digitization approach to your mainframe offers a number of benefits:

1. Faster time-to-business: Because data-first modernization is built on existing products, the implementation cycle is much shorter.
2. Less capital investment: You spend your time integrating products, not developing applications.
3. Minimized risk: Data-first integrates with existing, proven and reliable Google Cloud products.
4. Faster overall mainframe transformation: When you shift your modernization center of gravity from the application to the data, you look at mainframe applications from a business perspective instead of just “keeping the lights on.” As a result, only the most business-critical applications are modernized and many support applications can be decommissioned, accelerating your transformation journey. 

Taking a data-first approach to digitization is still relatively new, but we’re heartened by customers’ early successes. Watch this space for additional insights, reference architectures and technical white papers around data-first. And if you think this approach may be right for you, reach out to mainframe@google.com.

Learn more:

• Liberating your mainframe data with Confluent and Google Cloud
• Beyond mainframe modernization: The art of possibilities

Google Cloud Results

• Maximizes revenue by allowing customers to place bets faster and more confidently
• Scales for major racing events with 80% less IT involvement and up to $500,000 annual savings
• Improves time to market for new product releases by more than 30x
• Helps enable richer mobile experiences to keep fans engaged
• Processes up to 6,000 bets per minute

The first Saturday of May is the biggest horse racing event in North America each year. Minutes before the race, millions of dollars in online bets will flow in through advanced deposit wagering (ADW) operators such as TVG Network. For TVG’s IT team, it’s a high-stakes game: If wagering systems can’t handle thousands of requests per second, revenue and customers will be lost.

To avoid downtime before a major race, TVG used to bombard its systems with ad-hoc load tests a month in advance. Before each big race event, a team of seven people spent eight hours a week deploying new infrastructure and testing various scenarios. But with complex legacy systems and manual processes, the team’s efforts could only go so far. If an unexpected system issue or undetected bottleneck was found during the run-up to the big race, all bets were off.

After a brush with downtime in 2016, TVG decided to move its ADW application to the cloud, taking the opportunity to rewrite the application to take advantage of modern, container-based architectures. After a short period of development on a different cloud services provider, TVG moved to Google Cloud Platform using Google Kubernetes Engine to automate container management and orchestration.

“We chose Google Cloud Platform because it was the most reliable, cost-effective, and automated cloud solution available,” says Tim Morrow, CTO at TVG Network. “We get better security, strong compliance, and the peace of mind that when the biggest race day rolls around, we won’t have any downtime.”

Placing the right bet

Moving to Google Cloud Platform gives TVG a variety of options in different regions and availability zones to satisfy regulatory requirements. Google Cloud Platform offers continuous availability and transparent maintenance, with no scheduled downtime or patching requirements.

“For our online wagering site, we prefer Google’s philosophy of continuous availability and live migration,” says Tim. “Having to plan for scheduled downtime of cloud instances just seems ridiculous in this day and age. And with Google Cloud Platform, we get much more consistent performance as we scale.”

To keep its IT team focused on value-added tasks, TVG uses Google Cloud managed services such as Cloud Bigtable, a highly scalable NoSQL database, as well as Cloud Storage for backups and Cloud Pub/Sub for real-time messaging between applications.

“We like the software-defined nature of Google Cloud Platform,” says Saeid Vafaeisefat, Vice President of IT, TVG Network. “The managed services are so easy to use. Google Cloud Platform even helps us mitigate and absorb distributed denial of service attacks with its global load balancing features, which we don’t pay extra for.”

TVG worked with SADA Systems, a Google Cloud Premier Partner, for consulting and deployment assistance. “SADA Systems helped us gain a deeper understanding of the advantages of Google Cloud Platform so we could make better decisions about how our application would perform and scale,” says Saeid. “They provided the facilitation, follow-up, and expert advice we needed to make our deployment a success.”

Scaling with 80% less work

With an active-active cloud architecture spanning multiple regions and the ability to conduct continuous, automated load tests, TVG no longer worries about downtime during major racing events—or any time, for that matter. Infrastructure and tools that used to be required to scale and provide resiliency are no longer needed, reducing CapEx. And with autoscaling replacing human intervention, accidental downtime is much less of a concern.

“With Google Cloud Platform, we can scale for major racing events with 80% less IT involvement and up to $500,000 annual CapEx savings,” says Tim. “Google Cloud Platform gives us faster deployment—we’re releasing new enhancements to our wagering site four times a week instead of every two months.”

More profitable user journeys

TVG’s success is being driven by ongoing modernization made possible in part by Google Cloud Platform, with TVG becoming the first U.S. operator to launch native iPhone and iPad apps. Lower latency means that stale data is never an issue, allowing customers to place bets faster and more confidently from anywhere they happen to be—which generates more revenue for TVG.

“Being on Google Cloud Platform has allowed us to develop our customer-facing channel faster while focusing on automated deployment and immutable infrastructure,” says Tim. “We have far greater confidence in our platform, and last year we broke records on our major race days while delivering an excellent customer experience.”