Job seekers can often feel lost or disconnected—like the right opportunity is out there, but they don’t know where or how to look. Employers face a similar challenge when trying to attract the right candidates. Many companies, especially large enterprises, face a talent shortage across a range of critical roles.

For global companies like Johnson & Johnson (J&J), their online career website is an important recruiting tool. It’s the “front door” for talent that could make a vital difference in the company’s future and drive innovation for years to come.

However, career sites are often underutilized. If a job seeker doesn’t find a good job match with a quick search, they will likely move on. Too often, that represents a lost opportunity for both the company and the job seeker that could have been avoided with better search results.

“Partnering with Jibe and using Cloud Talent Solution for our career site allows us to do a much better job matching opportunity to talent on a very large scale.”

—Sjoerd Gehring, Global VP of Talent Acquisition, Johnson & Johnson

While J&J receives approximately 1 million applications for 25,000 positions each year, the percent of applicants that were highly qualified for open positions was low.

Although the company always has a variety of open jobs on its career site, it noticed that even when strong matches existed between online job seekers and available positions, search results often didn’t highlight or even display the right opportunities. The user interface wasn’t intuitive enough, and job seekers couldn’t easily find their ideal positions.

As J&J began to reevaluate recruiting to take a more relationship-centric and digitally-driven approach, the company began working with Jibe, a career-site solutions provider.

Jibe introduced J&J to Cloud Talent Solution, which uses machine learning to better match job listings with job seekers’ interests and qualifications. Using Cloud Talent Solution, companies can build a compelling career-site search experience that helps candidates easily find the jobs most relevant to them. With smarter job searches and recommendations, J&J improved the effectiveness of its career site in just a few weeks.

“Jibe and Google make it easy for a large company to make a real difference in the candidate experience without investing a lot of time, money, or internal resources,” says Sjoerd Gehring, Global VP of Talent Acquisition at Johnson & Johnson. “Now that we’re using Cloud Talent Solution, our career site search results are exponentially better.”

Transforming job searches with better matches

Cloud Talent Solution better connects job seekers with jobs, because it understands the nuances of job titles, descriptions, industry jargon, and skills, matching job seeker preferences with relevant listings based on sophisticated classifications and relational models. It helps decipher job seeker queries and employer job postings, removing the manual effort of optimizing job content for search.

By using the Jibe platform to integrate Cloud Talent Solution with its career site, job seekers are more easily finding what they’re looking for and J&J is filling business critical roles more efficiently.

Since integrating Cloud Talent Solution, J&J has seen a 41% increase in high-quality job applicants per search and a nearly 45% increase in click-through rate on its career site.

“Partnering with Jibe and using Cloud Talent Solution for our career site allows us to do a much better job matching opportunity to talent on a very large scale,” adds Sjoerd. “We’re able to take a more personal approach and really connect with job seekers, which is a win.”

“Today’s job seekers expect a prospective employer’s career site to work like the other cloud services they use. Using Google’s machine learning and artificial intelligence, we can help customers like J&J get better search results and return jobs that candidates are more likely to apply to.”

—Joe Essenfeld, Founder & CEO, Jibe

Connecting people with opportunities

J&J is now offering job seekers experiences in line with what they have come to expect as consumers—searching for a job should be as easy as searching for flights, restaurants, products, and other services. Because candidates are familiar with the experience, their level of interaction and engagement goes up, creating a larger pipeline of qualified candidates and filling jobs faster.

“Today’s job seekers expect a prospective employer’s career site to work like the other cloud services they use,” says Joe Essenfeld, Founder & CEO at Jibe. “Using Google’s machine learning and artificial intelligence, we can help customers like J&J get better search results and return jobs that candidates are more likely to apply to.”

A new digital revolution for recruiting

J&J continues to work with Jibe and Google to offer new features which make its career site even more effective. By offering job seekers a transformative, engaging experience, J&J is a more attractive and visible employer, increasing the value of its brand. It’s also continuously improving its recruiting process with end-to-end visibility and feedback from interactions with a million people every year.

“Transforming our career site with Jibe and Cloud Talent Solution directly impacts our ability to attract high-quality talent and hire those candidates faster,” adds Sjoerd. “Lots of people are looking for their dream job, and if it’s here at J&J, we want them to find it quickly and easily.”

Throughout the past couple of years, I have helped a good number of companies, big and small, migrate their systems to the Google Cloud Platform (aka GCP). During the course of these migrations, there are always a few of those moments where people look at a specific Google Cloud feature and say, “now, that’s cool!”.

