Microservices are quickly becoming a preferred pattern for modern software applications. And while the pattern certainly has clear benefits for some use-cases, it’s not always the best choice.
I recently tapped four senior engineers with microservices experience from the GunIO community to shed some light on the right - and wrong - time to choose microservices.
To see the full video interview, head over to our Microservices vs. Monolith page and check it out.
I’ve included a text version of the answers to my first question below. Hope you enjoy the full video.
“Microservices patterns seem so intuitive and easy when you look at them from 50,000 feet. Where are some of the major “gotchas” and how to do you mitigate them?”
Danny Graham - Senior Software Engineer
“First, it's really good to understand the domain that you're working in. What's the business trying to deliver? What are the goals?
And if you're not already speaking that as a business, that should be a good warning sign. Don't start talking about microservices until you can understand your business.
What are the domains that you have? How can you articulate the context that these services might be operating in?”
Jordan Schatz - Senior Software Engineer
“You can't do microservices unless you've already gone to containers. Unless you can manage your infrastructure in your services as code rather than one-off snowflakes, you're going to have a hell of a time trying to manage a hundred or a thousand microservices at different versions at different deployments.”
Matt Rosentrater - Senior Software Engineer
“Everyone wants to do microservices. And I think, sometimes, clients feel like “I need to build a microservices” but a) they don't know what it is; and b) it just sounds good so “We've got to build a microservice.
There are a few things that I always look at on a microservice. I always say to a client: ‘Know what a microservice is and how it's going to benefit you.’
Some of the gotchas with microservices, I think, are anti-patterns. A microservice should be something that's small, bite-sized, very efficient, and preferably running in concurrency.
When some developers design these, they kind of design these anti-patterns. It's kind of like ‘If this and not this, do this’ and you're going, ‘Wait a minute, is that a double negative?’ or ‘What's going on?’
That's kind of my take on the microservice patterns.”
“There are alternatives that smell similar to microservices that might fit some immediate need; but, in general, it's a good idea to make sure that you're speaking the language of the business domain and you're able to articulate the boundaries and the complexities of your business before talking about the microservices that will solve those problems.”
“I would say that communication is one of big gotchas. How do you ensure that an update for one service does not break some functionalities and another service.
I think documentation is really key there. DevOps is also a pretty big one. Generally, with microservices, the individual code bases are much less complex but the communication between each one of them is much more complex. And so, you really need to have a mature DevOps team. Each service is going to have its own set of dependencies, deployment configurations. You're going to have nightly cron jobs, etc. So there's going to be a lot more moving pieces there for each individual application.
Network communication is also a pretty big one. A lot of times, helper function or would-be helper functions would turn into really just Ajax request so performance issues and network lag ─ you can have a ping-pong effect with your request responses between each microservice, so what would normally be a single request response cycle with a monolith can turn into like multiple request responses. It can decrease performance.
To get around that, you need to have really fast and reliable connection and also be able to handle errors gracefully when networks go down.”