Based in Mountain View, California, Khan Academy is a not-for-profit that produces and posts a vast collection of free educational online videos about math and science topics ranging from algebra and trigonometry to biology and economics.

Millions of students, educators, and self-learners around the world watch the videos, both on the Khan Academy’s YouTube channel and on its hugely popular website (www.khanacademy.org), where students answer some 1.5 million practice questions per school day. The Khan Academy development team continually tweaks the site based on how visitors choose to learn.

Challenge

Khan Academy’s beginnings date back to 2004, when Sal Khan’s cousin asked him to remotely tutor her daughter in math. Khan was happy to help and more than qualified, given his three MIT degrees and his Harvard MBA.

As more relatives and friends asked Khan for tutoring assistance, he began videotaping short lessons and posting them to YouTube. His knack for distilling complex concepts into easy-to-follow tutorials helped the videos go viral.

Sal knew he needed to offload the technical and maintenance concerns so he could work on what was important. To grow, it was important for him to be able to stop worrying about things like deployment issues and running his own server.

Ben Kamens, lead developer for Khan Academy

Khan maintained a website for his growing video library for several years, but the platform experienced limitations as traffic increased.

At the same time, media attention was growing, and technology industry leaders, including Microsoft founder Bill Gates and Silicon Valley venture capitalist John Doerr, began lending their support and evangelizing Khan’s mission and work. It was at this point that Khan quit his job as a hedge fund analyst to devote his full-time attention to the site’s growing potential.

“With Google App Engine, we don’t need a system administrator or anyone dedicated to deploying our app, so 99 percent of our time is spent working on our application,” says Ben Kamens, lead developer, Khan Academy.

“Sal knew he needed to offload the technical and maintenance concerns so he could work on what was important, which was to make more videos for the Khan Academy library,” explains Ben Kamens, lead developer for Khan Academy. “To grow, it was important for him to be able to stop worrying about things like deployment issues and running his own server.”

Solution

Khan Academy chose App Engine as its hosting and application development platform because App Engine could easily house its growing collection of 2,000-plus videos, resolving the organization’s overall server and maintenance issues with a single solution.

Using App Engine freed the team to focus on the user experience and the array of content that makes the academy such a powerhouse.

“A lot of what the Khan Academy is about is collecting data on student behavior so we can teach them better,” Kamens says. “Did they use a hint? Have they watched the video before? That data is being stored on Google App Engine so we can figure out what the most effective videos are, or where students struggle the most.”

Khan Academy provides individual profiles to students so they can analyze their learning progress, which means the organization needs systems running in the background to collect and track of all this data. Because App Engine takes care of server support, Khan Academy’s five developers can spend almost all of their time improving site functionality.

“If we didn’t have Google App Engine, we’d be spending a lot more time figuring out server setup and working on routers,” Kamens says. “Our ability to focus on the actual product is the benefit of Google App Engine.”

With the App Engine dashboard, which provides information like response time, uptime, and error rates, the development team also has an easy way to watch over site performance. “It lets us see what the average response time is, so we can keep it really low,” Kamens explains.

Results

During the US school year, Khan Academy receives more than 3.8 million unique visits a month — all served through App Engine. To support this much traffic, a typical company would need an internal system administration staff.

“With Google App Engine, we don’t need a system administrator or anyone dedicated to deploying our app, so 99 percent of our time is spent working on our application,” explains Kamens. “Our application lives on Google App Engine, and we bank all of our scalability and traffic concerns on Google App Engine. Even huge traffic spikes from Sal’s media appearances don’t worry us since we know that Google App Engine will handle the spike.”

Kamens also likes the fact that he and his team can turn to the Google App Engine support team for assistance when they need it. He also finds helpful tips on the Google App Engine blog.

The Khan Academy staff has come to completely rely on App Engine. “We are constantly using more of Google App Engine’s capabilities and have been happy with the performance,” Kamens says. “It’s nice to have an easy deployment process since we deploy the site on average at least once a day, [and] sometimes up to nine or 10 times [a day].”

We’re excited to announce that Spring Cloud GCP version 4.0 is now generally available! In this post, we’ll be describing what the new major version has to offer, and demonstrating the process of using the migration guide on one of our reference architectures, Bank of Anthos.

