Kitabisa is shaping the future of fundraising with Google Cloud - Build What's Next
Case Study

Kitabisa is shaping the future of fundraising with Google Cloud

3113

Of your peers have already read this article.

3:30 Minutes

The most insightful time you'll spend today!

Kitabisa's mission to inspire people to create a kinder world has never wavered. Here’s how they used the combination of seamless scalability, resilient data pipelines, and creative freedom to drive the future of their platform.

The name Kitabisa means “we can” in Bahasa Indonesia, the official language of Indonesia, and captures our aspirational ethos as Indonesia’s most popular fundraising platform. Since 2013, Kitabisa has been collecting donations in times of crisis and natural disasters to help millions in need. Pursuing our mission of “channeling kindness at scale,” we deploy AI algorithms to foster Southeast Asia’s philanthropic spirit with simplicity and transparency.

Unlike e-commerce platforms that can predict spikes in demand, such as during Black Friday, Kitabisa’s mission of raising funds when disasters like earthquakes strike is by definition unpredictable. This is why the ability to scale up and down seamlessly is critical to our social enterprise.

In 2020, Indonesia’s COVID-19 outbreak coincided with Ramadan. Even in normal times, this is a peak period, as the holy month inspires charitable activity. But during the pandemic, the crush of donations pushed our system beyond the breaking point. Our platform went down for a few minutes just as Indonesia’s giving spirit was at its height, creating frustrations for users.

A new cloud beginning

That’s when we realized we needed to embark on a new cloud journey, moving from our monolithic system to one based on microservices. This would enable us to scale up for surges in demand, but also scale down when a wave of giving subsides. We also needed a more flexible database that would allow us to ingest and process the vast amounts of data that flood into our system in times of crisis.

These requirements led us to re-architect our entire platform on Google Cloud. Guided by a proactive Google Cloud team, we migrated to Google Kubernetes Engine (GKE) for our overall containerized computing infrastructure, and from Amazon RDS to Cloud SQL for MySQL and PostgreSQL, for our managed database services.

The result surpassed our expectations. During the following year’s Ramadan season, we gained a 50% boost in computing resources to easily handle escalating crowdfunding demands on our system. This was thanks to both the seamless scaling of GKE and recommendations from the Google Cloud Partnership team on deploying and optimizing Cloud SQL instances with ProxySQL to optimize our managed database instances.

A progressive journey to kindness at scale

While Kitabisa’s mission has never wavered, our journey to optimized performance took us through several stages before we ultimately landed on our current architecture on Google Cloud.

Origins on a monolithic provider
Kitabisa was initially hosted on DigitalOcean, which only allowed us to run monolithic applications based on virtual machines (VMs) and a stateful managed database. This meant manually adding one VM at a time, which led to challenges in scaling up VMs and core memory when a disaster triggered a spike in donations.

Conversely, when a fundraising cycle was complete, we could not scale down automatically from the high specs of manually provisioned VMs, which was a strain on manpower and budgetary resources.

Transition to containers
To improve scalability, Kitabisa migrated from DigitalOcean to Amazon Web Services (AWS), where we hoped deploying load balancers would provide sufficient automated scaling to meet our network needs. However, we still found manual configurations to be too costly and labor-intensive.

We then attempted to improve automation by switching to a microservices-based architecture. But on Amazon Elastic Container Service (Amazon ECS) we hit a new pain point: when launching applications, we needed to ensure that they were compatible with CloudFormation in deployment, which reduced the flexibility of our solution building due to vendor locking.

We decided it was “never too late” to migrate to Kubernetes, which is a more agile containerized solution. Given that we were already using AWS, it seemed natural to move our microservices to Amazon Elastics Kubernetes Service (Amazon EKS). But we soon found that provisioning Kubernetes clusters with EKS was still a manual process that required a lot of configuration work for every deployment.

Unlocking automated scalability
At the height of the COVID-19 crisis, faced with mounting demands on our system, we decided it was time to give Google Kubernetes Engine (GKE) a try. Since Kubernetes is a Google-designed solution, it seemed likeliest that GKE would provide the most flexible microservices deployment, alongside better access to new features.

