The buzzwords "microservice" and "open-source" seem to go hand in hand. Perhaps it's because the microservices architectural vision came along recently, on the heels of open source establishing itself.
Perhaps it's because the open-source world is a chaotic N-body simulation filled with thousands—if not millions—of different chunks of code, pretty much working together, microservices-like. More or less. Or perhaps it's just because we all like to mix our favorite combinations of microservices, and those inevitably will include some open-source tools.
That's the secret of microservices. By splitting your architecture into many different parts, it's simple to mix and match the right tools for your application. Some might be proprietary and some might be open source, but as long as they can communicate, the work will get done.
Note that all microservices do not need to use exactly the same foundations. That's the beauty of microservices. They're independent and communicate through API calls. The insides can be wildly different, and those differences can be maddening for some developers on your team, but the approach can be useful when faced with supporting legacy systems.
Here are nine open-source microservices foundation options that are battle-tested and ready for your data center.
Use containers to package up your bits
The simplest way to create a small, interchangeable block of code is to use Docker, a container creation suite that packs up the essential bits so they can be started up easily on a server or, say, on an entire cluster of servers. Containers have changed the way that developers test and ship their code by making it all but certain that the code that runs on your desktop will run the same way on a server in a distant data center anywhere on Earth.
Docker is probably the most widely used container system, but it is far from the only option. The LXC/LXD combination from Canonical and even the rkt tools from CoreOS both have smaller followings. (The idea has even found a home in the closed-source world, where Windows Server users, for instance, can deploy some of the Windows containers available since 2016.)
Don't forget a scheduler
Microservices architectures rely upon running more than one copy of a container at a time. Sometimes, when demand is high, there could be dozens or even hundreds of containers answering requests at the same time. Organizing this chaos is the job of a scheduler, which monitors the load, creates new servers when needed, and destroys them when they're not.
Kubernetes is the dominant tool, and it continues to get more popular. The clouds that once offered you a chance to boot up an instance of a particular OS are now offering Kubernetes clusters with just a few clicks. Google, which built the original Kubernetes tool before releasing it to the open-source community, knew a few things about running massive server farms.
The Kubernetes clusters will "self-heal," which is to say that they'll notice when containers have locked up or stopped responding and just replace them with a new version that's booted from scratch. A scheduler can cover up a multitude of programming mistakes and lead to some sloppy coding, but it is essential for keeping a microservices application running when one part goes south.
There are other options. Docker's Engine has a "swarm mode" that will fire up a number of containers, but it remains a distant second in the marketplace.
Linux is usually a good pick for OS
Standardizing on one version of an operating system may be the least important part of the process. Many of these tools run smoothly on all versions of Linux, Windows, and even macOS. Any differences among them are often abstracted by other layers long before they get to your code.
In general, unless you're using some of Microsoft's tools, the cloud machines run a version of Linux. Ubuntu is popular, but some vendors choose by default the local versions built by the cloud company, such as Amazon's version of Linux.
Lots of choices for databases
Some call the database the original microservice. In goes a compact query and out comes a well-formulated response. The top open-source database choice continues to be MySQL, which now has a close cousin in MariaDB. Version 8.0 of MySQL offers a range of new features, including built-in tools for managing geographic information (GIS) and juggling requests for JSON-encoded data.
The database is so popular that many cloud vendors now offer hosted versions that run preconfigured versions of the database on optimized instances, so you don't need to spend the time and energy putting together a secure server. The services are also popular with cloud users because the database is open source, making it easy to migrate to a different cloud provider or on-premises server.
PostgreSQL continues to be a popular alternative, with almost as many devoted followers as MySQL or MariaDB. Many common packages such as content management systems (CMSes) will work with either interchangeably.
Give your microservices some Swagger
Microservices clusters tend to come with plenty of API endpoints, and Swagger is one of the most common open-source tools for building a RESTful interface. You write a simple configuration file with the OpenAPI format, which defines the parameters for the API, and then Swagger does the rest.
The CodeGen tool turns the configuration file into the basic boilerplate for answering all of the API calls. At least 20 different languages are supported.
The configuration file also supports the developers who come along later by generating documentation and building pages that can be used to test the API's behavior. This result is usually in a standard location, making it simpler for a new programmer to navigate through a maze of API calls. That's what standardization is supposed to provide.
Monitor and conquer
Old techniques for debugging tools don't work as well when the app is split into dozens of microservices. Prometheus is one of the dominant tools for tracking the sequence of calls as they flow through the network. The server collects metrics that measure when the APIs are called; then you can filter and display the results in a visualization dashboard. If one of the services goes south, it will probably show up here immediately.
Some of the components are complex enough on their own to justify dedicated tools. Kibana, for instance, is a popular tool for watching over Elasticsearch, a search engine based on the Lucene library. The performance of the cluster and the responses are tracked in detail so you can see when (and if) rebuilding the index is necessary.
Grafana is a more general program for analyzing any time-series data; it's been optimized to handle the log files produced by monitoring your cluster. That can mean data from Prometheus or from other tools, including InfluxDB or AWS CloudWatch.
Testing is key
Developing microservices means writing test cases that make sure that each of the services behaves correctly. Sometimes writing these tests can get tedious, so some developers are turning to tools that record real API calls made to the HTTP port so they can be replayed during testing. GoReplay and VCR are two of the popular libraries that create verbatim copies of the data, so you can keep on testing it until the code does the right thing.
Establish trust with JSON
JSON Web Tokens help your microservices prove themselves to each other by bundling digital signatures with JSON data structures to add authentication to your constellation of machines. The open-standard RFC 7519 joins together a header, the payload data, and a digital signature that can be generated with a private key (HMAC) or a public key (RSA).
Messaging options and considerations
There are dozens of different options for delivering messages among microservices, and the right choice depends heavily on your architecture and the structure of the flow of information. The simplest option is to set up each microservice as a separate web server that answers to HTTP calls. If you need to move some services to different clouds or your private data center, the entire Internet is ready to deliver your messages.
Faster, more specialized message services can orchestrate the flow of data through a complex architecture by multicasting packets and ensuring delivery. Apache Kafka, for instance, borrows a sophisticated consistency mechanism and treats the network as a distributed database where messages are committed. RabbitMQ is one of the most widely deployed mechanisms for basic asynchronous message delivery, and there's a large collection of plugins for extending it.
The open-source way forward
If you take one thing away from this article, let it be this: The open-source software realm and microservices are natural partners. Instead of embracing one monoculture, you can knit together solutions from different stacks and different environments unified by some service messaging solution.
Not all of the answers need to be open source, because there's plenty of room to mix in proprietary solutions from vendors that may even host the code themselves. All of these parts can evolve independently as you add new and improved microservices to support better features.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
