Mailjet allows companies to create, send, and track millions of emails to their customers and prospects around the world each month. The company’s offerings range from routing these emails to tailor-made tools that allow clients to design and send marketing campaigns with messages related to sales, user clubs, coupons and discounts, and promotions, as well as transactional emails such as purchase confirmations, shipping confirmations, e-tickets, or password resets.

“All of our services are accessible through programming interfaces. We use the same APIs for ourselves and for our customers. This is part of our unique selling point, which is to make life easier for developers and marketers,” explains François Fanuel, IT Operations Manager at Mailjet.

The company scrupulously monitors its service quality to help ensure that emails sent on behalf of its customers don’t trigger spam filters, and that they obtain the best possible open and click rates.

From hosting to the cloud

In its early years, Mailjet used hosted servers. This model had several disadvantages. It was impossible to instantly activate or deactivate computing power; the company could not be charged for actual, to-the-minute usage; and it lacked the flexibility to add disk space or scale servers in real time.

At the beginning of 2016, Mailjet decided to switch to the public cloud in order to improve technical and economic flexibility. “This two-year evolution required us to review our developments. If we use a virtual machine even for just one hour, our computer code must be able to support it in order to preserve the consistency and integrity of the data and processes,” says Fanuel.

“We needed a way to port our IP addresses to Google Compute Engine. In less than a month, the feature had been developed by Google engineers. This reactivity really impressed us and was definitely a deciding factor.”

—François Fanuel, IT Operations Manager, Mailjet

Mailjet and Google were already partners. The marketing and transactional email specialist is one of only three providers in the world, and the only one in Europe, accredited by Google to send bulk emails through Google Cloud Platform. The choice—based on three main factors—was obvious.

Financial and technical considerations

Factor 1: the right price proportionality. “We are able to activate Google Compute Engine virtual machines on demand, without needing to reserve these instances. While the machine remains active, a sliding-scale price is applied, which is particularly attractive to us,” explains Fanuel.

Factor 2: the quality and level of technical communication. Mailjet has direct access to Google Cloud Platform engineers when required. The company has its own IP addressing infrastructure, which is the foundation of its service quality. “We needed a way to port our IP addresses to Google Compute Engine. In less than a month, the feature had been developed by Google engineers. This reactivity really impressed us and was definitely a deciding factor.” Since then, via specific tunnels, Mailjet IP addresses have been ported directly into Google Compute Engine.

Factor 3: conformity to international data regulations. Mailjet is the only email service provider to be ISO 27001 certified and GDPR-ready, enabling the company to offer its clients the highest level of data security and privacy. Google Cloud Platform is also ISO 27001 certified, which was an important factor for Mailjet.

Power through minimalism

In mid-2016, Mailjet replaced its 30 or so email sending servers installed at a hosting company with smaller Google Compute Engine virtual machines, using the automatic load-balancing function. “Using smaller virtual machines—but more of them—optimized our computing power.” This precision mechanism accompanied an increase in activity for the company, with the number of emails sent doubling every year. As for the company’s some 300 TB of data, this is stored in Google Cloud Storage.

The flexibility and power of Google Cloud Platform helps ensure that Mailjet can adapt to peaks in activity that can reach up to 20 times the normal flow—our customers usually send their messages at the same times and during the same peak periods. “Previously, we had to reserve a lot of computing power with our hosting company, equivalent to 150 servers. Moving to an on-demand infrastructure means we can avoid paying a disproportionate fixed annual cost.”

Google Cloud Platform also provides Mailjet with the infrastructure needed to process events centrally, which facilitates technical support. A new analytics dashboard in the making will provide customers access to their campaigns’ key metrics in real time—a circulation report, open rates, and click-through rates, as well as invalid email addresses— regardless of the volume of emails at stake.

From distribution to development

Following routing operations, the development environment is currently being ported to Google Cloud Platform, and will eventually represent 100 virtual servers. “The addition of any new code is iteratively tested in Google Cloud Platform. We benefit from machines that are custom made for our needs, from machines with one core and 3 gigabytes of memory, up to machines with 64 cores.”

