Imagine you don’t just create one big badass application, but you create a smart ecosystem of a bunch of smaller ones. For example, one part in the background that receives commands via an API for creating, changing or editing data in the database. Then one app for a search service sitting on another server, optimized for that. And then you have all your code for the frontend part such as the actual website or the interface of your app that displays the data via API commands. Together, they form a microservice architecture.
So, you want to build the first version of your new digital product. Usually, you are full of ideas, but most of them are not yet proven or haven’t been tested with real, paying customers.
The risk here is not just that you develop something your customers might not need – wasting your time and money – but that you also gather a lot of insights. Eventually, this might mean that you have to restructure your software and the setup of your data.
This gives developers a lot of headache: adding is always easy – but reconfiguration is hard!
Microservices are about decoupling, i.e. separating code by concerns, and address exactly those issues of agile development. Compared to monolithic software, it saves you from bigger rework (refactoring) of your code in short development cycles.
One of the common separations of concerns is loosening the connection between frontend (what you see) and backend (what is processing the data on your server).
There are already other approaches, like MVC, which separate frontend and backend within the file structure (M = the model that defines the data structure, V = the view that defines how to display it, and C = the controller that defines the processing of the data). But still, when working in teams or distributed project settings (for example co-ordinating the work of multiple teams, working with freelancers, other agencies, or even with open source communities), this can lead to problems. Problems in maintaining code, finding bugs, and especially when switching technologies in one of those parts with potential side effects. Furthermore, having smaller modules that deal with separate concerns also helps to keep the sensitive parts of the code hidden and not unnecessarily exposed – this becomes particularly relevant with bigger projects and larger teams.
But there are more advantages to microservices than just improving the developers’ team work. Here are our top 3:
Once the number of your users grows, you will run into the need to ramp up more server resources. But which part of your app consumes the most server power? Usually, it is not your database but, for example, servers for real-time interaction (e.g. messaging) or the frontend, needing to serve many more people. You might have a number-crunching backend, a data indexing service for fast search, or computing, for example, statistics in intervals. All of this requires an appropriate server power. Imagine you have your frontend stationed in powerful content distribution networks (CDN) across the globe instead of having everything on a single server. This makes it much more responsive for people all over the world while maintaining all the data in one place.
With microservices, you can scale exactly the part you need.
Since the different functionalities are separated, it is also much easier to replace them. For example, if you want to use a new front-end technology, like React, you can do it without changing your backend. The same goes for updates in backend libraries. You can, for example, plug in a whole new layer (such as high performance caching) without affecting the other parts of your ecosystem. This is especially important when you grow your features, or even your whole business case, as your product evolves.
With microservices, you never need to relaunch as a whole again, but can iterate in chunks.
APIs are one of the drivers of our connected world. You can get access to data from other services and devices (from maps to the heating in your flat). Building an API for your application to connect the different parts allows you to open up to future developments or even external partners. Our favourite course of action here is to first build a web application running in your browser. Then, we build a separate mobile app, connecting to the same data. But there is more! This approach forces you to be very clear about the functionality and what the data is needed for. Even in big teams, a well-documented API decentralizes the development and brings more speed through parallel development into your whole product roadmap.
With microservices and APIs, you are ready for future opportunities.
We already enjoyed quite a few projects building on a microservice architecture, and have learned valuable lessons from it. For example, when you need your users to be logged in and identified across multiple servers, you need different authentication methods (e.g. tokens instead of sessions). To be able to take full advantage of one of the main benefits of microservices – working in parallel – you also have to take extra care to document everything you do properly. Moreover, despite the fact that testing and debugging is much easier with microservices, you should still remember to do complex test scenarios and, of course, user testing. And, last but not least, make sure to be careful while moving on other on-premise instances. Always have a SysOP involved.
Now, with all of this in mind, Dominik, our CTO, summed up how we feel about using a microservice architecture: “At first, the thought of using a microservice architecture makes you feel overwhelmed. It implies a lot more work, and it can be a pain to set everything up. But eventually, as your structure grows, you’ll realize that you made the right call at the beginning. Yep, it actually made things a lot easier for you further down the line.”
We ultilized a microservice architecture while working on one of our biggest projects – Wir Von Hier, a high performance, real-time web application. It serves as a neighborhood social network with a marketplace, groups, events, direct messaging and much more.
Was this article helpful? Are there any questions you would like to ask us with regards to planning a new project?
Drop us a line at firstname.lastname@example.org!
And to all the developers out there – if you would love to build a new digital product in a microservice architecture – Come on board and join the pack!
Edited by Daniela Patterson
Visuals created by Denis Simonenko