This course explores how to build microservices in Go and deploy them on Kubernetes to create reusable components that can be fully managed in the cloud. We'll talk about what a microservice is and its overall architecture. We'll then take a look at the Go programming language, its benefits, and why it works well for building microservices.

You'll also get an intro to Kubernetes including what it is, what it is used for, and the key components that are needed to get a microservice from code to be exposed on the internet.

We'll then combine these three services to do an example use case where we'll build a microservice in Go and deploy it on Kubernetes. Finally, we'll look at CI/CD integration with GitHub and Google Cloud and how you can automate your deployments.

Learning Objectives

  • Learn about microservices and their overall architecture
  • Learn about the Go programming language and why it's good for building microservices
  • Understand how Kubernetes can be used to deploy microservices
  • Learn about CI/CD with GitHub and Google Cloud

Intended Audience

This course is intended for engineers throughout the tech stack or anyone who wants to get their feet wet in DevOps and learn how programs can be managed in the cloud.


There are no essential prerequisites for this course. However, we recommend that you have:

  • Experience with at least one high-level programming language, whether that be Java, Python, or Ruby
  • A conceptual understanding of Linux containers and/or Docker

All right, if you're still here, glad to have you aboard. Let's dive in with our first topic, microservices. So what is a microservice? Sadly there's no single definition. Microservices is an architectural type. I define a microservice as a finely tuned piece of software that performs a single or small collection of tasks. This is what I considered to be a microservice and you'll see variations of this definition all around the internet.

At their core though, microservices usually meet the following criteria. They are highly maintainable and testable, meaning that they're quick to deploy and to develop. They're loosely coupled meaning they don't have any major dependencies on other parts of a systems code base. They are independently deployable. New versions can be deployed to the stack without interfering with other components. They're organized around business capabilities whether that be a web server running crud endpoints for a single entity or focused around data processing. They should be focused solely on a single piece of your overall application. Lastly, with microservices, they can be owned by a small team allowing your engineering team to have high deliverability.

Okay, so what's the difference between a monolithic code base and a microservice? Well, for starters, in a monolith, all sources in a single code base, it's tightly coupled. Classes can be dependent on each other throughout different parts of the code. This makes the monolith a single point of failure. If one piece of the application crashes, it has the potential to crash the entire application rather than just that individual component.

It's difficult to manage the appointments and maintenance as well. Chances are you will have considerable more downtime for deployments with this model of code when compared to microservices. This is because of the fact that the entire application or API needs to be brought down.

Monoliths are also difficult to scale. When we're talking about scaling, we can scale up fairly easily but that can get costly. Monoliths are difficult to scale out because of their large size dependencies and requirements. The other software architecture I want to talk about is service-oriented architecture or SOA.

SOA can range from a small specialized service all the way up to enterprise wide services. The key difference I see between SOAs and microservices is scope. SOAs have enterprise level scope. Microservices on the other hand almost always have application scope. Outside of scope though, in fact, these two types of architectures can go hand in hand where an enterprise application can utilize underlying microservices.

The other difference between SOAs and microservices is communication. Components of service oriented architectures communicate directly over an enterprise service bus or ESB. The microservices tend to communicate to one another over HTTP. And depending on the traffic, the ESB can actually become the single point of failure for the whole enterprise rather than a single application. And if a single service slows down, the entire system can be affected.

I do want to point out before moving on that microservices are not a cure-all rather, they are just another design pattern that you can keep in your software architectural arsenal. And when the project arises you may find that microservices fit your use case. There is nothing wrong with using a monolith or SOA. In fact, there are legitimate reasons as to why you would want to do one or the other over microservices. Always consider the best tool for the job.

About the Author
Learning Paths

Calculated Systems was founded by experts in Hadoop, Google Cloud and AWS. Calculated Systems enables code-free capture, mapping and transformation of data in the cloud based on Apache NiFi, an open source project originally developed within the NSA. Calculated Systems accelerates time to market for new innovations while maintaining data integrity.  With cloud automation tools, deep industry expertise, and experience productionalizing workloads development cycles are cut down to a fraction of their normal time. The ability to quickly develop large scale data ingestion and processing  decreases the risk companies face in long development cycles. Calculated Systems is one of the industry leaders in Big Data transformation and education of these complex technologies.