Mailjet uses the Google Cloud Interconnect virtual private network to tailor sending flows by geographical location. “For customers who only use our routing service, we will soon have worldwide load balancers. This will help ensure their API requests are received and their emails are sent to Europe and America from one single IP point, thus avoiding transatlantic latency issues.”

Mailjet also uses the Google Identity Aware Proxy authentication tool. All its employees around the world benefit from unique, more secure access, whether they use Google Sites intranets, or the development, or production environment. “Google Cloud Platform delivers on all the promises of a public cloud: service customization, real-time computing power adjustment during periods of high and low demand, and instant activation of computing resources. For us, it’s the best possible ratio between price, performance, availability, and quality,” concludes Fanuel.

The home lending journey entails processing an immense number of documents daily from hundreds of thousands of borrowers. Currently, home lending document processing relies on some outdated digital models and a high dependency on manual labor, resulting in slow processing times and higher origination costs. Scaling a business that sorts through millions of documents daily, while increasing efficacy and accuracy, is no small feat. When it comes to applying for a mortgage loan, consumers expect a digital experience that’s as good as the in-person one. Roostify simplifies the home lending journey for lenders and their customers.

No time to spare: Overcoming document processing challenges with AI

Roostify provides enterprise cloud applications for mortgage and home lenders. In order to empower its customers to deliver a better, more personalized lending experience, they needed to automate and scale their in-house document parsing functionality.

As a key component of its document intelligence service, Roostify is leveraging Google Cloud’s Lending DocAI machine learning platform to automate processing documents required during a home loan application process, such as tax returns or bank statements with multi-language support. This partnership delivers data capture at scale, enabling Roostify customers to automatically identify document types from the uploaded file and to extract relevant entities such as wages, tax liabilities, names, and ID numbers for further processing, and make things move faster in the cumbersome lending process. 

Roostify’s solutions leverage Google Cloud’s Lending DocAI, which is built on the recently announced Document AI platform, a unified console for document processing. Customers can easily create and customize all the specialized parsers (e.g., mortgage lending documents and tax returns parsers) on the platform without the need to perform additional data mapping or training. All Google Cloud’s specialized parsers are fine-tuned to achieve industry-leading accuracy, helping customers and partners confidently unlock insights from documents with machine learning. Learn more about the solution from the GA launch blog and the overview video.

Integrating Lending DocAI’s intelligent document processing capabilities into the Roostify platform means more innovation for their customers and tangible results: faster loan processing times, fewer document intake errors, and lower origination costs. Additional support in Google Lending DAI for other languages and more documents like global Know Your Customer (KYC) documents or payroll reports is in the near future.

Full integration of AI solutions

Working together with Roostify’s platform team, we were able to help them solve their document processing challenge through integration of various GCP products such as Lending DocAI (LDAI), Data Loss Prevention (DLP) for redacting sensitive data, BigQuery for data warehousing and analytics, and Firestore for API status. To make it very safe and secure, all data was encrypted end-to-end at Rest and in Transit. LDAI won’t require any training data to process. It is an easy plug and play API.

Here is a sneak peek in the high level deployment architecture for LDAI in Roostify environment:

Here are the steps for processing data:

1. Receives document processing request from the client.
2. API Function directs requests to the pre-processing service. For Async requests a processing ID is generated and returned to the caller.
3. Pre-processing service sends the request for further processing (Long/short PDF conversion), calling other microservices and receives back the responses. Any error in the response received is then sent to the response processing service. 
4. If the response is synchronous, the pre-processing service directs it to the LDAI Invoker service. 
   1. If the response is asynchronous, the pre-processing service feeds it into the Cloud Pub/Sub service.
5. Cloud Pub/Sub service feeds the response back to the LDAI Invoker service.
6. LDAI Invoker service routes the request to the Google LDAI API for classification if there are multiple pages in the document.
7. Document will be split based on LDAI response and then saved in a GCS bucket for temporary storage.
8. LDAI entity interface for single page processing and then LDAI Invoker sends LDAI results to LDAI Response Processing
9. If a request is a synchronous request the LDAI Response Processor sends results to the API Function so that it can complete the synchronous call and respond to the rConnect caller.
   1. If the request is an asynchronous request the LDAI Response Processor will respond to the caller’s webhook and complete the transaction.
