Getting Started With Microservices
Getting started with microservices can be a challenging and stressful endeavor. It is a giant step for most organizations, and the path to success is paved with risk and uncertainty. There are countless articles and case studies available that attempt to guide you in your decision making and planning process. Many of these articles are intended to drive traffic or leads, without truly taking into considering the individual requirements that each company might have when trying to decide on whether getting started with microservices is the right step. After being involved with multiple microservices initiatives we have put together some guidelines to help guide your efforts.
Business Needs Should Drive a Microservices Initiative
A microservices initiative should not be undertaken just because your competitors are doing it, or because other businesses have had success. Each company has to look deep inside to identify what problems they are experiencing and if microservices is the solution to address those problems. Some questions you can ask yourself to help identify these needs are:
- Does making small changes to my application require me to perform expensive and timely redeployment of the entire software suite?
- Could my internal and external users benefit from features being deployed in a timelier manner?
- Will faster deployments help us reach market faster and make us more competitive in our space?
- Will decoupling our current application strengthen our system and result in increased reliability?
- Does our monolithic application host a large amount of functionality that is unneeded?
- Is our current application able to effectively utilize the scalability and flexibility offered by the cloud?
The questions, and the answers to these questions will look very different for each company. Asking the right questions and evaluating the answers to those questions is a fundamental component in deciding if microservices will work for you. For a more detailed analysis of when a microservices architecture makes sense check out this thorough guide on microservices .
The Right Culture is Needed for Microservices Success
A common theme that we notice amongst the companies we have seen have success with microservices is a mature agile culture and a focus on continuous deployment and integration. These companies are well positioned to fully experience from the benefits that microservices have to offer.
For many companies this means reviewing several key area of the organization; agile maturity, product planning, architecture, DevOps and CI/CD, in order to determine if culture and process adjustments must be made before a microservices initiative is considered.
To fully leverage microservices you may need to realign teams and on-board additional skills such as business analysts, product managers, or product directors. You may need to up-staff your developer and DevOps teams, especially in an incipient effort. Several companies we know have created full-stack, domain teams instead of disparate front-end and back-end teams. Doing so requires some reorganization of people, but it results in greater efficiencies as you deliver functionality and minimize complicating dependencies.
In the most successful microservices practices, developers are fully dedicated to specific microservices. They are not contributing on multiple teams at a time, which has often been tried and almost always proves to be very inefficient.
Culturally, the clients we collaborate with encourage proactive ownership and accountability on their teams. In the agile spirit of continuous improvement, they provide meaningful metrics and constructive, regular performance reviews for individuals and teams. They enable efficient communications among team contributors. As mentioned above, that may require deploying chat or other tools that allow people to connect anytime, from any location.
As you can see, your culture and process have to align with a microservices approach in order to achieve success.
A Microservices Initiative Should Begin With a Well Developed Strategic Plan
Now that you have identified your business needs and ensured that a microservices model matches your culture and processes, you need to carefully plan your approach. There are many factors to consider, and decisions to make. Each one can have a profound impact on the performance of your finished application. You need to decide which microservice patterns you should use and what the best-fit choices are. If, for example, you decide for the pattern of one database per microservic; where changes in the database don’t impact other services, you also need to determine whether it’s to your advantage to use a composer pattern, which could be a composer per domain, per product, or even per team. You don’t want to end up with too many composers and needless complications, but you also should not have fewer than you need, which would saddle you with large set of code that is difficult to maintain. If you need to maintain transactions across microservices, another tool decision needs to be made. We often use SAGA in Tiempo client engagements. Then there is also the question of whether you should use a discovery service, and, if so, what kind; for the client side, the server side, or the registry service.
You also need to determine how the clients of a microservices application will access the individual services. We often solve for this by using an API gateway, like Netflix did in a well-known example, to provide a single entry point to the microservices for the front end. You need to choose among a variety of ways to set up such a gateway.
Your microservices architecture needs a solid recovery strategy, or failure at any of likely multiple points could be ruinous to your effort, especially if it cascades. You should understand the possible consequences of a microservice failing or taking too long to respond before you remedy them. Hystrix by Netflix is one possible solution that can help you ensure latency and fault tolerance and make your distributed systems more resilient when failure is highly probable.
Some organizations rely on multiple instances of the same microservice to enable quick failure recovery, sometimes using a client load balancing tool. If, on the other hand, the database crashes, a good remedy might be a cache from where you can retrieve data until the database is up once again. Of course, you can also combine the two approaches; multiple instance of one microservices together with a recovery tool, and benefit from better scalability and availability.
As you can see, the decisions you make can have a profound impact on the results you experience. Having a solid understanding of everything involved in a microservices migration and a strategic plan to guide you through it, will be your best bet to achieving success.
If you are interested in learning more about microservices please download our 11 page white paper "Making Microservices Work for Your Organization."