What’s new?

With this release, Spring Cloud GCP officially supports Spring Boot 3.x. However, this migration involves a number of breaking changes as outlined in the migration guide. The full list of changes made is available on Github, but the one of the most significant differences is that Java 17 is now a minimum requirement.

Another notable feature of this release is the addition of starter artifacts – Spring Boot starters for Google Cloud – that provide dependencies and auto-configurations for 80+ Google Client libraries. Just as the name suggests, these starters can serve as helpful starting points when working with a new client library. For now, they’re in preview. 

These starters are not included in the BOM by default and need to be added as a dependency to your project before they can be used. For example, if you wanted to get started with Cloud Text-to-Speech, you would include the following:

<dependency>
    <groupId>com.google.cloud</groupId>
    <artifactId>google-cloud-texttospeech-spring-starter</artifactId>
    <version>4.0.0-preview</version>
  </dependency>

The upgrade process

We prepared a migration guide to help answer any questions involved with moving from 3.x to 4.x.  Let’s follow those instructions to migrate Bank of Anthos.

We’ll start by cloning and building the application before the upgrade, according to the quickstart and development guide:

PROJECT_ID=<YOUR-PROJECT-ID>
gcloud services enable container --project ${PROJECT_ID}

git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
cd bank-of-anthos/

gcloud services enable container.googleapis.com monitoring.googleapis.com \
  --project ${PROJECT_ID}

REGION=us-central1
gcloud container clusters create-auto bank-of-anthos \
  --project=${PROJECT_ID} --region=${REGION}

gcloud container clusters get-credentials bank-of-anthos \
  --project=${PROJECT_ID} --region=${REGION}

skaffold run --default-repo=gcr.io/${PROJECT_ID}/bank-of-anthos

At the end of this, you should see a “deployment stabilized” message:

Deployments stabilized in 9.657 seconds

With the environment set up for development, we’re ready to move on to the actual migration. The migration is already complete at time of writing, but here’s the full list of changes made:

• We began by checking the current Java, Spring Boot and Spring Cloud GCP versions.
  • Our Java version is okay, but the other two are out of date, and will need to be updated.
    We can also add the Spring Cloud GCP BOM to manage our versions going forward while we’re here.
• Then, in no particular order, we can make the following code changes:
  • Remove the explicit type declarations from our ResponseEntity instantiations.
  • Replace all javax.* imports with Jakarta.* counterparts, since Spring 3.0 makes use of Jakarta EE 9.0

With those changes in place, the app is upgraded and ready to re-deploy!

Live example

For a finished example of this migration, check out the Bank of Anthos repository on Github. It’s an excellent sample application that showcases a polyglot Java & Python app, served on Kubernetes and Google Cloud. All CI/CD and configurations are open source, so it may be instructive as you approach this migration.

Thanks for reading, and feel free to provide comments or feedback on Twitter, or in the issues section of the repository.

Apps play a critical role in an ever-expanding range of healthcare services, as patients and providers increasingly expect streamlined, engaging digital experiences. This means that IT must become faster, more agile, and free from the constraints of everyday infrastructure management.

At Cardinal Health, we are continuously enhancing our technology to empower innovators across our organization as they strive to build connections across the continuum of care. Through our efforts, we have adopted a continuous integration and continuous delivery (CI/CD) pipeline that powers breakthroughs and drives innovation. Our CI/CID pipelines use a combination of Cloud Build for foundational elements, as well as our internal DevSecOps platform, NitroDX, to deploy our application workloads built on Google Cloud.

This CI/CD pipeline powered the development of our Pharmacy Marketing Advantage (PMA) Commerce, which was built from the ground up on Google Kubernetes Engine (GKE), to provide independent pharmacists with a digital platform that expands online shopping capabilities for patients by offering more than 11,000 over-the-counter products. We also replatformed our Order Express tool, which is a simple, reliable web ordering application for independent pharmacists, from on-prem to Google Compute Engine and GKE, which allowed us to shift from quarterly releases to weekly on-demand releases.

