2020 brought many challenges, especially as in-person operations were shut down, and many were left vulnerable to unemployment.

The State of Rhode Island responded to these challenges, by modernizing their workforce development operations and moving completely to a custom online platform called the Virtual Career Center, also nicknamed “the VCC.”

It was developed in partnership with Google Cloud and a nonprofit called “Research Improving People’s Lives” (RIPL), and was fully built by Google Cloud partner Maven Wave, which helps a wide array of organizations, including public sector customers, with many types of cloud initiatives.

In this episode of Architecting with Google Cloud, we interviewed Joel Osman, head of Digital Experience & Custom Applications at MavenWave who shared a lot of insights such as:

“We looked at how we can apply leading edge emerging technologies to help people get back to work and use them as tools in such a way that we can augment the personal one to one interactions that agencies had been using with job seekers, to help them get back to work.”

One of those key benefits is enabling job seekers to find coaches that are specialized in their respective community. During the in-person walk-in model, applicants were paired on a first come first serve basis with any available coach on site. Meanwhile online scheduling has enabled a greater opportunity to match veterans, college graduates, non-English speakers, etc with coaches with prior experience in that specific area.

How the VCC was built

This VCC web app was built on Angular. It has a custom frontend built on top of 2 key Google Cloud products. The first is Workspace, which includes functionality such as video conferencing, documents, slides, chat, file storage, etc. And the other is Google Cloud computing resources. Here’s a view of the architecture:

There are 3 main types of users at this time, and that’s job coaches, job seekers, and employers.

• 👩‍🔧 Job Coaches all have Google IDs in the Google Workspace domain, and therefore authenticate against the Google identity repository.
• 🕵️‍♂️ Job Seekers are authenticated through a Cognito-based process maintained by the nonprofit I mentioned earlier (RIPL), the Rhode Island infrastructure team, and the Department of Information Technology (DoIT). Cognito was an identity repository setup prior to this project for users interacting with the State, and remained as their form of authentication.
• 🧭 Employers participate directly with Google Meet, and, to an extent, Google Calendar; but not the Angular app. There’s also a focus on building a future dashboard to see how the center has helped employers with applicants.

The specific Google Cloud components used are the following:

• Firestore: realtime Database that keeps data in sync across client apps.
• BigQuery: serverless warehouse for data.
• Data Studio: is used to build filterable dashboards over BigQuery
• Cloud Functions: which serve as triggers to keep scheduling and data workflows in sync.
• Kubernetes cluster: runs & autoscales the server-side code in a single-region deployment, with a minimum of four nodes per zone across three zones of the US East region.
• Cloud Armor: protects applications and websites from attacks, and sets NIST-compliant policies.
• Google’s Content Distribution Network (CDN): content is accessed and cached.

To manage the lifecycle of the infrastructure, a Terraform script is used, which is an open source tool, and is structured into 5 folder environments:

• Admin
• Dev
• QA & UAT
• Networks
• Prod
• Shared Services (for CI/CD pipelines between Dev & Prod).

Adoption outcomes

A universal fear we technical practitioners may have is:

“Will our tool be loved and adopted by our intended audiences?”

 Joel mentioned Job Coaches at the time were not used to working from home, and the team was concerned that they would potentially feel overwhelmed with a lot of new technology.

 As a rewarding surprise, when Job Coaches were presented the proof of concept, it was received with positivity.

“95% of Job Coaches rated the VCC as a valuable solution and 87% reported to find it very or extremely effective.”

This alignment was thanks to designing the tool with the users in mind, and performing user research since the beginning of the journey, which helped address their day to day needs.

Additional innovation for the future

After creating a centralized hub and moving operations to a digital format, many more benefits also arise. For example, there can now be an integrated data analytics view which enables meaningful dashboards that can be customized for different audiences such as job applicants, coaches, program stakeholders, or state agencies.

There can be improved job searchability by integrating machine learning, helping with resume building and parsing that take keywords out of a resume and match them to a variety of relevant job clusters, rather than just performing raw keyword searches.

Embedding chat bots can also help reduce the load of call centers in states, as they utilize natural language processing as well to help guide job seekers with prompt answers.

Conclusion

The State of Rhode Island’s Virtual Career Center is an amazing success story. By having worked with an experienced partner to move their operations to a digital format, they were able to respond to their citizen’s needs in a time where in-person operations were not possible. They also unlocked opportunities such as better matching and reporting along that journey.

