With the rise of microservice architecture in the past couple of years, many developers find themselves wondering if it's right for them. There are two frequently asked questions I’ve seen concerning microservices:
Should I switch to utilizing microservices?
When and how should I switch to microservices?
Should You Switch?
The focal point of whether to change your architecture can often be productivity.
Productivity drives developer happiness. When developers are productive and able to make the changes they want, things are good. In an ideal world, programmers would be less concerned about implementing a feature than designing it. The goal ultimately is that we design more than we code.
The problem with all of this is that our applications become harder to change as they grow in size and age. Technical debt starts to pile up and bring productivity to a crawl. What were once considered arbitrary changes then become six-to-eight-hour rabbit holes of trying to understand why a change doesn’t work.
Eventually productivity hits such a snag that something has to be done about it. This is the point where microservices start to appeal to many teams. They offer what looks and seems like a welcome change of pace.
However, microservices are not a short-term bet. They’re a long-term investment.
Neither are microservices a total solution to developer productivity. In fact, they change your team’s entire workflow, skill needs, and way of thinking. The early days of implementing microservices for your projects will likely be full of the trashing and troubleshooting you’re trying to avoid. However, this short-term annoyance should eventually usher back the productivity and organization your team is after.
I’ve learned that teams that are sizing up the switch to microservices should ask themselves a few questions:
Do we want to make a long-term investment in our application architecture?
Are you planning on eventually sunsetting your application? Think three to five years into the future on this one.
Are we feeling limited by a language subset in our application suite?
Do you feel limited by a language’s speed or tooling? We often tout about how a certain language is faster, cleaner, more usable than our current stack. Yet, what would it actually look like if you could write a service in a “better” language? Would the concept appeal to you and your team?
Are we wanting to invest more in serverless services?
Serverless services are a trend with microservices where we delegate certain parts of our architecture to a third-party service. Utilizing serverless services like AWS Lambda could be a really helpful means for your team to start writing microservices.
Are our engineers willing to share problems and issues across different services?
Most small teams have to be able to hand off microservices issues and bugs to one another. You have to be willing to spread out the knowledge base and understanding, perhaps a whole lot more than you're used to.
Let’s assume you finally decide that you want to pursue microservices, but there’s still a question lingering in your team strategy: “When and how should we switch our architecture?”
!Sign up for a free Codeship Account
When and How Should You Switch?
The truth is there’s no perfect time to switch to microservices. However, there are a few important considerations you can put in place beforehand to try to make the transition smoother:
Cut down on feature churn and refine the product you want to decompose into microservices.
Commit to a certain stack of languages and tools.
Establish, at least generally, the product's design as a microservice.
I can’t express how difficult it is to convert a constantly changing application into microservices. If you don’t have a core product to decompose and refine, you’re going to be doing a lot of redundant changes to your services instead of making them more stable.
Committing to a certain language and/or stack is a bit harder in practice than theory. Many companies will tell you that they use a certain set of languages and frameworks, and they certainly might. However, there’s always a crisis at hand as to whether to keep or move on from a certain element of it. Being committed to a certain stack (at least for the time of transition) makes it a lot easier to decompose. You can certainly try to risk a new technology or idea on a microservice. However, you'll be wrestling with the cost of integrating something new as well as a new architecture type.
Have an idea of what you’re trying to decompose into. Try to cut down on the tendency to wing it and change it later just because it's a smaller service now. Microservices work best when they’re modular but also well-defined.
Digesting It All
While it might be easy to think of our applications as soulless digital machines, I’m becoming more convinced we should treat them as our homes. We want to make our codebases warm and inviting to anyone and everyone who encounters it. Does your house have the space for careful organization, for example? Does it give you the ability to only allow specific things in each room?
With microservices, we have to have a preference for that level of organization, and we need the ability to implement that sort of separation. Yet you also have to want to have a finer separation of concerns between each part. If that idea resonates with you and your team, then maybe it's worth looking into.
The transition isn’t easy. However, it could lead to a much more organized and long-lasting codebase at your company.