Book Image

Hands-On Software Architecture with Golang

By : Jyotiswarup Raiturkar
Book Image

Hands-On Software Architecture with Golang

By: Jyotiswarup Raiturkar

Overview of this book

Building software requires careful planning and architectural considerations; Golang was developed with a fresh perspective on building next-generation applications on the cloud with distributed and concurrent computing concerns. Hands-On Software Architecture with Golang starts with a brief introduction to architectural elements, Go, and a case study to demonstrate architectural principles. You'll then move on to look at code-level aspects such as modularity, class design, and constructs specific to Golang and implementation of design patterns. As you make your way through the chapters, you'll explore the core objectives of architecture such as effectively managing complexity, scalability, and reliability of software systems. You'll also work through creating distributed systems and their communication before moving on to modeling and scaling of data. In the concluding chapters, you'll learn to deploy architectures and plan the migration of applications from other languages. By the end of this book, you will have gained insight into various design and architectural patterns, which will enable you to create robust, scalable architecture using Golang.
Table of Contents (14 chapters)

Datacenter-level reliability

What happens if the entire datacenter goes down? To be prepared for this eventuality, you need to run your application cluster in more than one datacenter, and ensure that both deployments are in sync in terms of data. Building such architectures is typically under the purview of business continuity planning (BCP) and disaster recovery (DR).

A common way to have DNS switch between deployments in two datacenters. A DNS name, such as www.mysite.com, resolves to a VIP of 4.4.4.4 with a specific time-to-live (TTL). This layer can be made intelligent and, in the case of a datacenter outage, repoint the DNS name to a backup VIP, say 5.5.5.5. For doing this we need the deployments to happen in both datacenters and that the data is replicated (usually asynchronously) between the deployments. This scheme is described in the following diagram:

The following...