In this post, I will share my experience of working as a consulting solutions architect and a mentor on Go programming language and distributed systems architectures, in India, and I will also share some of my recommendations based on my experience, when you adopt Go in your organisations.

I am an early adopter of Go, and authored two books on it, in 2015 and in 2016. Before Go, I worked extensively on Microsoft .net stack for more than a decade, and since 2008, I have been working as an Architect. When I left from .net technologies and moved to Go, I was a Microsoft MVP and an Azure insider. Since 2015, I have been working as a consulting solutions architect and a trainer to mentor companies to adopt Go in their organisations and to projects and products. During this period, I have mentored more than 50 companies, which includes start-up companies on product engineering, mid-sized companies and larger organisations. While I work with these companies, I went through different emotions — pleasant, unpleasant, and neither unpleasant nor pleasant. …


I have been working as a consultant and trainer on Go programming language and distributed systems architectures, in India, and guided a lot of software development teams to adopt Go for building their systems. I have worked with product engineering start-ups, mid-size organisations and larger enterprises. Except working with some larger enterprises (not with everyone, but majority of times), the adoption path to Go has been very pleasant experience. When I mentor fresher software engineers, they quickly adopt the Go language and then working on product engineering, like experienced engineers do. Because Go is a very simple and minimalist language, the adoption path to Go is very easy, which is really helpful for product engineering start-up companies. …


A lot of younger software engineers have been approaching me for taking my advice to become good software developers. My recommendations are very simple: The problems with many of the younger generations of software engineers are that they emphasize more into learning programming languages and frameworks, and excited to learning new technologies, but not focusing on basic programming fundamentals for writing good, maintainable code. Learning a new language doesn’t make you a great programmer.

Programming languages are just providing a mechanism to write code by using its grammar and semantics. Even by using a good programming language, you can write very bad code if you don’t have knowledge. I’ve seen that people use modern programming languages and finally writing bad code with it. So a language doesn’t make you a better programmer, but it does make sense when you incorporate good software engineering principles with your choice of programming language. I highly recommend starting with learning SOLID principles to become a good developer. You can start applying SOLID principles from functions to class level, then move to module/package level, component level, and finally at architecture level to design highly cohesive components for building distributed systems at scale. SOLID principles are basics for building great software systems based on clean architecture. When you start to write code by using good software engineering principles, you will become great developers regardless of which programming language you’re using. Once you’re good on core fundamentals, then explore various programming paradigms such as functional programming, concurrent programming, etc. Once you become a good developer, then you can learn anything independently. When you learn a new programming language or something else, you may feel that this language/technology is an an evolution of something which you have learned in the past. But if you don’t have basics, and then learning a new programming language, you may simply learn some syntax of that language, which will never transform you as a good developer. …


In this post, I will give an introduction to Go kit, a toolkit for building microservices in Go. This post is an introductory post on Go kit as part of a series of blog posts on it, and the source code of examples are available from here: https://github.com/shijuvar/gokit-examples

Go has gradually been becoming a language of choice for building modern distributed systems. When you build cloud-native distributed systems, you may need specialized support for various capabilities such as support for different transports and message encoding formats, RPC safety, logging, tracing, metrics and instrumentation, circuit breaking, rate limiting, infrastructure integration and even guidance on architecture. Go is very popular for its simplicity and “no magic” approach, thus a collection of Go packages like standard library packages, for distributed programming would be more appropriate than using a full-fledged framework with lot of magic and opinions on underlying technologies. Personally I don’t like to use full-fledged frameworks that come with lot of opinions, but I do prefer libraries that come with less opinions and more freedom to developers. …


In this post, I will demonstrate a simple Event Sourcing/CQRS Example in Go to demonstrate how to solve the practical challenges of Microservices based distributed systems. Keep in mind that my objective of this post is not about introducing best practices for Event Sourcing and CQRS, but introduce these two architectural patterns by writing a simple example in Go, which provides a solution for the challenges in Microservices based distributed systems in order to dealing with transactions and data.

