Microservices—how they can help you to build software quicker and at a higher quality
Migrating to a microservices architecture for an existing application is a tough investment to make. Even if you understand the merits of microservices, how can you justify multiple months of reworking your software-stack without delivering any apparent feature improvements?
You as a developer might understand the potential of a new architecture, but you know you could continue on your current platform.
But I promise — invest now and you will see near-term results in form of faster development-cycles, higher quality releases, more motivated developers and satisfied executives.
Before we start to have a look at microservices, let‘s first review the more classical approach of how most organizations are building software: The Monolith.
The Monolith
A lot of software products start with a so-called monolithic architecture, in which the whole source-code lives within a single code repository and gets compiled and packaged as one executable for deployment.
A single code base can grow very large and individual developers usually specialize in certain parts of it. This approach makes sense, since not every developer is equally skilled and has all of the necessary knowledge about every component in the application. It is quite common that large development teams shape smaller feature-teams, who own certain parts of the application and work autonomously.
Another advantage of a monolithic application is that it is generally easier to debug since the whole code gets executed within a single process. Developers can use debugging tools and examine the whole state of the application. Performance-wise one of the benefits is that memory is shared amongst objects during execution and individual components can communicate with others in a very efficient way using function calls.
So what’s the issue? Why is everybody talking about service-oriented architectures? The two main pain points of monoliths are:
- individual release-cycles for distinct components
- horizontal scalability of separate components
Let’s now compare these attributes to microservices.
The Microservice
Have a look at my personal definition of the term microservice:
A microservice is an encapsulated and loosely-coupled piece of software, that usually runs as a separate process, can be reached over a network interface and is deployable in an independent way.
Although this definition is quite compact, it contains everything special about microservices:
- encapsulation
- communication using network interfaces
- deployments in an independent way
At Cognigy, the tech-startup I am working at, we ship our individual microservices in a fully-containerized way using Docker. This allows us to pick the right technology for the right job. Some services are written in Python, others are based on NodeJS or GO — the strong encapsulation makes all of this possible at no real cost.
The communication between services is often based on network interfaces. We are utilizing the AMQP protocol and a central message-broker that all services connect to. There are other possibilities out there, such as making HTTP requests, using WebSockets or the binary GRPC protocol — in the end, the idea is always the same: Connecting various services by some sort of message bus. The caller has no clue about the inner structure or functionality of a service, which turns out to be quite handy if you want to apply changes to a service without breaking the whole application.
Deployments often utilize a container registry, in which container images are stored on a per-service base. Developers can then ship updates to single services which can be transmitted to servers and get deployed in seconds.
Why does it matter?
Let’s have a closer look at how a microservices-based architecture impacted my work on the Conversational AI Platform COGNIGY.AI
COGNIGY.AI started as a monolithic application, with our NLU (=Natrual Language Understanding) stack being the only exception. As a startup, back in the early days, we were totally focused on building new features for our product, in order to be able to sell it to our first clients. Even though our software stack was already fully containerized, releasing this ‘huge boy’ was quite a nightmare. After a new release-candidate was finished, the testing hell started. We often spent multiple days testing the new version to be confident, that we did not break stuff. On the other hand, the pressure to release new things was quite high, considering that the first customers were asking for more and more features we did not have back then.
A close look at our release-notes shows, that we shipped 19 versions of our product within our first year in business. With the release of version 2.7.5, we started to think about a new architecture that should allow us to:
- ship new features faster
- fix bugs without affecting the stability of our product
- speed-up deployment times
My team and I went back to the drawing board and we broke down our monolithic application to form individual, much smaller services with a central message broker that connects all components with each other.
After multiple months of work, we released version 3.0.0 of our product, which shipped with 20+ services — all individually updatable and ready for a bright future. In fact, we could optimize our development pipeline to release much more frequently and apply changes with higher confidence that nothing broke.
We’ve had this modern infrastructure since June 2018 and have already shipped 20+ versions of our software since then, on target for many more releases to come for the full year! Additionally, we realized that the number of support-tickets went down since we migrated to our new architecture — a clear indicator for a more stable product!
I can clearly say that it was an invaluable investment to make and has made us more effective as a company. If you are considering making the leap to a new architecture for your product, the business justification is clear.
To be continued…