For any organization whether they are in the public sector, university, private sector, etc; anyone can take advantage of this platform and customize it to their needs as Maven Wave shared that they offer a menu of options, where you can pick and choose functionality based on your requirements, IT resources, and budget.

This week, the Vera C. Rubin Observatory is launching the first preview of its new Rubin Science Platform (RSP) for an initial cohort of astronomers. The observatory, which is located in Chile but managed by the U.S. National Science Foundation’s NOIRLab in Tucson, AZ and SLAC in California, is jointly funded by the NSF and the U.S. Department of Energy. The platform provides an easy-to-use interface to store and analyze the massive datasets of the Legacy Survey of Space and Time (LSST), which will survey a third of the sky each night for ten years, detecting billions of stars and galaxies, and millions of supernovae, variable stars, and small bodies in our Solar System.

The LSST datasets are unprecedented in size and complexity, and will be far too large for scientists to download to their personal computers for analysis. Instead, scientists will use the RSP to process, query, visualize, and analyze the LSST data archives through a mixture of web portal, notebook, and other virtual data analysis services. An initial launch with simulated data, called Data Preview 0, builds on the Rubin Observatory’s three-year partnership with Google to develop an Interim Data Facility (IDF) on Google Cloud to prototype hosting of the massive LSST dataset. This agreement marks the first time a cloud-based data facility has been used for an astronomy application of this magnitude.

Bringing the stars to the cloud

For Data Preview 0, the IDF leverages Cloud Storage, Google Kubernetes Engine (GKE), and Compute Engine to provide the Rubin Observatory user community access to simulated LSST data in an early version of the RSP. The simulated data were developed over several years by the LSST Dark Energy Science Collaboration to imitate five years of an LSST-like survey over 300 square degrees of the sky (about 1,500 times the area of the moon). The resulting images are very realistic: they have the same instrumental characteristics, such as pixel size and sensitivity to photons, that are expected from the Rubin Observatory’s LSST Camera, and they were processed with an early version of the LSST Science Pipelines that will eventually be used to process LSST data. “This will be the first time that these workloads have ever been hosted in a cloud environment. Researchers will have an opportunity to explore an early version of this platform,” says Ranpal Gill, senior manager and head of communications at the Rubin Observatory.

Broadening access for more researchers

Over 200 scientists and students with Rubin Observatory data rights were selected to participate in Data Preview 0 from a pool of applicants that represents a wide range of demographic criteria, regions, and experience level. Participants will be supported with resources such as tutorials, seminars, communication channels, and networking opportunities—and they will be free to pursue their own science at their own pace using the data in the RSP. 

“The revolutionary nature of the future LSST dataset requires a commensurately innovative system for data access and analysis paired with robust support for scientists,” says Melissa Graham, lead community scientist for the Rubin Observatory and research scientist in the astronomy department at the University of Washington. “I’m personally excited to enhance my own skills by using the RSP’s tools for big data analysis, while also helping others to learn and to pursue their LSST-related science goals during Data Preview 0.” 

At the same time, the fact that the RSP is hosted in the cloud provides researchers at smaller institutions access to state-of-the-art astronomy infrastructure that is comparable to that of the largest national research centers.

The launch benefits the observatory too: the development team can learn what researchers are interested in while also testing and debugging the platform. Graham says that “the platform is still in active development so researchers using it will be able to follow along in the progress, and provide feedback on ways that we can optimize the development of the tools.”

Next steps

The LSST aims to begin the ten-year survey in 2023-24 and expects it to include 500 petabytes of data. Through the cloud, Google aims to help make this extraordinary project scalable and accessible to researchers everywhere. To learn more about Data Preview 0, watch this video.

Want to ramp up your own research in the cloud? We offer research credits to academics using Google Cloud for qualifying projects in eligible countries. You can find our application form on Google Cloud’s website or contact our sales team.

Cloud infrastructure offers so many advantages: on-demand scalability, built-in security, and a bevy of tooling to scale your business at the speed of the Internet.

It enables companies to pursue “blitzscaling,” as Reid Hoffman calls it. Capital expenses that take years or decades to pay off are no longer required to establish global networking, compute capacity, storage resources, and application enablement tooling. By renting these assets from cloud providers, you can translate capital costs to operational costs, help your company to manage resources efficiently, keep expenses aligned with growth trajectory, and develop a portfolio of business-driving technology assets faster than would have previously been possible.

Certainly, this is the message from many founders and venture capitalists: move to the cloud, build a ton of software, scale like crazy, and win. Sounds great, right?