More often than not, it is because, coming from other platforms, they have gotten used to some features requiring multiple steps, or some operations being complicated, etc. And often they find out that in GCP you can do this specific operation in a couple of clicks, or by setting up a simple text-based configuration. Then you see that light bulb turning on in their head, and there you go… happy customer.

A few of these happen so often that I compiled them in a list to share with others who might also benefit from these “aha!” moments. You could say these are the five things I wish they told me when I started using Google Cloud.

Projects: Naturally Group Resources Together

A project is a namespace where resources live. Every resource you instantiate in GCP, from load balancers to Kubernetes clusters to virtual machines, belongs to a single project, and has no access (by default) to resources in other projects. User roles and authorisations can be defined per-project and trickle down to everything in it. This has two immediate benefits: you can group things that belong together in neat logical units, and things that don’t belong together are isolated from each other (and isolation is a Good Thing)

This is powerful and quite simple, but it often takes new users off-guard. I’ve had many clients call me and ask me “How can I make sure my developers cannot access the production machines? What’s the best way to create access policies? ”

The answer to this is actually super-simple:

• have a project for development where your developers have rights,
• have a project for production where they don’t.
• That’s it.

Every machine/other resource in the production project won’t be accessible to developers.

Of course there is a lot more to it, and you can refine roles and permissions to a much greater degree using Organizations, Folders, etc. Not to mention all the crazy things you can do with per-project billing. But at least you can say “hey, if it’s a machine in the staging environment then it can be found in the “staging” project”.

Global Virtual Networks Are *Truly* Global

Imagine you are using a Cloud provider and that you have servers in the US, and servers in Singapore, and that they need to communicate.

So you create a VPC (Virtual Private Cloud) network in the US data center, another one in the Singapore data center, and then you will connect them by setting up inter-region VPC peering or a VPN (Virtual Private Network) or a transit VPC or other routing magic.

Lots of work, right? And many moving parts, so lots of opportunities for things to break.

With GCP, however, what makes my clients go “aha!” is when they realize that in GCP a single VPC network covers the entire planet. Only subnets are attached to a geographic location, and virtual machines communicate between subnets on private IPs (good old RFC1918 addresses) — no extra routing needed.

So, to make your server communicate across continents on GCP, here are the steps:

• create a VPC network
• create a subnet in the US, put your US servers in it
• create a subnet in Singapore, put your Singapore servers in it

That’s all there is to it. Your VPC network spanning 2 continents is ready to use. Below is a screenshot of how it looks on my account, for a VPC network called ‘my-global-network’ with 2 subnets. The first column (“us-central1” and “asia-southeast1”) contains the name of the GCP regions (read: data centers). The second column is the subnet name that I picked when I created them.

A machine in the US (on the “us-central” subnet) with IP 10.0.0.5 can communicate directly with a machine in Singapore (on the “singapore”) subnet with IP 10.10.0.8.

Nothing else to set up.

And thanks to the way these networks work, the Google Cloud Load Balancer can present a single IP to the world, and forward traffic to the instances that are the closest to you geographically without having to setup a tedious DNS-based load balancing. But that’s worth an entire blog. I’ll save it for another day.

Firewalls with Tags and (Almost) No IP Addresses

There is no network security without a firewall so unsurprisingly GCP comes with one built-in.

Now, I don’t know about you, but nothing makes my brain hurt like a list of firewall rules displaying IP ranges and addresses and ‘Allow/Deny’ directives. It looks a bit like this:

If you imagine a normal network with a few dozen (hundred?) servers, you can quickly see how this can get out of control. You’d better have a solid printout of your network layout to refer to when you start adding and changing rules. And good luck debugging things!

Wouldn’t it be nice if, instead, you could just tell the firewall: “the HTTP traffic from outside can only reach the HTTP servers and the MySQL database is only reachable by the HTTP server(s) on the same network?”

Turns out it’s pretty simple on GCP by using a little thing called network tags. As the documentation says:

“Network tags are text attributes you can add to Compute Engine virtual machine (VM) instances. Tags allow you to make firewall rules and routes applicable to specific VM instances.”

So let’s see how it works. Firewall rules in GCP are defined in terms of source and target (the traffic flows from the source to the target). You can define filtering rules that apply to the source or the target, and in both cases you can use tags.

