Microservices with Go: Why They Are Made for Each Other and What Results You Can Get
Having appeared in the 2000s, microservices quickly became an IT-trend. It’s an agile, user- and technology-friendly solution which suprasses monolithic architecture in many ways. Large companies and startups, which are tending to extend, choose microservices for their projects, and according to the O’Reilly survey, 92% of the respondents have at least some success. At the same time, the effectiveness of using microservices depends among the other things on the programming languages they’re written in.
In this article, the Surf team shares expertise based on 12 years’ experience in back end and specific-task-oriented solutions. We’ll explain how Go and the architecture match each other.
What special is there in microservice architecture?
To see what special there is in the architecture, let’s go through its main advantages, disadvantages, and differences from monoliths. Having in mind the whole picture, we’ll better understand why Golang is a better match for building microservices than other programming languages.
Microservices, or microservice architecture, is an app- and software architectural approach implying that a single application consists of many smaller components. They are loosely coupled and independently deployable, and connect with each other via REST APIs (application programming interfaces), event streaming, and message brokers.
Here are some advantages the architecture has over monoliths.
Launching quickly. A microservice can be launched much faster than a monolith. The reason is that it executes one function while a monolith executes many functions connected to each other by the business logic of an app.
Operable even if the system partially fails. If something goes wrong, it doesn’t mean that all the processes are stopped. Thanks to microservices architecture, you can restore a module or a function while others work properly. With monoliths it’s the other way around: if a module falls, others stop, too. Users wait, and a company loses money.
Scalable. Since we can run each app on a separate server, we can scale it depending on the needs. For example, if a microservice has a low load, you can run it on one server. If it has a high load, receives a lot of requests, and requires much RAM to process, you can scale the infrastructure for it, too.
Easy to develop and understand. To maintain a microservice, programmers don’t need to know everything about the software or the app they are working on. As it is split into independent parts, the specialist works with a separate microservice without impact on others, and doesn’t need to update the entire program. In monoliths, programmers spend much time on minute changes because each change leads to another one.
Deploying independently. Developers can update the server partially, make canary releases (delicately deploy a new version of an app into Production), and check new versions without sharp transitions to the new version (blue-green deployment). It simplifies the development process.
Technology friendly. To build microservices for a project, you can use as many programming languages, frameworks, and tools as you want. In monoliths it’s impossible, so programmers spend their time on “code fighting” instead of thinking of solutions best for business.
Microservice building challenges and how Go helps overcome them
There are three main difficulties that companies and developers face while building an app with the architecture. Let’s get a closer look at them.
Increased complexity
In the case of microservices, we sacrifice simplicity of the system to get higher maintainability and upgradability. In monoliths a programmer can declare dependencies once and have no reason to think about deployment, because all parts ship together. When your team works with microservices, parts of them are on the network. So, to make them work together, the programmer has to do an extra job: identify each microservice, enable access to others, fiddle the firewall, change router setups, etc. And that’s not all.
There are some more things that increase architecture complexity:
- Microservices are complicated to run. The more microservices we build within an app, the more difficult it is to run them, and the more programmers a company needs to do it. However, famous companies pay enough attention to this question and have no problems. A big amount of microservices is normal for large businesses and prospective startups. For example, Netflix uses over 1000 microservices, and Monzo Bank—over 1600.
- With microservices database schema partitioning is necessary. In the monolith, all data is stored in one scheme. Microservice architecture implies that each module has its own database, and the exceptional set of tables that it needs. Besides, a programmer has to carefully control their proper communication. For example, during a transaction.
- Testing can be challenging. To test an app with a monolithic architecture, it’s enough to open the monolith and run the integration test. When we have a microservice architecture, programmers or QA have to raise each microservice, check whether it communicates with each other, and only then run the test.
- Split-brain (network partition) situations are probable. It means that a failure in the network caused the nodes to split into two different networks. As a result, request processing is broken, and data—inconsistent. There is no such problem in monoliths, but it appears in microservices.
With Go all the processes take far less time than with other programming languages. Microservices’ complexity is compensated by the simplicity of Go code. Programmers don’t spend much time doing all the setups, so microservices built with Golang are quicker to launch than with Python, Ruby, or Java, for example.
High resources consumption
Every microservice has its own data storage, runtime environment, so for each of them you need developers, testing tools, source code management system, and scripts. It means, more microservices require more resources. But high resource consumption is compensated by their independence and an opportunity to release new features quicker and easier than with the monolithic architecture.
Go in microservice architecture helps decrease resource consumption due to CPU and memory use optimization. For example, to compare Go and Java, the first one uses 5 times less memory than the second.
Security risks
Microservices are a distributed system. In a microservice architecture, modules communicate through a network. In monoliths, one module can communicate with another module by calling a method within the code—it all happens at the process level. So microservices need extra steps to ensure sustainability, scalability and security. And these are orchestration systems that help developers to ensure it.
The most famous orchestrator used today is Kubernetes. With this Go-powered tool developers wire services together and build successful MOAs (microservice-oriented architectures). Also this orchestrator system provides high data security—it’s important because the microservice architecture itself is inferior to monoliths in this area.
As the Go community grows day by day, developers pay more attention to security and create extra tools to provide it. That’s why there are various proxies and modules to keep data safe, and it makes Go so great.
More Go benefits for microservices and not only
High execution speed. Go is a compiled programming language, so it doesn’t need to create a separate program to translate a program from a high-level language to a low-level language.
Law entry threshold. It’s one of the greatest benefits of Golang in microservices development. Code written in this language is very easy to understand and correct even for a new developer on your team. Specialists understand Go-powered apps quickly, while with other programming languages the process takes more time.
If you want to know more about how to choose a developer team for Go outsourcing, read our article.
Rich choice of toolkit. Golang is famous for the wide choice of libraries, frameworks, and other tools, including special kits for microservices building. Here they are.
- Gizmo. This toolkit provides packages to put together server and PubSub daemons. PubSub is an asynchronous communication system where applications can exchange messages in real time. With Gizmo we get a list of tools that simplify the technical side of the process.
- Go kit. With this library, a developer gets specialized support for Golang microservices. It covers infrastructure integration, RPC (Remote Procedure Call) safety, system observability, and program design. Go kit expands development borders significantly.
- Kite. It is a Go-powered microservice RPC library which helps write distributed systems easier. It also helps developers create distributed microservice apps convenient to use.
To find out more reasons for large companies to choose Golang for their projects and the results they achieve in practice, read our article.
How to build a bank on Go-powered microservices: Monzo experience
Monzo is an online bank platform and marketplace with numerous financial services. Having been launched in 2015th, today, it has over 4 million customers. Understanding the users’ needs and expectations, from the very beginning the Monzo team aimed to develop a bank with the best technology support, with 24×7 access to money, and features being updated in a matter of hours.
Unlike many other companies, the bank started with microservices (instead of splitting a monolith into them only after the business has started to grow). Monzo chose the architecture as they planned to have many developer teams working on different features of their product.
The bank needed:
- an efficient cluster management,
- tools built in different languages—and most of them in Go,
- RPC transport to minimize latency and route around component failure,
- asynchronous messaging for a performant and resilient backend.
To reach the purposes, provide large computing resources, and minimize delays in the development process, Monzo built a microservice architecture solution using AWS for its core banking system architecture. Now in Monzo there are over 1600 microservices, and the company isn’t going to stop developing new ones.
We regularly work with banks and fintechs: create b2b and b2c apps and backend. If you’re interested in financial services development, read Surf’s case studies to find a fresh IT-solution for your company and attract customers with various features.
To sum up
- Businesses often choose microservices due to its scalability, sustainability, and possibility of independent deploying.
- The architecture has not only benefits, but some disadvantages: for example, necessity in database schema partitioning, complicated testing, and distributed systems problems (eventual consistency, data loss, cascade falls etc.).
- Go has many advantages over other languages: easy code writing, high level of security, high execution speed, and law entry threshold make it unrivaled for this architecture.
- Microservices are successfully used in startups and large companies. For example, Monzo bank has built over 1600 microservices including Go-powered ones, and Netflix runs over 1000 microservices. Both companies are satisfied with their choice: they achieved the desired results.
At Surf we have been developing back-end and industry-specific solutions based on microservices and monoliths for 12 years. Large banks, restaurants, retailers, and prospective startups become our clients, and together we implement ideas that help businesses grow. With a client-oriented approach and experienced developers working in-house, we analyze companies’ needs and expectations to suggest modern IT-solutions.