But history has shown us that the process is not quite this simple. Scale can be great and is a prerequisite to many of today’s most exciting business opportunities — but scale also frequently produces unintended consequences. You need to be able not only to achieve scale but also to manage it.

When scale produces bloat

To understand how unforeseen impacts can ripple out from a rapidly-scaled technology, consider the first mass-produced vehicle, the Model T. The first production model was produced in 1908, and less than two decades later, Ford had produced 15 million. This rapid growth profoundly affected urban living for decades.

Thanks to cars, fewer workers needed to live near cities or along major public transportation lines. The ease-of-access to personal transportation led to suburban population centers and, ultimately, urban sprawl. “Sub-cities” extricated homeowners from the density of urban population centers but also created a complex web of unintended consequences: new and often duplicative administrative bodies, new taxes, new zoning laws, and more intricate infrastructure projects. We are arguably still dealing with this fallout today as communities grapple with antiquated zoning laws and, in their attempts to find ways forward, often produce only more sprawl.

If your technology is in the cloud, you may be challenged with similar issues. For example, when developers build software in the cloud, many of the barriers to building software are removed. As a result, developers build a lot of software — but often without a lot of intentional design. This in turn results in companies building a large number of disparate systems and overwhelming app sprawl.

The cloud can help you proliferate technologies so quickly, in other words, that effective management and re-use of resources becomes incredibly tough.

Managing scale

Software assets are often seen as comprising the “brains” of a company — but to effectively grow, you should consider not only brains but also the digital nervous system. You need systems that connect the brains to all of the other important limbs that have to coordinate in order for your company to drive value.

One way of creating this nervous system and managing this complexity is to leverage the facade design pattern: applying an API layer that abstracts the underlying complexity of multiple systems into an elegant, reliable interface that encourages discovery and re-use of applications, functions, and other technology artifacts such as build and deployment pipelines.

For example, too many enterprises build a new digital “road” for each application that needs to authenticate or authorize users. Instead, you can leverage a facade pattern to help establish one “main road” for these purposes, encourage reuse of the road for new projects, and — with API management — monitor and control all traffic along the road. For tasks such as aligning risk and compliance operations or unifying developer onboarding functions, the distinction between reusing elegant roads and continually building new complicated ones could not be more important.

API management tools mean you can establish a single-pane-of-glass view into your network of digital roads and destinations or, if you prefer the biology metaphor, into the nervous system routes connecting your company’s software brains. This view becomes a point at which suspicious API usage patterns can be detected, reported, and handled and through which business-driving insights from legitimate traffic can be gleaned. Rather than dealing with IT sprawl, you can maintain visibility over your assets, control how they are used, roll out experimental digital products and get immediate feedback on adoption, and generate analytics to help you effectively divest from and invest in opportunities as the market demands.

More is not always better

More is not always better, and, in fact, it is sometimes worse.

It’s a time-worn sales axiom that would-be customers are more likely to make a choice when presented with two or three options rather than fifty, for example, and virtually all of us can relate to moments of “analysis paralysis” triggered by too many choices. These dynamics of choice are such that the diminishing marginal utility of each choice can detract from each option: with each choice comes a little stress, and as these stresses accumulate, customer satisfaction suffers. IT systems are no different; if developers building new connected experiences are left to their own designs, rather than encouraged with standardized resources and best practices, their work may add to complexity and customer dissatisfaction.

One need look only at the various open air markets around the world to see this point in action. They may offer many things to see but the experience is anything but efficient. The multitude of shops selling similar and duplicate items, the zigzag layout, and the expected friction from bargaining with each vendor all mean concepts such as market-wide product discovery and product inventory go out the window. If your developer experience mirrors these marketplaces, your efforts to scale are more likely to tangle up your operations than to satisfy customers.

Contrast this experience with luxury retail experiences where product areas are clearly demarcated in different retail spaces, product explanations accompany showcase items, inventory is available locally or ready to ship, clear pricing is readily available, and similar stores are intentionally anchored to strategic physical areas to encourage customer flow among them. The developer programs that cloud efforts are often meant to enable require a similar focus on luxurious experiences.

If your growth strategy creates bloat, internal developers will not use resources efficiently and your ability to share resources with external partners will likely be hamstrung. Applying API facades helps to ensure that your growing software portfolio is not a complicated maze to be navigated but rather a series of technology products for developers to leverage.

Indeed, you should think of the API itself as a product, not just a way of surfacing or connecting technology. The better the product, the more easily it can be managed, the better the experience developers will have using it, and the more control you’ll have harnessing the cloud to extend your business’s footprint.