Through a direct comparison with AWS, we discovered that everything from provisioning Kubernetes clusters to deploying new applications became fully automated, with the latest upgrades and minimal manual setups. By switching to GKE, we can now absorb any unexpected surge in donations, and add new services without expanding the size of our engineering team. The transformative value of GKE became apparent when severe flooding hit Sumatra in November 2021, affecting 25,000 people. Our system easily handled the 30% spike in donations.

Moving to Cloud SQL and ProxySQL

Kitabisa was also held back by its monolithic database system, which was prone to crashing under heavy demand. We started to solve the problem by moving from a stateful DigitalOcean database to a stateless Redis one, which freed us from relying on a single server, giving us better agility and scale.

But the strategy left a major pain point because it still required us to self-manage databases. In addition, we were experiencing high database egress costs due to the need to execute data transfers from a non-Google Cloud database into BigQuery.

In December 2021, we migrated our Amazon RDS to Cloud SQL for MySQL, and immediately saved 10% in egress costs per month. But one of the greatest benefits came when the Google Cloud team recommended using the open source proxy for MySQL to improve the scalability and stability of our data pipelines.

Cloud SQL’s compatibility allowed us to use connection pooling tools such as ProxySQL to better load balance our application. Historically, creating a direct connection to a monolithic database was a single point of failure that could end up in a crash. With Cloud SQL plus ProxySQL, we create layers in front of our database instances. It serves as a load balancer that allows us to connect simultaneously to multiple database instances, by creating a primary and a read replica instance. Now, whenever we have a read query, we redirect the query to our read replica instance instead of the primary instance.

This configuration has transformed the stability of our database environment because we can have multiple database instances running at the same time, with the load distributed across all instances. Since switching to Cloud SQL as our managed database, and using ProxySQL, we have experienced zero downtime on our fundraising platform even when a major crisis hits.

We are also saving costs. Rather than having a separate database for each different Kubernetes cluster, we’ve merged multiple database instances into one instance. We now group databases according to business units instead of per service, yielding database cost reductions of 30%.

Streamlining with Terraform deployment

There’s another key way in which Google Cloud managed services have allowed us to optimize our environment: using Terraform as an infrastructure-as-a-code tool to create new applications and upgrades to our platform.

We also managed to automate the deployment of Terraform code into Google Cloud with the help of Cloud Build, and no human intervention. That means our development team can focus on creative tasks, while Cloud Build deploys a continuous stream of new features to Kitabisa.

The combination of seamless scalability, resilient data pipelines, and creative freedom is enabling us to drive the future of our platform, expanding our mission to inspire people to create a kinder world in other Asian regions.

We believe that having Google Cloud as our infrastructure backbone will be a critical part of our future development, which will include adding exciting new insurtech features. Now firmly established on Google Cloud, we can go further in shaping the future of fundraising to overcome turbulent times.

How-to

Business Evolution with API Ecosystems

3451

Of your peers have already read this article.

1:30 Minutes

The most insightful time you'll spend today!

Apigee customers, like CHAMP Cargosystems, have pursued API-first ecosystem models to enter adjacent markets, create new customer interaction models, and rapidly grow their brand reach and partner ecosystems.

During uncertain times, ecosystem partnerships that leverage APIs have proven to help companies scale and address gaps in their businesses. Apigee customers, like CHAMP Cargosystems, have pursued API-first ecosystem models to enter adjacent markets, create new customer interaction models, and rapidly grow their brand reach and partner ecosystems. As a result of building their API ecosystem, they are transacting 300 million electronic exchanges and 20 million shipments per year.

CHAMP selected Apigee to provide an API platform and developer self-service portal option to all of its SaaS customers. Google Cloud’s Apigee API management platform and portal allows CHAMP and its customers to quickly connect to a variety of backend systems, including in-house, third party apps, marketplace portals and more– thereby accelerating their digitization strategies and opening up new markets through an API ecosystem.

