These days, many across our industry and others are talking about microservices. It’s one of the buzzwords of the moment, even though the topic as such has a far longer history. With companies like Netflix, Gilt and LinkedIn, among others, drawing attention to this architecture, many smaller companies find themselves confronting this very issue. With cloud providers offering more and more microservice support, and with tools and frameworks evolving around this topic, we at Smaato have also been asking if this is the direction we’d like to go.
I’m not going to explain what microservices are, how you would or should define them, how to deploy and run them, nor if and how you should use them. A nice primer is here, though, should you need one. I’m not even going to provide general advice, but I’ll share some of the thoughts and discussions we're currently having at Smaato. I'm hoping this might help our publisher community and in the developer community at large in your own discussions. Furthermore, I’m quite eager to receive your input. I’m quite sure there are no right or wrong answers, yet a great deal of inspiration can be provided by different people already using microservices, or from those intending to use them.
So how did Smaato's microservices journey start? For a long time we've worked on larger applications that have had 2- to 4-week release cycles. That worked quite well with a small team. As we grew, we needed to find a way to allow more people to work on a growing number of features. We wanted to independently update our database structure - the one point that coupled the applications together. This is crucial, especially during deployments. We also wanted to increase resilience, which is very important for a system serving multi-billion ad requests every single day. Last but not least, the ability to scale parts of the system independently also sounded appealing to our team. This requirement seems to be perfectly met by a microservice architecture.
So we started by looking at some frameworks, namely Spring Boot, Play, and Dropwizard; the Netflix stack seemed too huge for our first try. Eventually, for our first go at this, we decided to use Spring Boot, and created a maven artifact. We implemented a very small application that was basically a read-only view on a single small database, which provided the data over a simple REST interface. We included metrics and monitoring that adhered to our company standards. We created documentation, and finally helped our System Engineers to deploy this service within our cloud. We used two instances and a load balancer. We thought we had created a microservice architecture, or a least a microservice.
We had not - at least not according to commonly-discussed criteria of microservices. Yet it was something useful we created, and it worked. So we found ourselves struggling with the definition of microservices. Of course we wanted to create a guideline for building new ones, but what is it that actually defined a microservice or even a microservice architecture?
So we took a step back and thought again about our initial requirements. We wanted to have:
- Easier migration and smooth deployments
- Independent development and loose coupling
- System resilience
Instead of directly addressing these issues, we were lost in a discussion about what constitutes or defines a microservice. In the end, there was not much that distinguishes a microservice from any piece of software we might develop.
We decided not to worry too much about what a microservice or microservice architecture is, and instead agreed to continue in small steps to achieve the goals we'd set. This would also be my advice to anyone who wants to use microservices, simply because you think you should do it as anyone else is doing it. This is completely wrong, at least when you're defining everything upfront and then expecting it to work flawlessly.
Best to use an agile approach as well here. If your software is becoming an ever-growing monolith, it’s obvious you should do something. Slice it into pieces. Adhere to common architectural principles, use business capabilities. Nothing special just for the sake of microservices. We did this, and we really did not care what we named it. I recommend you also should also take this step by step.
If, in the end, you find yourself faced with a certain amount of services, think about service discovery. Add circuit breakers and monitoring if you head towards a complete microservice architecture. If you need to independently scale, add this to your stack. And so on.
Bottom line: Never use microservices just because you think it’s fancy. It’s wise, especially for rapid prototyping, to build a monolith - that is, one application with all the functionality - with well-defined and loosely-coupled responsibilities. If you then realize that you need to develop parts in separate teams or want to scale just pieces, put them into different applications. Once you're there, you can then reap additional fruits from your efforts, including resilience, the ability to use different languages and technologies, have independent deployments and the possibility to work in different teams.
That's what we've found, in any case. I'd love to hear your thoughts, and we can compare notes in our comments section.