Considerations for Moving to Microservices

Microservices as a concept has been around for a while, however it’s been picking up steam in the last few years, and more and more development projects and development teams are either moving forward with microservices in their projects or are seriously considering them.

When you are thinking about Micrososervices you need to think about, understand, and come to conclusions regarding the state of your DevOps, development team, architecture team,  business strategy, and overall enterprise architecture.

It’s important to understand the challenges an organization might face implementing and maintaining a microservices architecture, the risks if it goes wrong, and what the state might be if the microservices are only partly implemented or not implemented correctly.  Micrososervices can be a boon or a burden, and this has to be carefully examined by the architect or architecture team to see how Micrososervices will fit into their organization.

What is a microservice?

Consider a microservice to be an entirely independent piece of business where multiple micososervices will be part of a broader microservice architecture.  It simplifies code at the service level because all of the moving parts related to a single microservice are specific to a specific business need or capability.  They have their own set of code, don’t share components with other microsservices (other then some cross-cutting code to handle common scenarios like logging, etc), have their own data structure, and ultimately have their own team who is responsible for it and potentially other microservices.

It’s a paradigm shift from the standard thinking of building n-tier applications, SOA’s, and Service Bus’s that will change the nature of your DevOps, development, and testing.

Micrososervices are generally easily testable, and have no dependence on one another.  They can be written in entirely different languages and have entirely different back end data storage architectures and technology, and can be written and handled by completely different teams as there is no dependence between the code bases.

Consider some examples of business capabilities that would be handled by a microservice to include such business domains as:

• Ordering: The ability for a customer to order a piece of equipment
• Document Generation: Based on an input, a PDF document will be produced and provided to the user
• Mortgage Bundling (Calculation Engine): Engines used to do massive data calculations and computing in the financial or mortgage industry to assess and bundle up mortgages to be resold

Distribution, Complexity, and Lack of Consistency

With a distributed set of services like we see in Microservices, there may be inconsistencies with the development approach, teams, and standards being used.  This could be a benefit if you have completely independent development teams who are experts using different sets of technologies or taking on new approaches.  It also means, as an organization, you may end up with a large number of micrososervices that are designed, developed, and evolve differently with completely different technical roadmaps.  This is not great with smaller numbers of development teams due to the costs in ensuring that the team members understand multiple pieces of technology, but it gives the organization a broader perspective and freedom to use the technology that is best suited for any given business scenario.

With all of this comes much additional complexity.  Your system will be bigger, more complex, yet have advantages of isolated testable code, quick deployments of individual microservices, autonomy between the teams implementing the services, and the risk of a new deployment breaking another dependant service is mitigated completely by the architecture.

Changes to the Team and Organization

Your teams will be smaller as one team will focus on one business capability, although it is completely feasible to have the same team responsible for multiple business capabilities.  These capabilities will present themselves through the microservice architecture.

Teams will have more opportunity to use specific design approaches or different technology altogether, however since many organizations standardize on technology stacks, mixing too many technology stacks can also be detrimental.  The architects should be involved in making decisions on technology for each service to make sure there are not unnecessarily large deviations in technology stack that are not warranted.  It’s important that some levels of governance is still a part of your teams’ approaches.

Your DevOps teams will adjust.  There will be the days of large monolithic deployments and long hours of preparation just to promote your new changes and get them tested.  You will still have times where a re-deploy or initial deployment happens with all services, but generally, the DevOps team will be involved in much larger numbers of deployments much more frequently, but the deployments will be smaller in scope.

Distributed services needs to be mitigated with added code protections, distributed transactions, fault tolerance, and the DevOps infrastructure that goes along with that.

Using and Consuming Data  

Your team will have to adopt an attitude regarding how they use and consume data because each microservice should be independent, including, the data.  Some organizations will try to get away with some data sharing between microservices, but it’s the wrong approach if you are standardizing a microservice architecture.

Data storage needs to be isolated per microservice.  This means not even sharing SQL tables within the same database if a relational database is used.  Your Orders Table will be completely isolated from your Products table.  This is because even a table relationship can be affected by changing one table (one side of the equation), or a rogue microservice could inadvertently fill up a database table causing the entire database to be at capacity, negatively affecting the other business capabilities (microservices).  Even though it can be a source of contention between architects many experts, generally with some exceptions, would prefer completely distinct database stores per service even if the same database storage technology s being applied.

Generally, in many cases, a single database with multiple tables in which the tables are owned and only used by it’s associated Micrososervice can work, but it does bring additional risk to the consistency of your microservices architecture.  This isolation means that a team working within the Product business domain is unable to make any changes to backend data, structure, keys, or constraints, or the Customer or Order business domain.

Risks

Because it’s a paradigm shift for many people, there needs to be good consensus about how the teams will work and work together along with agreed upon governance.

There will be more overhead for many teams especially your DevOps and Development teams as there are now independent code bases that need to be deployed more often as well as the configuration, learning curve, development overhead, that goes along with each microservice project.

This complexity can slow down less capable teams, and the added complexity can contribute to the technical debt if teams are not careful on how they manage the approach to microservices.

Bugs and technical debt will be contributed to if the microservice architecture isn’t used properly or business capabilities in the microservice share dependency.

Integrity of the system will require proactively developing microsoervices independently, but also knowing when code or services should be bundled as a single microservice or a set of separate microservices.  If this isn’t done properly, microservice code may grow organically, but end up ultimately creating dependence on each other due to the fact that their business capabilities are very close or cohesive.

The distributed nature of microservices will require a big focus on reliancy from the development and DevOps side.  This increases the risk of bug and technical debt if the teams are not mindful of the need for resiliency,

Summary

It’s important to understand the current state of the enterprise as well as future state before jumping into a new microservices architecture.  Understanding what is required from your teams and organization, the additional costs, long term benefits and drawbacks, and risks will help you determine if a microservices approach is appropriate for your organization.