Introduction​

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.

In-depth knowledge of Terraform and Multy is not needed to follow this tutorial. If you want to learn more about these tools, check out the Multy documentation and the Terraform documentation.

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.

Financial regulators are becoming increasingly worried of the implications the increased adoption of cloud can have as more and more financial services companies are gradually becoming more reliant on Cloud Service Providers (“CSP”). With the dominance of the space by Amazon, Microsoft and Google, the failure of any one of them could prove a single point of failure for a big portion of the financial system. Consequently, regulators have proposed regulation that aims to lower the systemic risk this dependance introduces into the system. This involves everything from doing proper due diligence and risk assessments of the CSPs to having architectures and plans in place that reduce operational risk and increase resilience.

Multi-cloud strategy – the use of multiple private or public clouds – is increasingly becoming the main method companies use to deploy their IT infrastructure. For example, Walmart adopted a multi-cloud setup to reduce cloud costs by 18% and increase deployment speed by 1,700x. In the next three years, an estimated 64% of companies will rely on multi-cloud as their main deployment model. 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. So, what makes multi-cloud so attractive?

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.

There are many computing resources available across all clouds which usually fall into one of these categories:

• Containers (managed container services, kubernetes)
• Instances (virtual machines, spot instances)
• Serverless

In this article, we're specifically focusing on Virtual Machine instances. If you are interested in other resources, join our mailing list as we will be comparing other resources later on.

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.

In this post, we'll go over an overview of what is IaC, why you should consider using it and a brief introduction to how some of these tools work under the hood.

Overview​

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.

However, most infrastructures get to a point where manual deployments and resource definition start actually slowing you down. Manual deployments, having to create copies for each environment or having dozens of developers deploying changes to code/infrastructure - these are all things that can lead to mistakes, downtime or even loss of data.

In this blog post, we'll take a look at the current IaC landscape, current tools and how they compare against each other.

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.

In this blog post, we'll go over the potential consequences of running on a single cloud, the current options companies have when deploying cloud infrastructure and the common pitfalls.

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. It's the core communication framework that powers everything from the 8.5 billion Google searches per day the internal communication layer between each teams' microservices.

In this blog post, we'll go deeper into what gRPC actually is and what its advantages are over REST.