On April 6th, 2022, Google Cloud established a new partnership with CAST, to help accelerate the migration and application modernization programs of customers worldwide, complementing the Google capabilities already available through the Google Cloud Application Modernization Program (CAMP).

Application Rationalization (App Rat) is the first step towards a cloud adoption or migration journey, through which you go over the application inventory to determine which applications should be Retired, Retained, Refactored, Replatformed, or Reimagined.

Why is this important to you?

Have the majority of your in-house applications still not moved to the cloud? How much time does your development team spend on support (bug fix, tickets, etc.) versus feature(s) development? Have Infrastructure/Platform dependencies ever delayed product rollout? Would an auto-scalable, managed cloud, increase stakeholder buy-in?

Can Google simplify this journey?

Google Cloud Application Modernization Program (CAMP) has been designed as an end-to-end framework to help guide organizations through their modernization journey by assessing where they are today, and provide a path forward. When it comes to App Rationalization, this depends on what your role is.

Step 1 (Assess): Who is the target audience? The Platform team (or) the Application team?

This determines what kind of challenges we are trying to solve. For e.g. the centralized platform team wants to set some guardrails on how the App teams deploy their apps. Streamlining this would allow the platform team to mature themselves into the SRE territory. The application team, on the other hand, loves flexibility, and the ability to perform Continuous Delivery.

These examples are only the tip of the iceberg. Most of the enterprise customers have a majority of their applications in the legacy world. Unless we move those business critical applications to the cloud, it’s impossible to mature as an enterprise. For more information, check State of DevOps 2021 report.

Step 2 (Analyze): Google Cloud offers the tooling and the framework to analyze your legacy applications.

Platform Owner (persona), usually have very little information on which workloads are a good fit for modernization.

Google’s StratoZone® SaaS platform provides customers with a data-driven cloud decision framework. The StratoProbe® Data Collector Application delivers the ability to easily deploy and scale the discovery of a customer’s IT environment for Private, Public, or Hybrid-cloud planning. To ease and accelerate the VM migration journey, Google Cloud offers assistance and guidance in making the right decisions when deciding to go to cloud.

Google’s mFit aims at unblocking customers in their transformation by providing workload selection for successful on-boarding, at scale, to Anthos, GKE and Cloud Run , in both pre-sales (e.g. proof-of-concept/proof-of-value) and post-sales (e.g. pilot and at scale execution) scenarios.

App and/or Business Owners (persona), get involved in a 1-week workshop, using CAST Highlight, which would provide rapid portfolio assessment through automated source code analysis for Cloud Readiness, Open Source risks, Resiliency, and Agility.

Step 3 (Plan & execute): Each organization is different. Some may follow the “Migration Factory” approach, and some may follow “Modernization Factory”, and some may follow both. Irrespective of which approach you choose to follow, it is important to plan just enough, so that you can start your execution. Ensure to set the OKRs, that would help with the right measurements, before you start the execution. The actual learning from the execution helps the team(s) to learn more about the cloud migration process, and refine it based on their organization.

Using CAST Highlight in the assessment step previously, we get the recommendation for the analyzed applications. From there, for certain workloads, we can use Migrate to Containers, to automate the containerization of suitable workloads. However, there are certain applications that require manual code changes. You have a few options for that,

• Our experts can help you get started.
• Our partners can help you

Step 4 (Measure & reiterate): Measure the progress using the predefined metrics in the previous step. Celebrate the wins. Consistently share the learnings and best practices with the developer community. Pick the next challenge

Take the next step

Tell us what you’re solving for. A Google Cloud expert will help you find the best solution.

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

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.

When it comes to creating a business that can thrive in the digital age, the benefits of DevOps are clear. In a recent survey sponsored by Google Cloud, Harvard Business Review Analytic Services found that about two-thirds of the respondents who use DevOps have seen benefits that impact their bottom line, including increased speed to market (identified by 70% of the respondents), productivity (67%), customer relevance (67%), innovation (66%) and product/service quality (64%). Not only do these factors deliver profitability, but they’re precisely what cements a winning reputation among customers – the ultimate payoff.

We’ve seen these benefits within Google where DevOps helped us build secure products used and loved by billions of people across the world. However, as head of DevOps practices at Google, I know firsthand how daunting implementing a new model can be, even if it’s worthwhile. Intrigued but unsure of where to begin, customers constantly ask me: “How can I make DevOps a reality?”

Implementing DevOps can be really hard. Getting people to work differently doesn’t happen overnight. From our own journey toward embracing what are now known as DevOps practices, we learned seven critical lessons essential to adopting a DevOps model:

