7 Things to Consider While Moving to a Microservices Architecture

in part i of my four-part blog series on microservices , i explained what microservices are and the benefits you will see by adopting this architecture.

however, life is all about tradeoffs. in part ii of this series, i will go over the things you need to consider while moving to microservices, as well as some challenges that crop up even when you do everything right.

microservices for greenfield projects

anytime your team develops a new application from scratch, it feels great not to inherit technical debt and be locked into outdated decisions made years ago. most teams developing new apps today would probably choose to containerize them using docker and adopt microservices architecture for speed and agility.

however, there are a few things to consider before you start:

1. degree of independence

the first decision is - how independent do you want your services to be? you can choose one of the following options:

• each service is completely independent with its own database and ui. this is consistent with an extreme microservices architecture where services really share nothing and are completely decoupled. the nice thing is that the team for each microservice can choose the database that best addresses their requirements. however, this approach makes it much harder to ensure that all data stores are in sync and consistent. for example, you need to verify that the same userids exist in all data stores, and there is nothing missing in any of them. also, database management tasks like backups need to replicated by each team.
• you can choose to share some components, usually your database. this makes it easier to enforce standards across all teams and ensure data consistency across all services. however, this also means your services are not completely decoupled and if someone updated a table or schema, other services might be affected as well.

both approaches have pros and cons so you need to decide what you can live with. at shippable, we chose the second approach since we did not want to deal with inconsistent data and then spend time finding ways to ensure consistency.

2. code organization

there are several ways you can organize your codebase. you can create a repository for each service, you can create a single "mono repo" for all services and have a folder for each service. the pros and cons of both approaches were discussed in our blog post on " our journey to microservices: mono repo vs multiple repositories " where we explained why we chose the mono repo approach.

3. technology stack

it is difficult enough to decide on the technology stack for a monolithic application, but now this decision has to be made for every microservice. what seems attractive in theory can become problematic in practice if your services are too heterogeneous. standardization becomes a problem and there is potential for cowboy behavior. also, it's harder for people to move between teams if every team is using a completely different stack.

we recommend a balanced approach where there is a preferred technology stack across the application. if any team wants to override this default stack, they should justify their decision with pros and cons of why a different stack is more suitable for their microservice. your technology stack should include programming language, testing and logging framework, cloud provider, infrastructure, storage, monitoring, etc.

4. operational complexity

microservices greatly increase operational complexity since you need to rethink operations from a very fundamental standpoint. you need to consider the following aspects:

• infrastructure : defining infrastructure requirements for microservices and then provisioning and maintaining infra for each microservice adds a degree of complexity that most ops engineers working on monoliths are not accustomed to. plus, as these services are scaled up and down, infrastructure needs to be provisioned and brought down automatically so you need a very sophisticated level of automation.
• load balancing and scaling : you will likely need a scaling strategy that is much more complicated than for monolithic applications, which are always scaled out (x-axis). with microservices, you will need to figure out if you need to scale all services or just a subset when there is a spike in demand. your ops team will need to understand y axis scaling since the microservices approach is consistent with it and z axis scaling to get the benefits of x and y. more on the scalability cube here .
• service discovery : the set of service instances in a microservices world changes dynamically due to scaling and upgrades. also, services have dynamic network locations, so you need a way for new service instances to be discovered. we recommend a service registry like consul for this since it has worked very well for us. read more on client-side service discovery , server-side service discovery and a list of commonly used service registries .
• monitoring : this has to be configured and maintained for every microservice, increasing the complexity for ops engineer(s). also, the monitoring solution has to handle scenarios where a subset of services are scaled up and down.

the operational complexity itself should give you some pause before you decide to move to microservices. unless you are aware of the challenges with microservices and have a plan to address them, it will be a painful transition.

5. continuous delivery

we agree with martin fowler when he says this in his blog article about microservices tradeoffs :

"being able to swiftly deploy small independent units is a great boon for development, but it puts additional strain on operations as half-a-dozen applications now turn into hundreds of little microservices. many organizations will find the difficulty of handling such a swarm of rapidly changing tools to be prohibitive.

this reinforces the important role of continuous delivery. while continuous delivery is a valuable skill for monoliths, one that's almost always worth the effort to get, it becomes essential for a serious microservices setup."

organizations that evangelize microservices, like netflix and amazon have the resources to build homegrown custom continuous delivery pipelines for their microservices. however, not every organization can afford to do that. even if you can afford it, you should think about whether your time is best spent building fragile homegrown automation that has to be custom for each microservice, or whether you want to improve your own product instead. you have three choices:

• decide that you do not want to pay the microservice premium and stay with a monolithic architecture
• bite the bullet and build homegrown pipelines by cobbling together several different tools that help with parts of the workflow. the problem with this approach is that as the number of microservices increases, the time and effort required to automate them increases at an even faster rate
• use a cd automation platform like shippable that will get you 90%+ of the way towards complete continuous delivery for heterogeneous microservices.

i will publish a blog post on the third option in the next few days as part iii of this blog series that will also show how shippable can help with continuous delivery as well as infrastructure automation, scaling, and service discovery.

6. team organization

last but not the least, you will need to reorganize your team(s) to ensure that every microservice is really developed, deployed, and maintained independently. you can't have your engineers working on multiple microservices since that will invariably lead to decisions that optimize for factors that don't correlate with what's best for each microservice.

an independent, self-contained team should work on each microservice. amazon's 2 pizza team approach gives a ballpark team size - it should be small enough that everyone on the team can be fed with 2 pizzas for dinner, i.e. less than 10 people. each team should be balanced with expertise across dev, test, ops, db administration, ux, and even product management in some cases. this doesn't mean you need a unique team member for each role, just that they should be addressed within the team. for example, a devops engineer satisfies dual roles of dev and ops. similarly, each team can also have a manager who writes specs and defines the ux.

there are variations of the approach above, such as centralizing the ops, product management, or platform teams. these articles shed further light on the ways teams can be organized.

microservices for existing projects

if you want to move your existing monoliths to microservices, you will still need to consider all the points described above. however, there is an additional challenge specific to your case. you will need a strategy that helps you make the transition in stages.

7. strategy to transform from a monolithic architecture to microservices

this is an extensive topic and deserves its own blog post. just like rome wasn't built in a day, your transition will take time and dedication. in a nutshell, you need to do the following:

• implement continuous delivery so that you have the right automation in place as the number of services starts growing
• move to a distributed source control system like github so that teams can work independently without stepping on each other
• dockerize your application to get portability and the ability to spin services up and down within seconds
• always build new functionality as a microservice
• convert existing components gradually, starting from the least complex business functions with the fewest dependencies and working your way to more complex functions.

summary

as you can see, adopting microservices is not trivial and should be done only if you see enough value for your applications. i will elaborate further on continuous delivery for microservices and strategies for moving existing monoliths to microservices in upcoming posts this month.