This is simpler shown with an example. The rule below states that on the default network, the traffic to the VMs with the tag mysql-server can come from the VMs with the tag http-appserver. Any other traffic is “Deny”-ed by default.

All you have to do is to tag your machines properly, and they will automatically be covered by the rule. You don’t need to enter their IP range.

That’s neat if you ask me. It makes it a lot simpler to grasp what’s happening.

Of course, there’s a TON more to firewalls in GCP. Tags also apply to routes and you can mix and match IP-based rules with tag-based rules. Not to mention that thing called service accounts, but I’ll leave those for another day.

The bottom line is that you can create most rules by just expressing a business need and not having to remember complicated network layouts. I have no hard stats, but I’m pretty sure this has saved me hours of work.

Console Access to VMs from the Browser

Easily access virtual machines (VMs) from the Google Cloud console was one of my first “aha!” moments when I started using GCP.

This is a screen capture of my Google Cloud console, with a virtual machine and its internal IP.

The last column has a header that says “Connect” and when you click on the word “SSH” a separate windows pops up. You wait for a few seconds, and… this is what you get. Your personal shell access — in a browser popup no less.

You are connected through ssh to the virtual machine of your choice. You did not have to download ssh keys and put them in the ~/.ssh directory, do the correct chmod command and run a long-winded ssh -i ~/.ssh/somekey me@<it-took-me-forever-to-copy-paste-the-address-here>

In addition, you have access to a few nifty features such as uploading and downloading files, changing the user etc. Just use the menu behind the cog icon at the top right.

In truth, you should not need to connect directly that often, but when you have to, this is a godsend.

Your Personal Jumphost from the Google Cloud Console

The Google Cloud console has a cool trick: you can actually connect to a virtual environment that is managed by the Google Cloud console itself. It serves a bit as a jump host. You can access most resources from the projects from it, and you can activate it directly from the top menu with, no particular setup on your side. It’s called the Cloud Shell.

This is how it looks at the top right of the console:

When you activate the Cloud Shell, the session opens at the bottom of the console. You get a command line prompt and it’s fully configured with the gcloud command line tool (the jack-of-all-trades of Google Cloud scripting).

You can do a great many things from there, and this even includes uploading and downloading files, editing code or deploying it, a web preview for your AppEngine application, and more.

So you can get access to a fully configured shell environment in your project from any laptop where you can connect with your credentials. On top of this, it persists between connections so you can fine-tune it to your needs and have these changes available the next time you re-connect.

This has saved me many times during my previous life as a traveling consultant!

Live migration

Did I say 5 “Aha!” moments ? Well, you’ve been patient reading all the way to here, so here’s one more for free.

Google Cloud has an amazing way to literally “teleport” a running virtual machine between physical hosts without stopping it. It’s called Live Migration. It allows Google to move your virtual machine away from a defective host, or a host that needs a patch or an upgrade, or for any other infrastructure related reason.

It’s all done in the background, and is totally transparent, so you never really see it happening. Unless you look VERY closely. I once did a demo to a client, where a machine was live migrated while he was simulating a solid network load — and we did not lose a single packet, with no noticeable degradation in latency.

And that’s a wrap!

So there you go. These are 5+1 things that made me go “Aha!” when I became more familiar with the Google Cloud Platform, and that still make my clients do the same.

There is a lot of depth to the platform, and my examples above only scratch the surface of our features. I encourage you to try it yourself. There is a generous free tier, and when you are ready to take the plunge and create that new company, please contact us at Google Cloud for Startups. We’ll get you up and running in no time.

Jerome is a Startup Architect at Google Cloud. Based in Singapore, he helps startups make the most of the Google Cloud Platform.

While some traditional financial services companies have more slowly transitioned to the cloud, capital markets firms have embraced cloud computing across their entire value chains — front-, middle-, and back-office. We wanted to understand the dynamics behind this rapid adoption, the most common use cases, and the types of technology most in use, particularly as it relates to market data. Google Cloud commissioned Coalition Greenwich to survey 102 institutional capital markets professionals — at exchanges, trading systems, data aggregators, data producers, asset managers, hedge funds, and investment banks — in the United States, Canada, France, Germany, Italy, the Netherlands, Switzerland, and the United Kingdom. 

Our research found that while there are many drivers, demand for easier accessibility is fueling widespread adoption of cloud-based market data services, and associated trading infrastructures, across the buy side and sell side. In fact, 68% of sell-side and buy-side users find it critical for market data providers to offer public cloud-based data services. At the same time, exchanges, market data providers, aggregators, and trading systems are embracing the cloud as a delivery model by offering access to data directly via their own cloud services, APIs or partners.