Join this webcast and hear from this leading Enterprise company on how to:

  • Identify new revenue sources and markets using an API management platform
  • Improve time to market while still complying with all industry requirements
  • How to create a proof of concept to grow API adoption throughout your organization
  • Align internal business leaders and partners to see the importance of an API-first platform vision

3595

Of your peers have already watched this video.

24:00 Minutes

The most insightful time you'll spend today!

How-to

Build, Deploy, Modernize and Manage Apps Using Anthos

Anthos enables platform teams to defragment application delivery across hybrid and multi cloud. Learn how Anthos provides a consistent runtime and operational experience for a platform team to enable developers to move at an agile pace while minimizing operational overhead.

Case Study

How Barilla Created a Social Media Style App to Improve Efficiency

5635

Of your peers have already read this article.

3:30 Minutes

The most insightful time you'll spend today!

By consulting factory workers about their needs and aspirations, Barilla created with Google Cloud technologies a successful social-media style app to improve efficiency on the production line.

Google Cloud Results

  • Replaced conflicting, time-consuming paper logs with a near real-time, transparent app
  • Scaled rapidly and easily to accommodate new teams thanks to Google App Engine
  • Enables photographic and video communication to replace confusing text
  • New factory solution rolled out in just 15 days

In 1877, Pietro Barilla set up a small bakery to make pasta and baked goods for the people of Parma, Italy. Today, Barilla applies its 140 years of baking knowledge on a global scale, with six major manufacturing sites in Italy and an international network employing over 8,000 people. As the world’s leading producer of pasta, Barilla knows that when it comes to making quality food, great communication is key. That’s why the company plans to become a completely digital, looking to technology to improve the way it works.

Teams at the Barilla factory in Cremona work along a production line more than one-kilometer long, staffed by three shifts of workers a day. When one shift handed over to the next or requested machine maintenance teams, they used paper notebooks and unofficial instant messaging to communicate. That meant there was no authoritative, real-time record of events, communication was messy, oversight was poor, and teams had to hold daily morning meetings to synchronise notes.

Barilla worked with the Google Cloud Partner Injenia to create a solution, beginning with a consultative process on the factory floor.

“We had the idea to to start from the bottom and work up,” says Cristiano Boscato at Injenia. “Barilla’s top staff were brilliant about letting us do it. Eight of us from Injenia spent months on the factory lines with Barilla workers, collecting ideas on Google Docs, making presentations with Slides and collecting feedback with Forms. The CollaborAction app we created is the result of an amazing partnership.”

Co-designing a team social network

“Everything at the Cremona plant was managed offline, with paper,” explains Alessandra Ardrizzoia, Digital Engagement Senior Manager at Barilla. “Workers on the line would track events in notebooks, the shift leader would have another notebook, and the leader of the maintenance team would have yet another notebook. Everybody wrote their own text description of events, so there would be mismatches in the information going around.”

To resolve this, teams would meet at 8:30am every day to reconstruct a consistent narrative. In addition, machine maintenance workers were already using instant messaging to communicate with the line. Barilla and Injenia looked for a solution that could deliver a searchable, single version of events, with the ease of use of a mobile messaging application.

After consulting factory workers for ideas, Injenia created CollaborAction, a custom-built app that brought G Suite collaboration tools together on an Google App Engine platform, using Google Cloud SQL to index files. Google+Google Drive and Hangouts were not only highly available and easy-to-use, they also “helped with fast adoption, with interfaces that workers could already relate to.” Meanwhile Google App Engine enabled the Injenia team to deliver updates and new versions at speed, as part of a feedback process with workers who offered suggestions through a link to Forms embedded in the app.

Google+ provides an intuitive social media dashboard that workers felt comfortable with. Now teams use company tablets placed at intervals along the line to log in, report issues to other teams, photograph problems, schedule maintenance, give status updates through Hangouts chat, and have visibility on the whole process as it takes place.

