In this tutorial, we'll deploy a simple web app to the cloud of your choice - composed of a database and a virtual machine where the frontend code will run. So that the configuration is reusable and consistent, we'll write it in Terraform. Usually Terraform configurations are cloud-specific, and changing clouds requires a complete rewrite. In this case, so that you can reuse the same configuration across clouds, we'll be using Multy.

Cloud has become the de facto way to build infrastructure, meaning cloud providers end up in charge of a significant amount of the apps we use every day. From the likes of Netflix, Slack, Ring and Doordash running on AWS or PayPal, Twitter and HSBC on GCP, it's easy to see how impactful a failure of any type can be. Let's look at some of the issues that have happened recently that have led business to consider how dependent they are on a single provider.

Cloud computing can bring many benefits to financial services companies such as increased speed and agility, easier innovation and scalability. It is no wonder then that cloud adoption is set to continue increasing with 54% of financial services companies expected to have more than half of their entire IT footprint in public clouds in the next five years. However, despite the benefits that this can bring for financial services, it also brings a new set of challenges for financial market stability.

Multi-cloud strategy – the use of multiple private or public clouds – is increasingly becoming the main method companies use to deploy their IT infrastructure. In the next three years, an estimate 64% of companies will rely on multi-cloud as their main deployment model source. Despite the complexities that come from operationalizing it, as we disccussed in The Challenges of Building Multi Cloud, the multiple benefits that come from this deployment model can often make it worth the effort.

In this blog post series, we will be comparing different services in AWS, GCP and Azure. We'll go into detail in each of the resources and understand the differences between providers, something you need to be aware if you are looking into switching clouds. Some examples will be given using Terraform, the Infrastructure as Code (IaC) market leader. If you want to know more about different IaC tools and how they compare, check our other blog post - Terraform vs Pulumi vs CloudFormation.

Cloud infrastructure has been on the rise for the last decade. As it's adoption grows, so has the complexity of managing infrastructure, becoming more complex and more prone to user mistakes. This led to a new wave of tools in the Infrastructure as Code (IaC) space that aim to tackle this issue by treating your infrastructure as you would any other piece of software.

When getting started, using an Infrastructure as Code (Iac) tool might seem overkill, and something that will slow down development. Building and deploying manually is often the way to go early stage - infrastructure changes constantly and having to re-write your configuration can be a pointless exercise until you have a better understanding of the fundamental pieces of your infrastructure.

Multi cloud has long been a contentious topic when you talk about cloud infrastructure. Infrastructure as code tools such as Terraform and Pulumi have made deploying to any cloud much easier - you can now use a single interface to deploy infrastructure to virtually any cloud environment. However, the effort of creating infrastructure for each cloud provider still requires significant expertise and time to get right, leading many to see it as a effort not worth taking.

Nowadays, REST is ubiquitous across most kinds of applications. It provides an easy, simple and clear language to communicate between services, usually a frontend and a backend. Although, there are many good alternatives and I want to talk about one in particular - gRPC. From my days as a Software Engineer at Google, I have grown quite fond of gRPC. Google uses it everywhere, from communicating between frontend and backend, to communicating with database servers to all kinds of microservices.