Here were five noteworthy takeaways from the study: 

1. Cloud services are becoming ubiquitous for data delivery. Today, the cloud is pervasive, with 93% of exchanges, trading systems and data providers offering cloud-based data and services, according to surveyed executives. Moreover, 100% of those surveyed intend to offer new cloud-based services, such as derived data, in the next 12 months.

2. Commercial and investment banks are offering additional connectivity, real-time data feeds, and trading applications delivered via the cloud,demonstrating that it’s not only exchanges, trading systems, and data providers that are moving rapidly to the cloud. Internal use cases abound as well, with 67% of those surveyed consuming cloud-deployed market data, primarily for data analytics. 88% of surveyed sell-side firms intend to consume cloud-based market data services, with digital transformation, data science and quant research as the top use cases.

3. Buy side firms will consume even more cloud-deployed data. Today, 90% of surveyed buy-side firms are consuming cloud-deployed market data, mostly for portfolio management. 70% of buy-side firms intend to consume more public cloud-based market data services in the next 12 months, adding services such as compliance and regulatory reporting.

4. AI/ML, powered by cloud, is moving out of the pilot phase and into mainstream use. Today, 50% of exchanges, trading systems, and data providers are offering data products or services powered by AI/ML, and of those, 42% intend to offer AI-powered trade execution and trading analytics services in the next 12 months. Within commercial and investment banks, 55% said they are currently using AI/ML in the cloud, and while that was true for only 14% of overall buy-side respondents, 44% of large buy-side respondents are using it.

5. Exchanges, trading systems, and data providers are prioritizing public cloud for internal insights. 71% of these firms are using the public cloud, mostly for data transmission, processing, analysis, and long-term data storage. Over the next 12 months, 33% of new public cloud workloads will focus on data mining, data insights and advanced analytics, while 28% of new AI/ML tooling and infrastructure investments will focus on faster analytics and risk reviews, and 27% on data quality maintenance.

“We see new, dramatic shifts on the adoption of cloud across market data,” said David Easthope, Senior Analyst for Coalition Greenwich. “And we expect further proliferation of cloud-based services and greater consumption across the trading and investing lifecycle.”

Conclusions and future predictions

Based on the survey results, Coalition Greenwich predicts five following trends over the next 12 months:

1. Exchanges and trading systems will continue to launch a wide array of new cloud-based and possibly cloud exclusive data services across derived data, end of day data, reference data and pricing data.
2. Data providers will launch new data products such as pre-trade analytics powered by AI/ML in the cloud.
3. Commercial and investment banks will offer additional connectivity, real-time data feeds, and trading applications delivered via the cloud.
4. Buy-side firms will consume even more cloud-deployed data, including real-time market data, portfolio management data, and risk analytics.
5. Exchanges, trading systems and data providers will explore proof-of-concepts around core systems on the cloud. Improvements to AI/ML tooling or infrastructure will ramp up as firms seek more rapid responses to risk initiatives.

To learn more about these findings, download our two full reports, The Future of market data: Distribution and consumption through cloud and AI and Exchanges and data providers: Prioritizing the cloud and AI for internal insights or our short infographic.

Research methodology

The survey was conducted online by Coalition Greenwich on behalf of Google Cloud from March 2021 to April 2021 among 102 executives in North America (n=82), EMEA (n=17) and other (n=3) who are employed full-time and who are participants or influencers in decisions around cloud and/or senior management with a role at a company which is an institutional asset manager, hedge fund, alternative investment manager, exchange and/or trading system, information provider, information aggregator, or other asset manager/asset owner. The survey included wide perspectives from a range of firm size and asset class focus, including equity, fixed income, FX, commodities, multi-asset, and other asset classes.

Foot Notes

1.  We defined market data as direct feeds, consolidated feeds, terminal and desktop products, security and reference data, pricing data, historical data, alternative data, and index data.

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.

https://youtube.com/watch?v=xFSDexQhCUY%3Fenablejsapi%3D1%26

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.

https://youtube.com/watch?v=B1VH56_L8f8%3Fenablejsapi%3D1%26

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!

https://youtube.com/watch?v=I9sqXDqkKBM%3Fenablejsapi%3D1%26

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.

https://youtube.com/watch?v=mrSb5vqOfuI%3Fenablejsapi%3D1%26

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!