“Everyone in the Cremona plant was really happy with the new social collaboration process. Because they were involved in designing the solution, they felt involved and really engaged with the process,” says Alessandra. “And now that everyone is aligned with CollaborAction, all the work in the plant is more effective. They are more agile and can use their time in more added-value activities.”

Optimization and a national roll-out

Created in Cremona, now CollaborAction connects over 1,000 users in six of Barilla’s factories in Italy. “The pilot at Cremona took one month, and adoption has been easier and faster in every plant we’ve taken it to,” says Cristiano. “We have another five or six plants more, and it takes no more than 15 days to introduce. That’s incredible.”

Because CollaborAction is a mobile app built on Google App Engine, scaling to meet new demand has been simple. Now maintenance teams use the app on smartphones, line workers use it on tablets, and shift leaders use it on laptops, so the entire team is aligned in close to real-time on a single version of events. And now teams communicate with video and photographs as well as text, there’s less room for confusion, as Alessandra explains. “It’s no problem understanding what’s happening in a video or picture, compared to a message that just says ‘something is going wrong.’ On a production line, where one part leads into the next, that speed makes a difference, and means we don’t have to throw as much food away when something breaks down.”

“Now we’re collecting feedback from all of the plants using CollaborAction and using it to create a standardised solution that we can apply across all of our plants,” says Alessandra. “We’re side-by-side with the workers in that sense, trying to address their needs with new features. It’s a way to make the workers feel like part of the solution, and that the app represents their needs and their voice.”

Solving a universal problem

By the end of 2018, Barilla and Injenia aim to have deployed CollaborAction to 2,700 employees at 18 factories worldwide. Barilla has already collected more than 50,000 posts with the app, including around 20,000 photographs and videos, and is now considering ways to apply Cloud Machine Learning Engine to create a maintenance chatbot or direct IoT connection with machinery.

“CollaborAction hasn’t just made our maintenance processes faster and more efficient, its also exponentially increased the knowledge and understanding employees have about their work,” says Alessandra. “It’s improving team spirit, too, such as when employees use CollaborAction to arrange to play soccer. It’s become the main communication tool for the entire plant.”

Blog

Secret Manager: Keeping Your Organization’s Secrets Safer!

3280

Of your peers have already read this article.

2:00 Minutes

The most insightful time you'll spend today!

Read the blog to get started with Secret Manager, every organization's must have toolkit that can easily manage, audit, and allow access to API keys and credentials across Google Cloud, Anthos, and on-premises.

Secret Manager is a Google Cloud service that provides a secure and convenient way to store API keys, passwords, certificates, and other sensitive data. It is the central place and single source of truth to manage, access, and audit secrets across Google Cloud. Since its launch, Secret Manager has helped secure millions of workloads and continues to provide industry-first features like replication policies and support for VPC perimeters. This blog post explores new Secret Manager capabilities and integrations that will help keep your secrets safer.

New tier, free of charge

No, you’re not dreaming – Secret Manager now has a tier that is free of charge! With this tier, each month per billing account you can have up to:

  • 6 secret versions
  • 3 rotation events
  • 10,000 API calls

This enables you to experience the value of Secret Manager with minimal financial risk and pairs nicely with existing services that offer a free tier like Cloud Run and Cloud Functions. For existing Secret Manager customers, this change will go into effect next billing cycle. Learn more about the Secret Manager free tier in the documentation.

Increased SLA

To meet the growing availability and reliability requirements of our customers, the Secret Manager SLA is now 99.95%! With this update, Secret Manager guarantees that all valid requests will succeed 99.95% of the time. This means you can depend on Secret Manager for even your most critical workloads. Additional details are available in the updated Secret Manager SLA.

Geo-expansion

In addition to the free tier and increased SLA, Secret Manager is now available in all public Google Cloud regions! With Secret Manager’s replication policies, you can choose the specific regions in which to replicate your secret, which means you can store secret payloads in geographical proximity to your workloads or users to reduce latency. This is also very useful if you have legal or regulatory requirements to store data in a particular locality. For more information, check out the list of Secret Manager locations in the documentation.

