Microservices aren’t for everyone.

I recently went to a conference where there were several talks on microservices, an architectural pattern that my team at work has been looking at for a while. These were all generally high-level talks about the pros, cons, and use cases for microservices. I was kind of disappointed in the first one when the speaker said specifically that microservices are not good for small teams. It makes sense, but I would say at two and a half developers, our team is pretty small. So after that talk I took some time to reflect.

After a couple more days of talks, I decided to keep going with our microservice plan. Mainly because I think we aren’t technically creating microservices in our case. I’ve read several articles and listened to some podcasts about whether the small apps people are building can actually be called microservices or not. In our case, I think we will end up with some real microservices, but the core applications that we are trying to extract out will actually act as repositories for data that other applications need. After thinking about these talks, I think we may in fact want to combine some of what we were considering breaking apart.

We will still end up with a suite of applications that need to communicate with each other. I don’t think there is any way to avoid that. So the microservice talks were still helpful. There are definitely some tools I need to investigate more to improve that communication. A discovery service, configuration manager, and messaging tool are all things we don’t currently have. We will still keep trying to ‘containerize’ our applications for maintainability, so these are all tools we’ll need even if our apps aren’t technically microservices.

I guess it’s fortunate that we haven’t had a whole lot of time to work on this new architecture yet, since there is still more for my team to learn about it. But I do think we’re headed in the right direction.

Leave a Reply

Your email address will not be published.