More and more companies are looking to orient to a microservices architecture as their business processes and interactions become more complex and exist on a grand scale. For those of you that are new to the game, microservices provide a software architecture that organizes applications as modular services. A microservices-oriented architecture seeks to deploy applications as a set of separate services running different processes that communicate through light, flexible protocols. As such, each microservice can feature a different language; can receive individualized, targeted updates; and has the potential to scale exponentially without affecting the other services of the system.
Ideally, the flexibility of microservices translates to swifter deployments and updates to particular areas of the system, increased innovation from specialized teams, and improved capacity for rapid expansion. This style of architecture also allows companies to avoid cascading failures by separating modules and building robust practices in continuous delivery (CD) and continuous integration (CI), allowing team members to catch mistakes much faster.
But, you already know that because, right now, you’re ready to jump into microservices and you need to know how to structure your implementation in the best way possible. My colleagues and I followed a real-time, self-directed approach to implementing microservices and we’ve learned quite a lot. To help guide you through the process, we’ve put together our top recommendations when adopting microservices.
Clearly Outline Your Business Structure
A clearly defined business structure will make developing a microservices architecture much more successful from the beginning. Most of the benefits of a microservices architecture are due to the fact that systems are separated and teams can be divided based on business capabilities. However, your company might not be large enough to build specialized teams to work on individualized, complex projects.
Think about these questions:
- Do you have both the monetary and human resources available to implement these projects in a responsible, successful manner?
- Are you able to cover the implementation costs of adopting microservices?
- Are you willing to accept the short-term productivity costs of microservices?
- Will your organization run more smoothly on a microservices architecture?
The productivity cost of microservices is high, and microservices are worth undertaking only for large and complex software projects. Be realistic about your ability to take on these productivity costs and what that will mean for your team, your bottom line, and your customers.
Utilize Your Team’s Strengths
Your team is your greatest asset and the deciding factor when determining if your microservices approach will be successful. When switching to a microservices-oriented architecture, you’ll have the opportunity to create specialized development teams. Keep the teams small and interdisciplinary. When bringing individuals together and building teams around your capabilities, consider the “two pizza rule” coined by Jeff Bezos. In case you haven’t heard it before, it posits that you should never have a team or a meeting that requires more than two pizzas to feed everyone.
Adhering to the Agile and DevOps methodologies can be hugely beneficial when undertaking a complex architecture such as microservices. Consequently, your teams should be well versed in these principles. More specifically, take into account the level of experience and understanding your team displays in terms of CD and CI or, more simply, automation and collaboration. High levels of competency are incredibly important for the success of your microservices implementation.
Leverage the expertise of each team member to give your company a competitive and innovative advantage. So, take the time to think about where and with whom each team member will perform best. If your team is not yet technically up to the challenge, consider working with an external partner that has the skills and experience necessary to complete the project while you continue training your team.
Map Your Company’s Trajectory
A microservices architecture is not suitable for every company. To help ensure your company is on the right track, map your expected trajectory for the next few years. Then, use this to determine how microservices will impact your intended growth. Are you going to need to deploy to at least two domains that are built around different business capabilities? Will a monolith application still work efficiently for you in most cases?
Being realistic about your projected growth can help you understand the implementation and productivity costs of adopting microservices. You might never reach the scale of operations of an Amazon or Airbnb, and if a microservices architecture doesn’t seem to be in your near future, don’t push yourself to adopt an architecture that won’t provide the benefits you need. If your architecture doesn’t need to be complicated, don’t make it so.
Also, and perhaps more importantly, be very clear about how this shift will change your user experience or your client journey. With microservices, are your customers able to solve problems easily? Will they be receiving a better product or service after each deployment?
Bounded Contexts Are Your Friend
Hopefully, you’ve done your homework and you’re familiar with domain-driven design (DDD) and the concept of bounded Contexts (BCs). Essentially, BCs are clear boundaries that separate a domain, or the subdomain it uses, and clearly define the interrelationships between the participating contexts. These boundaries are incredibly important when using microservices, because they help to highlight when BCs interact and when activities or information needs to be translated between two BCs. In order to clearly display this information across teams, create a concept map that clearly outlines each BC, its relationship to the other BCs, and how the BCs communicate and share data.
Additionally, make sure you align your development team structure to the BCs you have defined. To reap the benefits of a microservices 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. You should be developing a competitive advantage by being able to release new functionalities to the market through your specialized teams.
Consider the Size of Your Microservices
There are several different schools of thought when it comes to the size of your microservices. Stefan Tilkov, cofounder of innoQ, recommends choosing a variety of structuring systems and avoiding making your services too small, because this will lead to too many “self-contained systems.” Lightbend founder, Jonas Bonér adds that a single-entity approach to microservices will eventually lead to a system that no longer represents the domain and then poses serious problems.
To start, each microservice should represent a business capacity. This allows you to focus and orient your teams appropriately. However, the size should really depend on how cohesive the concepts are within the domain model, within their BCs and the ubiquitous language used. Essentially, each microservice should represent a business capacity and focus on completing that functionality well, independent of other services.
Conclusion
We hope that following our guidelines and best practices will give you a solid foundation on which to start developing your microservices architecture. We know this article does not provide a comprehensive list, but it provides a highlight of the things we found most important to consider. I’d be very interested to hear how you’ve switched or maintained microservices efficiently, so don’t hesitate to get in touch!
About the Authors
Sebastian Velez is director of engineering at Perficient Latin America, a Latin American agile software development company based in Mexico and Colombia. He has been in the industry for more than a decade.
Didier Tabares is a senior software developer at Perficient Latin America, an agile software development company offering IT services from its development centers in Latin America.