The Hardest Part of Microservices: Data and Transactions

People who have never worked on distributed systems, have been misinterpreting that Microservices are just about running services in Docker containers and orchestrating it with Kubernetes. In my country, India, a lot of people have been providing corporate training and guidance on Microservices with two misinterpretations: Microservices are just about orchestrating containers with Kubernetes, or just about using Spring Boot framework with Netflix OSS. But in practice, Microservices, is a distributed systems architecture pattern that is all about functional decomposition for building highly scalable and evolvable software systems. …


In this post, we’ll take a look into how to write gRPC Interceptors in Go. When you write HTTP applications, you can wrap route specific application handlers with HTTP middleware that let you execute some common logic before and after executing application handlers. We typically use middleware to write cross-cutting components such as authorization, logging, caching, etc. The same kind of functionality can be implemented in gRPC by using a concept called Interceptors.

gRPC Interceptors

By using Interceptors, you can intercept the execution of RPC methods on both the client and the server. …


Here’re some technology predictions for 2018 based on my technology focus and interesting areas:

  • Kubernetes, the open source container orchestration engine, will be the technology of 2018 in all aspects. Kubernetes, one of the most successful projects in the history of open-source ecosystem, will be the “new Linux” in cloud computing platforms. Kubernetes will be a key technology in 2018 to run massively scalable cloud-native applications. When Kubernetes is adopting in larger enterprises, some organizations may look for customizing it, thus developers with expertise on both Kubernetes and Go language, will be very demanding in such enterprises.
  • Go programming language will be most popular choice of language in modern enterprises. (When I say modern enterprise, I refer organizations like Uber, Netflix, Square, SoundCloud, etc, but not conventional corporates). The Scala language will never have been a darling of modern enterprises. …


A while ago, I have written a blog post Introducing NATS to Go Developers for using Apcera NATS as the messaging system for building distributed systems and Microservices in Go. In this post, I will take a look into NATS Streaming server, which built on the top of basic NATS server that provides a persistent log for your messages which you publish on the NATS.

NATS is an open source, lightweight, high-performance cloud native messaging system. I love to use NATS for building distributed systems in Go because for its performance and simplicity. Because building distributed systems always bring lot of complexities, using a simple and high performant messaging system is an important and vital decision. …


For the last three years, I have been working as a consultant and trainer on Golang and cloud-native distributed systems architectures including Microservices. In my consulting experience on Microservices, I have had lot of strange experiences from various clients due to the misinterpretations of Microservices. I work in India, at least here, Microservices is the most misinterpreted terminology in IT industry at this moment. Everyone is talking about Microservices. Lot of people are saying that their applications are based on Microservices architecture regardless of its merits to be called as Microservices or even called as distributed system.

Misinterpretations on Microservices

Here’re the few misinterpretations, which I have heard about…


In this post, I will introduce NATS as the messaging system to Go developers for building distributed systems and Microservices. When you build distributed applications, a messaging system plays a key role to make communications between applications, most probably in asynchronous manner with an event-driven architecture. There are lot of distributed queueing and messaging systems are available for building modern distributed applications. Open source technologies like Kafka, NATS, NSQ, RabbitMQ, ActiveMQ, and Cloud PaaS offerings like Google Cloud Pub/Sub, Amazon SQS, Amazon SNS Topic, Azure Service Bus, are providing different capabilities and patterns for building messaging middlewares and distributed systems. Among the technologies mentioned above, both NATS and NSQ are written in Go. It has never been an easy job to build distributed applications, even with modern approaches like Microservices. Because building distributed systems are always complex, using a complex messaging system will make more complexities to your applications. …

About

Shiju Varghese

Consulting Solutions Architect and Trainer on Go and Distributed Systems, with focus on Microservices and Event-Driven Architectures. Author of two books on Go.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store