10. Finally, Data stored in the GCP bucket will be deleted.

All the responses that come from the LDAI API can optionally feed into BigQuery via the Response Processor, after parsing it through Data Loss Prevention (DLP) API to redact the PII/sensitive information.  Throughout the processing of both asynchronous and synchronous requests all transactions are logged using Cloud Logging.  For asynchronous transactions, the state is maintained throughout the process using Cloud Firestore.

Roostify currently uses this technology to power two different solutions: Roostify Document Intelligence and Roostify Beyond™. Roostify Document Intelligence is a real-time document capture, classification, and data extraction solution built for home lenders. It ingests documents uploaded by borrowers and loan officers, identifies the relevant documents, and extracts and classifies key information. Roostify Document Intelligence is available as a standalone API service to any home lender with any digital lending infrastructure already in place. 

Roostify Beyond™ is a robust suite of AI-powered solutions that enables home lenders to create intelligent experiences from start to close. It combines powerful data, insightful analytics, and meaningful visualization to streamline the underwriting process. Roostify Beyond™ is currently available only to Roostify customers as part of an Early Adopter program and will be rolled out to the market later this year.

Through this partnership, Roostify has enabled its customers to adopt a data-first approach to their home lending processes, which will lead to improved user experiences and significantly reduced loan processing times.

Fast track end-to-end deployment with Google Cloud AI Services (AIS)

Google AIS (Professional Services Organization), in collaboration with our partner Quantiphi, helped Roostify deploy this system into production and fast-tracked the development multifold to generate the final business value.

The partnership between Google Cloud and Roostify is just one of the latest examples of how we’re providing AI-powered solutions to solve business problems.

With the rise of digital assistants and conversational interfaces, people have grown accustomed to hearing and speaking to synthetic voices. But what do those voices sound like? Often, pretty repetitive. We’re all familiar with the Google Assistant voice, for example.

That’s why we are excited to announce the general availability of Custom Voice in our Cloud Text-to-Speech (TTS) API, a new feature that lets you train custom voice models with your own audio recordings to create unique experiences.

For businesses looking to build a strong brand identity, establishing a unique voice can help turn mobile app interactions or customer service based on interactive voice responses (IVR) into differentiated customer experiences. Our TTS API has included a speech synthesis service with a static list of voices for some time, but now, with Custom Voice, moving beyond these predefined options is easier than ever.

Custom Voice lets you simply submit your audio recordings to get access to the new voice directly in the TTS API. Custom Voice TTS includes guidance on the audio requirements to help make sure you generate a high quality custom TTS voice model. Once this new model is trained, all you have to do to start using the newly trained voice is reference the model ID in your calls to the Cloud TTS API.

At Google, we are committed to building safe and accountable AI products, not only because it’s the right thing to do, but because it is a critical step in ensuring successful use in production. As part of Google Cloud’s Responsible AI governance process, we conducted a deep ethical evaluation of Custom Voice TTS, and its relation to synthetic media, in order to surface and mitigate potential harms that it may create. If you are interested in Custom Voice TTS, there is a review process to help ensure each use case is aligned with our AI Principles and adequate voice actor consent is given.

Additionally, to verify that voice actors are actually the ones producing the audio, you will need to submit an audio file producing a sentence that Google Cloud chooses (for example: “I agree that my voice will be used to create a synthetic custom Text-to-Speech voice).

We’re looking forward to seeing this API help businesses solve problems in an easy, fast, and scalable way. TTS Custom Voice is now GA in these languages:

English (US)

English (AU)

English (UK)

Spanish (US)

Spanish (Spain)

French (France)

French (Canada)

Italian (Italy)

German (Germany)

Portugues (Brazil)

Japanese (Japan)

We plan to continue expanding this lineup in order to meet your needs. Ready to try for yourself? Contact your seller to get started on your use case evaluation today!

When a software change is deployed — after being designed, coded, tested, packaged, and tested some more — a journey comes to an end. At the same time, a new journey begins: your customer’s relationship with your service. It’s here, in the domain of operations, that abstract risks like launch schedule slippage give way to tangible risks like lost revenue, degraded trust, and tarnished reputation. Only when it’s available to users can software contribute to (or threaten!) the success of your organization. And so, throughout the past several years, the DevOps Research and Assessment (DORA) project has incrementally deepened our research into the reliability of services, through and beyond deployment, into ongoing operation.

