What to Consider Before Leaping into Microservices
Step one in a microservices strategy is to figure out whether microservices are right for your organization.
In the ever-changing tech industry, companies know they have to ride some swift rapids to stay afloat. In fact, agility is one of the most important keys to business success. If a company takes too long to react to change, an innovative startup will most definitely swoop in to take their market share.
While microservices isn’t the most recent buzzword to hit software development, it’s received a lot of attention lately as a viable option for companies wanting to evolve their capacities and stay on the cutting edge. Microservices is a development architecture that deploys applications as modular services, which then run different processes and communicate through flexible protocols. It allows for swifter updates and rapid, complex expansion. It’s exactly what companies need when they scale and put new business processes into action.
Sounds useful, right? It is. But before leaping head first into microservices, you need to make sure your company is prepared for the challenge. Here’s what to consider before implementing the architecture, and how to make the most of it if you do:
Look closely at your business structure. Are you large enough for your development teams to work separately on complex projects? If not, you probably don’t need microservices. According to Chief Scientist at ThoughtWorks Martin Fowler, the productivity cost of microservices is only worth undertaking for large and complex software projects.
“Unless you're faced with that complexity, remember that the microservices approach brings a high premium, one that can slow down your development considerably. So if you can keep your system simple enough to avoid the need for microservices: do so,” he says.
Determine if you need to deploy components independently. If you constantly have at least two domains in the software your deploy -- that represent completely separate business capabilities or processes -- you have good reason to adopt microservices. Doing so will enable you to create an independent development lifecycle for various components of your application, which allows for them to be updated or deployed without affecting other components of your application. Additionally, you can code the domains using the language that makes the most sense for that component. However bear in mind that these situations require more single component pieces to be dynamically managed by specialized development teams. So, make sure you have enough talent on staff or the budget to afford them.
Consider whether your team has the right skillset. A microservices architecture means you can create smaller development teams that specialize in certain areas of expertise. This should increase the ability to constantly release new functionalities to market, giving a competitive advantage.
However before making the switch to microservices, think about how experienced your players are. Is your team mature enough to work with continuous deployment and continuous integration? Are they well-versed in DevOps culture? If your team doesn’t currently exhibit these skillsets, work on building a more robust group of engineers or, find external partners who can help to complement your team.
Be realistic about your business's roadmap. The ability to exponentially scale has made some of the largest companies into what they are today. Think Airbnb for example, which grew from an air mattress rental website to a $30 billion data-driven marketplace in less than a decade. While it’s important that growing companies remain agile, not every organization has a big need to scale. If you honestly don’t need to address complexity yet, don’t push yourself to adopt microservices.
Be realistic about where your business is headed, at least for the short term, and don’t make your development process more complicated than it needs to be.
So, you’re 100% certain microservices is for you. Here are some quick tips:
Once you implement a microservices architecture, be sure to make extensive use of Domain Driven Design, especially the concept of Bounded Contexts. These are clear boundaries that separate a domain, or the subdomain it uses and clearly define the interrelationships between the participating contexts.
There is no golden rule about how to define Bounded Contexts, as this depends on the domain you’re working on. However, a context map is a good technique in general.
Many experts propose using small microservices. But the size should really depend on how cohesive the concepts are within the domain model, within their Bounded Contexts and the ubiquitous language used. Essentially, each microservice should represent a business capacity. Focus on completing that component well, independent of other services.
Make sure you align your development team structure to the Bounded Contexts you have defined. To reap the benefits of a microservice architecture, your teams should be built around business capabilities. You should not develop transversal teams that create new silos and reduce the independence of your delivery teams.
While it’s tempting to quickly jump on board with hot software trends, leaping into microservices head first may not be the wisest move for every company. Every business is different -- whether it be in size or skillset -- and each needs to find the unique solutions that work best for them. Through keeping in mind your business structure, determining if you need to deploy components independently, analyzing your team’s skillset, and being realistic about your business trajectory, you’ll be able to determine if microservices are right for you, or whether it will only make your processes more complicated.
Didier Tabares is the Senior Software Developer at PSL, an agile software development company offering IT services from its development centers in Latin America.
About the Author
You May Also Like