1. Pilot a small project. This provides a low-stakes opportunity to master key DevOps capabilities, such as building small, diverse teams with shared goal. A few small wins will provide evidence to the rest of organization that DevOps works. Soon others will want to follow suit.

2. Be an open-source player. Leveraging open-source tools and engaging in the community keeps you up-to-date on the best solutions and practices and attracts top talent. It also flattens your company’s learning curve and speeds up release cycles. According to a recent DORA study, 58% of businesses made extensive use of open source.

3. Embed security within software development process. By addressing potential security issues as early as possible, you’ll avoid pushing those issues out to production. Over half of participants in the Harvard Business Review Analytic Services survey look for holistic approaches to improve security while automating the DevOps toolchain. In addition, the recent DORA study also found that top performers who build security into software development conduct security reviews and complete changes in just days.

4. Apply DevOps best practices. Use Site Reliability Engineering (SRE) principles to help build collaboration, reduce waste, and increase efficiency. Also look for ways to implement end-to-end automation. Not only does automation enable higher productivity, it frees organizations up to focus on what really matters:  delivering value and driving performance.

5. Provide immersive training. People will only commit to organizational change when they understand its premise and are given the resources and opportunity to put new tech to work. That’s why three-quarters of the top-performing DevOps teams in the Harvard Business Review Analytic Services survey, as well as Google, provide immersive, hands-on DevOps coaching and training, such as code labs and quick-start projects.

6. Establish a no-blame culture. By running blameless post-mortem meetings in a safe environment built on trust, we learn from our mistakes. Because let’s face it, defects and coding errors happen when building software. By presenting mistakes as opportunities, you enable people to relate to one another and solve problems together, while ensuring that the same mistake won’t happen again. That’s how the DevOps model can evolve faster.

7. Build a culture that supports DevOps.  I’m underlining this because the rest is worthless without it. When people feel like they have each other’s backs, they’re more likely to take smart risks; more likely to create; more likely to move faster. Trust comes down to these principles:

• Data-driven decisions: Look at data from code, logs, and traces, and use that data to arrive at decisions.
  
• Transparency: Choose sharing over secrecy and siloing. Everyone sees the same data means everyone feels comfortable and confident.
  
• Shared goals: Constantly collaborate so developers and operators are working toward a common goal.
  

Those are the basics. Reading the Harvard Business Review Analytic Services survey in its entirety will help flesh out the details. The report is full of proven tactics used by the most successful DevOps-based businesses, as well as statistics that demonstrate why it’s a worthy investment. After you’ve digested those facts and figures, consider my own intangible observation: there’s something magical about understanding what makes people productive, collaborating with them, and then empowering them to deliver value. Hope you get as much out of this transformation as we did.

Vodafone India had a manual, labor-intensive process for determining network capabilities and reach. The company sent field operatives to every customer location to conduct a feasibility study. These feasibility studies help Vodafone determine whether they can provide connectivity and services to customers based on the infrastructure at that location.

Everyone from the IT team and end users to the field operatives doing the work recognized the need to adopt a new solution to automate the measurements. They needed a technology that was easy to use and maintain.

“Vodafone used to manually perform physical surveys for each feasibility, which is a time-consuming and labor-intensive process. Often, feasibility studies were delayed, and we missed out on opportunities to serve additional customers. With SmartFeasibility, we’ve increased our capacity 15 fold, which positively impacts our bottom line and allows us to provide better and smarter customer service.”

—Rajneesh Asthana, IT Planning and Delivery, Vodafone India

Partnering with Lepton Software (a leading global provider of location-based analytics solution) Vodafone introduced SmartFeasibility—a solution that changed the feasibility testing from a manual to an automated process. This involved a full Google geo platform solution – leveraging world class technology like maps, roads and directions.

Google Maps Platform Results

• Employees are able to access information faster with SmartFeasibility—they have data at their fingertips, rather than waiting for an employee to collect it
• Field operatives have increased their conversion rates by providing more accurate readings on feasibilities and closing more customer business
• Addresses are now easy to find with a click of a button. The Vodafone India team can search feasibilities that have been loaded into the database, so if there’s an issue or if they need to reference a past action, they have that information at their fingertips
• 2 day turnaround versus 5 before the solution was implemented
• 400+ new customers added per day

With the new solution, Vodafone India no longer needs field operatives to manually calculate these measurements. With Google Maps, users can search customers’ addresses, calculate the distance between Vodafone’s location and the customer’s location and research building data such as height.

The old system of having field operatives collect data was unreliable. With Google Maps Platform, the Vodafone India team knows that the measurements are accurate and reliable.