Book Image

Distributed Computing with Go

By : V.N. Nikhil Anurag
Book Image

Distributed Computing with Go

By: V.N. Nikhil Anurag

Overview of this book

Distributed Computing with Go gives developers with a good idea how basic Go development works the tools to fulfill the true potential of Golang development in a world of concurrent web and cloud applications. Nikhil starts out by setting up a professional Go development environment. Then you’ll learn the basic concepts and practices of Golang concurrent and parallel development. You’ll find out in the new few chapters how to balance resources and data with REST and standard web approaches while keeping concurrency in mind. Most Go applications these days will run in a data center or on the cloud, which is a condition upon which the next chapter depends. There, you’ll expand your skills considerably by writing a distributed document indexing system during the next two chapters. This system has to balance a large corpus of documents with considerable analytical demands. Another use case is the way in which a web application written in Go can be consciously redesigned to take distributed features into account. The chapter is rather interesting for Go developers who have to migrate existing Go applications to computationally and memory-intensive environments. The final chapter relates to the rather onerous task of testing parallel and distributed applications, something that is not usually taught in standard computer science curricula.
Table of Contents (11 chapters)

Monolith versus microservices

Most of the new projects start out as a single codebase where all the components interact with one another via direct function calls. However, as the user traffic and codebase increases, we will start facing issues with the codebase. Here are a few possible reasons for this:

  • Your codebase is growing in size and this means that it will take longer for any new developer to understand the complete system.
  • Adding a new feature will take longer because we have to make sure that the change doesn't break any of the other components.
  • Redeploying code for every new feature might become cumbersome because of the following:
    • Deployment failed and/or
    • One of the redeployed components had an unexpected bug which crashed the program and/or
    • The build process may take longer because of a large number of tests
  • Scaling the complete application to support a CPU...