Microservices! They’re all the rage these days. There doesn’t seem to be a conference or blog that isn’t talking about them (including this one). There’s good reason for all the interest. There are many benefits to using a microservice architecture…but only if you’re ready.
While microservices solve many problems, they introduce new problems. If you’re not ready to tackle these problems, you should stick with your monolithic application until you are. These are the four signs you may not be ready to take on a microservice architecture:
No Tests
One of the reasons to shift to microservices is the ability to break up a monolithic application. If you don’t have a robust suite of tests, how will you know if your refactoring efforts are successful?
Not only must you have a suite of tests, those tests need to be automated. Moving functionality into microservices is an iterative process, refactoring code little by little. This means you’re going to be running your tests a lot. If you have to do a lot of manual testing, the benefits of microservices begin to diminish and errors can creep in.
No Monitoring
At first, you’ll only have one or two services. As you get more comfortable with microservices and build out your libraries, templates, build processes, and the like, the number of services will quickly multiply. Before you know it, you’ll have hundreds of these things running in your production environment.
You need a way to keep track of them all. How will you know they’re all healthy? If you do detect a problem, how are you going to review the log files. Do you really want to login into hundreds of different servers to look at individual log files?
When you have only one or two monolithic applications, monitoring them is relatively easy, there’s only a few places to look. With microservices, you need to raise your monitoring game to a whole new level.
No Automation
If you haven’t noticed yet, working with microservices will require investing in a lot of automation. Attempting to manage all your microservice instances by hand will quickly become untenable. This means you’ll need to automate everything you can:
- Creation. You’re going to be building a lot of these. Create scripts and templates that takes care of any boiler plate stuff required to get a new service off the ground.
- Deployment. Every time there’s a manual step, there’s the potential for error. Multiply that times hundreds of services and you’re almost guaranteed to make a mistake. Deploying services into each environment should be push button.
- Testing. Don’t leave testing to memory. Run your tests automatically. Avoid manual testing…there’s too much risk of missing something or making an error.
- Monitoring. Part of the service creation should involve setting up the monitoring hooks necessary to keep an eye on what the service is doing. If it’s not automated, someone will eventually forget a step and you’ll be running the service blind.
As you work with microservices, identify things you’re doing manually over and over and automate those things. It may not seem like a big deal now, but as your library of services grow, you’ll be happy you did.
New Project/Startup
Even if you’ve got amazing tests, a world class monitoring system, and you automate the heck out of everything, microservices may not be for you…yet.
If you’re just starting out, just build a monolith.
In the beginning, you won’t know where the domain boundaries are be for your application. Even if you think you do, you’ll be wrong. There may be some obvious candidates to break out into separate services (offline batch processes, asynchronous queue processing), but once customers begin using your site, many things will change as you learn and adapt to user behavior.
In addition, new projects usually need to move fast in order to get to market and start making money. Setting up all the infrastructure for automated testing, monitoring, and deployment takes time. Deploying a single application doesn’t require that investment.
Think Before You Leap
Don’t get me wrong, I think microservices are a great evolution in the way we build applications. However their benefits are not free. Build out your tests, invest in your monitoring and deployment infrastructure, and automate everything you can. Even then, think about whether you are really at a stage where microservices make a difference for you.
Question: What else do you think is necessary to be ready for microservices?