Compliance certifications

For customers wishing to use Secret Manager to store and process regulated data, Secret Manager is validated for compliance use cases including ISO 27001ISO 27017ISO 27018SOC 1SOC 2SOC 3PCI DSS, and HIPAA. Combined with the increased SLA and geographical availability, this makes Secret Manager suitable for use with regulated workloads.

Customer-Managed Encryption Keys (CMEK)

Secret Manager has always encrypted payloads in transit with TLS and at rest with AES-256. For customers that want additional control over the keys used to encrypt their secret payloads, Secret Manager now supports Customer-Managed Encryption Keys (CMEK). Secret Manager CMEK supports software-backed keys via Cloud KMS, hardware-backed keys via Cloud HSM, and even externally-managed keys via Cloud EKM. Learn how to enable CMEK support for Secret Manager in our tutorial.

Expiration and TTLs

While it was previously possible to expire access to a secret using IAM conditions, the underlying secret would continue to exist. Secret Manager now supports auto-expiring secrets which permanently deletes a secret at a specified timestamp or TTL. Since it is also possible to update a secret’s TTL, services can “lease” a secret and renew their lease on a periodic basis. If the service does not extend the lease by updating the TTL, the secret is automatically deleted.

Expiring secrets can be used in combination with IAM conditions to more safely expire secrets. For more information on expiring secrets and safety measures, see the guide on creating and managing expiring secrets.

Etags and server-side filtering

For customers that create or manage Secret Manager secrets via the API or an SDK, concurrency controls and performance are extremely important. This is why Secret Manager now supports Etags and server-side filtering! Etags help prevent concurrent modifications to the same secret by providing optimistic concurrency controls, while server-side filtering can dramatically reduce payload size and client-side computational overhead. Together, these enable stronger consistency guarantees and performance improvements to your applications. Learn more about Secret Manager Etags and Secret Manager server-side filtering in the documentation.

Code, build, run, deploy, monitor, and orchestrate

Secrets – like API keys, passwords, and certificates – are an integral part of most modern software applications. It is crucial that developers, operators, and security teams are empowered to build, operate, and observe software securely. That is why Secret Manager is now integrated with popular tools and technologies used throughout the application development lifecycle:

  • Code – Software engineers can create and access secrets directly from their preferred IDEs with Cloud Code. In VS Code, IntelliJ, or the Cloud Shell Editor, developers can browse secrets and insert code snippets for access secrets, all from the comfort of their local IDE.
  • Build – Release engineers can access secrets as part of CI builds using the Cloud Build Secret Manager integration. This could be used, for example, to authenticate to a Docker registry or communicate with the GitHub API. For customers that use other CI systems, there is also a GitHub Action for accessing Secret Manager secrets.
  • Run (on serverless) – Developers can mount secrets to be available as environment variables or via the filesystem through the native Cloud Run Secret Manager integration. Since the secrets are resolved in Cloud Run’s control plane, developers can use this integration to avoid a tight coupling between their applications and Secret Manager to enable hybrid cloud deployments or better local development experiences.
  • Run (on Kubernetes) – Developers can mount secrets from GKE, Anthos, or any Kubernetes cluster using the Secret Manager CSI driver. This vendor-agnostic driver exposes secrets via environment variables or the filesystem and enables hybrid cloud deployments using the same interface as other public cloud providers and HashiCorp Vault.
  • Deploy – To complement the existing Secret Manager Terraform integration, operators can now manage Secret Manager via Kubernetes Config Connector (KCC). KCC allows operators to manage Google Cloud resources through Kubernetes and the familiar Kubernetes APIs.
  • Monitor – With the Secret Manager Cloud Asset Inventory (CAIS) integration, security teams can understand secret usage across specific projects, folders, or the entire organization.
  • Orchestrate – Secret Manager Event Notifications enable DevOps and security teams to subscribe to Pub/Sub topics for when secrets or secret versions are changed. This enables customers to create deeply-integrated workflows, such as creating a ServiceNow ticket when a new secret version is added. Additionally, Secret Manager Rotation Scheduling enables DevOps teams to build automatic rotation flows like the ones described in the rotation guide.