Our application teams work in close alignment with our product teams and handle everything from basic software updates to more advanced cloud-native app development. We place tremendous value on our ability to empower our application teams, and we invest in tools and technologies to make them as efficient and successful as possible.

As part of our efforts to optimize applications and deliver engaging digital experiences for our customers and their patients, we saw the value of rethinking our approach to storage and overall IT administration. Working with the NetApp Cloud Volume Service (CVS), a fully managed storage service, and Google Cloud, we fundamentally changed our IT capabilities.

Accelerating app development

As a cloud-first company, Cardinal Health has embraced a managed approach to IT provisioning in many areas. When we offload responsibilities like infrastructure maintenance, patching, and updates, we enable our developers to focus on continuous innovations that directly impact the quality of patient and provider experiences.

We’ve made measurable progress in automating our CI/CD pipelines to simplify provisioning Virtual Machines (VMs), managing firewall rules, launching Google Cloud projects, and more. Our NitroDx platform also significantly reduced development time from weeks to minutes, improving the software delivery process and accelerating digital transformation.

Google Cloud is our primary cloud services vendor and has removed much of the heavy lifting related to server provisioning, firmware patches, and similar tasks. We rely on a mix of Google Cloud services, including Compute Engine, GKE, BigQuery, and Vertex AI to deliver patient-centric solutions. We also work closely with partners like NetApp to improve our storage management at a much greater scale and more efficiently than we could do on our own.

By using a combination of NetApp and Google Cloud solutions, we’ve been able to decouple storage from our underlying infrastructure to make better use of our resources and accelerate app development. When running on-prem, shared storage proved to be a time and resource drain.

If an application needed shared storage in our legacy on-prem environment, we had to communicate the requirements to an engineer and create a change control. And even then, if all staff and funding were in place to support the change, it would take weeks to complete. This held up projects and delayed our time to market.

We quickly overcame this challenge with NetApp CVS. Through this tool, we can delegate permissions directly within a teams’ Google Cloud project, allowing them to administer their own shared volumes. This translates to on-demand shared storage without operational complexities or the need for dedicated teams to manage it.

We were an early adopter of NetApp CVS, and we’re happy to have made that decision. In addition to cost savings and faster time-to-market, we can now provide our staff with more professional development opportunities. The team members who made up the dedicated storage team now work across the cloud organization, focused on innovation and enablement rather than maintenance.

A stronger foundation for developers to stand on

We constantly work to fill gaps at any point in the developer experience. Containerizing our apps and deploying to GKE has been a major part of this process, driving efficiencies through consolidation and improving our processes to keep our operating systems patched, updated and maintained.

In the past, it was also difficult for us to get reproducible or CI/CD pipelines into our application spaces. Now, we make things easier for application teams as we can provide a CI/CD pipeline for the containers themselves, automating more of the underlying technology to keep developers moving forward.

As we shift more traditional virtual machine (VM) workloads into GKE and leverage NetApp CVS for shared storage, our developers can more easily plug into file-based services. This further accelerates app development and deployments and fuels a more easily managed, efficient CI/CD framework focused on value, not system maintenance.

Smart, data-driven decisions

We’ve been impressed by how quickly we can aggregate data, analyze it, and uncover insights with BigQuery, Vertex AI, and Dataproc — at a speed that would not have been possible without Google Cloud. Vertex AI pipelines helped us automate and standardize our ML operations so data scientists can focus on innovating code vs. managing deployments. This allowed us to make improvements in areas such as more accurately predicting market demand and providing more relevant product recommendations to our customers.

To date, Google Cloud has collaborated with us on many projects, giving us access to early-release products, listening to our needs, and applying our feedback to their product development. Likewise, NetApp continues to work closely with us to expand what is possible with NetApp CVS, particularly with the types of data we can store and the ability to manage it easily.

It’s an excellent partnership, and our work with Google Cloud and NetApp helps us redefine the possibilities of app modernization in healthcare. We can continue to push boundaries of speed, agility, and success of CI/CD pipelines. It’s exciting to see what we are accomplishing today and what we’ll do in the future to constantly improve our customer’s digital experience.

Learn how integrated solutions with NetApp on Google Cloud can help you unlock the full potential of your data.