AWS App Runner and Google Cloud Run are two serverless computing platforms that can help you deploy and run containerized applications without having to worry about servers. Both platforms are relatively new, but they have quickly become popular choices for developers.

What are the similarities?

Both platforms are serverless, meaning that you don’t have to provision or manage servers. The platforms will automatically scale your application up or down based on demand, so you only pay for the resources that you use. Both platforms support containerized applications. This means that you can package your application code and dependencies into a container and deploy it to the platform. Both platforms are easy to use. You can deploy your application with a few clicks or a few commands. Both platforms are scalable. They can automatically scale your application up or down based on demand, so you can handle even the most unpredictable traffic spikes.

Azure networking and GCP networking are both comprehensive cloud networking services that offer a wide range of features and capabilities. However, there are some key differences between the two platforms.

Azure networking offers a more traditional networking model, with a focus on virtual networks (VNets), subnets, and network security groups (NSGs). VNets are isolated networks that can be used to group together resources, such as virtual machines (VMs), storage, and applications. Subnets are smaller subdivisions of a VNet, and they can be used to further isolate resources. NSGs are used to control traffic flow within and between VNets.

There are a few ways to monitor costs in Azure. One way is to use the Azure Cost Management + Billing portal. This portal provides a graphical interface that you can use to view your costs over time, track your spending against budgets, and identify areas where you can save money.

Another way to monitor costs is to use the Azure Cost Management API. This API allows you to programmatically access your cost data and integrate it with other systems. You can use the API to create custom reports, automate cost management tasks, and integrate cost data with your budgeting and forecasting processes.

Here is a Terraform file that you can use to create a Kubernetes cluster in Azure:

provider "azurerm" {
  version = "~> 3.70.0"
  subscription_id = var.azure_subscription_id
  client_id = var.azure_client_id
  client_secret = var.azure_client_secret
  tenant_id = var.azure_tenant_id
}

resource "azurerm_resource_group" "aks_cluster" {
  name = var.resource_group_name
  location = var.location
}

resource "azurerm_kubernetes_cluster" "aks_cluster" {
  name = var.aks_cluster_name
  location = azurerm_resource_group.aks_cluster.location
  resource_group_name = azurerm_resource_group.aks_cluster.name
  node_count = 3
  vm_size = "Standard_D2s_v3"
  network_profile {
    kubernetes_network_interface_id = azurerm_network_interface.aks_cluster_nic.id
  }
  default_node_pool {
    name = "default"
    node_count = 3
    vm_size = "Standard_D2s_v3"
  }
}

resource "azurerm_network_interface" "aks_cluster_nic" {
  name = var.aks_cluster_nic_name
  location = var.location
  resource_group_name = azurerm_resource_group.aks_cluster.name

  ip_configuration {
    name = "primary"
    subnet_id = azurerm_subnet.aks_cluster_subnet.id
    address_prefix = "10.0.0.0/24"
  }
}

resource "azurerm_subnet" "aks_cluster_subnet" {
  name = var.aks_cluster_subnet_name
  resource_group_name = azurerm_resource_group.aks_cluster.name
  virtual_network_name = var.virtual_network_name
  address_prefix = "10.0.0.0/24"
}

resource "azurerm_virtual_network" "aks_cluster_vnet" {
  name = var.virtual_network_name
  location = var.location
  resource_group_name = azurerm_resource_group.aks_cluster.name

  address_space = ["10.0.0.0/16"]
}

This Terraform file will create a new Azure resource group, a Kubernetes cluster, a virtual network, and a subnet. The Kubernetes cluster will have three nodes, each of which will be a Standard_D2s_v3 VM. The virtual network and subnet will be created in the same region and resource group as the Kubernetes cluster.

Here are some tips on how to create an effective SRE culture:

• Start with the right mindset. SRE is a mindset that sees reliability as everyone’s responsibility, not just the responsibility of the SRE team. It is important to create a culture where everyone is empowered to take ownership of reliability and to make decisions that will improve the reliability of the systems they work on.
• Embrace failure. Failure is inevitable, so it is important to create a culture where failure is seen as an opportunity to learn and improve. The SRE team should be empowered to experiment and to take risks, knowing that they will not be punished for failure.
• Promote collaboration. SRE is a team sport, so it is important to create a culture where collaboration is encouraged. The SRE team should work closely with other teams, such as development, operations, and security, to ensure that the systems are reliable.
• Automate everything. Automation is essential for SRE. By automating tasks, the SRE team can free up time to focus on more strategic work. It is also important to automate the collection of data so that the SRE team can have a clear understanding of the health of the systems.
• Measure everything. SRE is data-driven, so it is important to measure everything. The SRE team should collect data on the performance of the systems, the number of incidents, and the time it takes to resolve incidents. This data can be used to identify areas where improvements can be made.
• Celebrate successes. It is important to celebrate successes, both big and small. This will help to keep the SRE team motivated and to create a positive culture.

By following these tips, you can create an effective SRE culture that will help to improve the reliability of your systems.

This one is better explained with the presentation below. If you want to learn how to run quantitative analytics at scale, it’s well worth a watch.

Built and maintained a client and market side booking service, off order book trade reporting engine and trade manager/repository

Like most banks, this one suffered from the not invented here syndrome. They had decided to pretty much reimplement the core libraries to optimize for Zero Garbage Collection, low latency and high throughput. Unfortunately they were not optimized for large development teams and maintainability.

I helped the team debug issues and introduce new functionality using a tech stack that consisted of Java, Groovy, Spring, FIX, JUnit, MSSQL and JRebel.

Developed an eTrading platform routing client FIX flow to the firm’s Algorithmic Trading platform.

Used profiling/debugging tools to resolve critical issues around lost trade messages.

Java, YourKit, Swing, Spring, Tibco EMS, FIX

Design and development of a real time matching engine to provide insights into liquidity for funding forecasts and regulatory requirements.

Java, BDD/TDD, JUnit/TestNG, Maven, Coherence, Spring Core, Spring Data, Spring Boot Micro Services, IBM MQ, Maven, Jira, TeamCity