Best practices

The Secret Manager best practices guide ensures customers get the maximum security benefits from Secret Manager. Security is non-binary, and this guide covers nuanced topics like access controls, coding practices, and secret administration. While not an exhaustive list, the Secret Manager best practices guide answers some of the most common questions and concerns around using Secret Manager in production deployments.

Towards seamless security

Secrets management is an important part of every organization’s security toolkit. With Secret Manager, you can easily manage, audit, and access secrets like API keys and credentials across Google Cloud, Anthos, and on-premises. These new features and integrations make it easy to adopt Secret Manager whether you are a hobbyist working on a side project or a large enterprise with thousands of employees.

To get started, check out the Secret Manager documentation.

Case Study

Bigbasket: Delivering Groceries Across 25 Cities in India

7303

Of your peers have already read this article.

1:30 Minutes

The most insightful time you'll spend today!

Bigbasket needed a mapping platform that could help it meet its delivery times and offer a familiar interface to customers. Google Maps Platform came to its rescue.

When Bigbasket was founded in December 2011, it guaranteed to deliver goods within a one-hour delivery slot of its customers’ choosing or it would refund them 10 percent of their orders. The company also introduced an express service, delivering groceries within 90 minutes of an order being placed.

Bigbasket needed a mapping platform that could help it meet its delivery times, and offer a familiar interface to customers. MediaAgility, a digital consulting company, recommended Google Maps Platform to Bigbasket.

When customers use the Bigbasket mobile app to place orders, they select their locations on a Google Map. The prices and availability of groceries varies according to location, so a customer’s location determines the cost of the order and what can be ordered.

Google Maps Platform Results

  • Bigbasket handles more than one million orders per month, and delivers in more than two dozen cities in India
  • Bigbasket now has more than four million customers
  • Orders are delivered on time, increasing customer loyalty

It is also used to determine driver routes. Bigbasket used the Maps Javascript API to build a web-based app for the company’s backend that tracks all orders and delivery progress. Dispatchers use the Directions API to match drivers with orders and customers, and the Distance Matrix API to get estimate the time of arrival for deliveries. As dispatchers track the progress of deliveries on the map, they can tweak routes as necessary.

“We’ve built Bigbasket from the ground up using Google Maps Platform. It makes sure we have the right customer locations and deliver to them on time. We couldn’t have started Bigbasket without Google Maps. It helps us to be fast and efficient, and make sure our customers get what they’ve ordered quickly,” said Pramod Jajoo, Chief Technology Officer, Bigbasket

More Relevant Stories for Your Company

Webinar

API Design Best Practices and Common Pitfalls

The job of an API is to make the application developer as successful as possible. When crafting APIs, the primary design principle should be to maximize application developer productivity and promote adoption. API designers and developers generally understand the importance of adhering to design principles while implementing an interface. No

Blog

Speeding Up Digital Transformation with Industry Solutions

Most large enterprises started with their own data centers and developed in-house solutions to meet their specific business needs, regulations, and industry specifications. These solutions were based on traditional applications from legacy vendors like Oracle and Microsoft — or even mainframes — and from key technology providers like SAP and

Case Study

APIs Help Cleveland Clinic Revamp their IT Infrastructure and Deliver High Quality Healthcare

Cleveland Clinic is one of the largest and most respected hospitals in the United States. Its mission is to provide better care of the sick, investigate their problems, and deliver further education of physicians. The clinic deployed electronic medical records (EMR) to help doctors deliver greater quality healthcare. But the

How-to

Transforming Media Industry: Three Strategies for Media Leaders to Leverage Generative AI

The digital era turned the traditional formula for media and entertainment success on its head, ushering in new technologies that have changed how content is produced, distributed, experienced, and monetized. Audiences have more choice, flexibility, and power over what they consume, and today’s media companies have to embrace ongoing transformation

SHOW MORE STORIES