Reliability is a broadly defined term, which refers to a team’s ability to meet their users’ expectations — for software services, it may encompass aspects of availability, latency, correctness, or other characteristics that influence the consistency and quality of user experience. Google’s practice of Site Reliability Engineering (SRE), which has been embraced and extended by a global community of reliability engineering practitioners, is an approach to operations that prioritizes user-oriented measurement, shared responsibility, and collaborative, blameless learning. Starting with the 2021 Accelerate State of DevOps Report, we began asking survey respondents detailed questions about reliability engineering in their organizations. We continued and expanded our investigation in 2022, and found further evidence that modern reliability engineering is widespread: a majority of respondents report that they employ SRE-style practices. With this extensive body of data to draw from, this year we pushed further into analyses of the impact of reliability and its interaction with other dynamics present in our model of technology’s influence on organizational success.

Reliability matters

When reliability is poor, improvements to software delivery have no effect — or even a negative effect — on organizational outcomes

Reliability is more than beneficial: it’s essential. As in prior studies, we find that software delivery performance (as measured by the “four key metrics” of change lead time, deploy frequency, change failure rate, and failure recovery time) is predictive of organizational performance. However, this year’s analysis revealed a previously unseen nuance: the influence of software delivery on organizational performance is predicated on reliability. When reliability is high, high-performance software delivery predicts better outcomes for the organization. But when reliability is poor, improvements to software delivery have no effect — or even a negative effect — on organizational outcomes. This affirms a long-held belief among reliability engineers: “reliability is the most important feature of any system.” If a service or product doesn’t meet its users’ reliability expectations, it’s counter-productive to rapidly ship flashy new features, because users can’t properly experience them. Software delivery relies on a foundation of reliability to create value.

https://storage.googleapis.com/gweb-cloudblog-publish/images/dora.max-900×900.jpg

Reliability is a journey

Any experienced leader will tell you that progress is rarely linear: even with a discipline like SRE, widely practiced and with demonstrable benefits, the path to success is unlikely to follow a straight line. DORA describes the “J-Curve” of organizational transformation, a phenomenon in which durable success comes only after setbacks and lessons learned. This year, we compared the depth of teams’ reliability engineering practices to their impact on the services they provide: will an investment in SRE produce greater reliability? The answer is yes, but with a significant caveat: not at first. Comparing reliability outcomes across a range of levels of SRE adoption, the J-Curve is plainly visible. A team which practices SRE only lightly — at the beginning of their SRE journey, perhaps — is likely not only to not benefit, but to regress in terms of the reliability experienced by their users. However, after these practices have more deeply permeated, an inflection point is reached and we see strong reliability benefits from continuing to grow the reliability engineering capability.

Knowing that it will likely take time to realize the benefits of adopting SRE, it may be tempting to start the process as soon, and as broadly, as possible. But we offer a note of caution here: organization-wide cultural transformation initiatives typically fail from overreach. We studied this and reported findings in a previous report. And even if you manage to beat the odds and fully adopt SRE across multiple teams simultaneously, the cost may be unacceptable: the setbacks in reliability that you are likely to experience early on, amplified across an entire organization all at once, could have catastrophic consequences. Therefore the SRE principle of gradual change should also be applied to the adoption of SRE itself.

Reliability is about people

Reflecting back on over a decade of SRE practice and theory, the Enterprise Roadmap to SRE underlines the importance of culture, suggesting that Site Reliability Engineering is in fact emergent from culture. Tools and frameworks are important; language is essential. But only a trustful, psychologically safe culture can support the environment of continuous learning which enables SRE to manage today’s complex, dynamic technology environments. DORA’s research in 2022 demonstrates the interplay between culture and reliability: we found that “generative” culture, as defined by the Westrum model, is predictive of higher reliability outcomes. And reliability has benefits not only for a system’s users, but for its makers as well: teams whose services are highly reliable are 1.6 times less likely to suffer from burnout.

Got a story to share about your DevOps journey? Submit it to Google Cloud’s 2022 DevOps Awards by January 31, 2023!