Everyone is talking about microservices. This topic keeps coming up in meetings with our customers. What are microservices anyway? When should they be used? And when shouldn't they be used?

What Are Microservices?

Wikipedia defines the term as follows:

Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In microservices architecture, services should be fine-grained and the protocols should be lightweight.

Let's take a webshop as an example. Typical business processes consist of searching for items, managing a shopping cart, inventory or item management, checkout, and many others. Each of these processes would now be implemented as a separate piece of software. The webshop itself ultimately consists of a front end that connects the various services through an interface (generally a REST API via HTTP).

What's in It for Me?

Fragmenting a large application into smaller elements has several benefits:

• The individual parts can easily be developed by different teams. It is, however, important to make sure that the interfaces are clearly documented and complied with!
• Individual services can be tested separately. As long as the interface doesn't change, it can be assumed that the whole system will remain stable.
• Deployments are less risky. As long as the interface remains the same, a service can be deployed very quickly or - if necessary - rolled back.
• It is much easier to keep track of a small application than a huge monolith with vast numbers of internal interdependencies.
• A microservice can very easily be replaced or superseded by another one, provided the interfaces remain the same.

But this architecture has its own issues. If the individual services aren't separated from each other thoroughly enough, you end up building a fragmented monolith. This makes the system even more complex than it may have otherwise been.

When Does It Make Sense to Use Microservices?

The following questions should help you to decide whether or not you want to use microservices when designing a system.

• Different speed of change
  Are parts of the application changed a lot more frequently than others? This could indicate that these parts should form their own domain and therefore need to be extracted.
• Different life cycles
  Do parts of the application go through a different software life cycle than the others? Do they use different test frameworks? Do they have different pipelines in the CI system? Do they have to be deployed in a special way?
• Independent scaling
  Are parts of the application subject to higher loads than others? If so, under certain circumstances, it may make sense to scale them separately. In order to do this, however, they will need to be split out from the rest of the application.
• Isolate external dependencies
  Are parts of the application dependent on an external service that often changes its interface or has frequent outages? A "facade" service can standardize and stabilize these dependencies.
• The right tool for the job
  Are certain functions in the application performance critical, and are there actually better technologies for building this part? Then you can transfer the critical part over to a service that uses the best tools for the job. This also allows different teams to use the technologies they work with most efficiently.
• Multiple consumers
  Will a part of the application be used by multiple consumers? An online news portal, for example, can be separated into a content and a front end part. This allows various mobile apps to access the content part, while development of the front end part continues independently

Requirements

Compared to conventional architectures, there are no additional technical requirements. There are, however, a few tools and technologies that can help when using microservices.

Automated tests are definitely mandatory. Unit tests ensure the internal operation of the service, while integration tests can automatically preserve the interaction between the various services.

In order to take full advantage of the simpler deployment and the independent scalability of smaller services, it makes sense to use a container technology such as Docker. Big platforms - such as RedHat OpenShift or Cloud Foundry - have built-in features for automatic deployments or auto scaling.

It is also worth investing in the area of infrastructure as code. More services also mean more infrastructure. Maintaining this manually leaves it vulnerable to errors and is also very expensive. Tools such as Puppet, Ansible, and Terraform can help automate many processes and provide infrastructure versioning.

Since a task may involve multiple different services in the application landscape, it is important to create a central and structured place for the logging data. A front end request should be identifiable through to the last service in its sequence, so that debugging and auditing can be carried out.

Conclusion

Microservices can help to break down large and complex systems into smaller and more easily manageable units. It is, however, of utmost importance to make sure that the fragments are logical, and that services are constructed independently from each other. The number of microservices produced should never be used to evaluate the effectiveness of a development team.

Get more exciting information about technical background and experience reports from our engineers. Sign up for the Engineering Logbook updates to make sure you don't miss anything.