We've talked a bit about the shift towards microservices here before, but the first question that often comes up is "how do we embrace microservices?"
This is a great question, and with that, let's take a look at a few things to look at as we begin evaluating the right reasons to move towards a microservices approach. The easiest one to begin with is a new application that is not yet built. As we enter the architecture and design phase, we can start right away by looking at how to deliver a microservices architecture. This may be a change in the way that you've thought about it in the past. How about we go over a couple of quick tips on how to think in microservices.
Architecting for Microservices
Thinking in microservices lets us architect for microservices. The core of this approach is to take the components of the application and create those as individual services. The loosely-coupled approach will mean that you can grown, shrink, upgrade, and deprecate each service more easily.
Truthfully, I could just direct you to read everything ever written by Martin Fowler, but what is important as people who are entirely new to thinking in a microservices mindset, is finding others who've travelled the legacy trail a bit. This is where the Ops in me has helped to give guidance to teams over the years during transitions like this.
One thing to remember is that you aren't necessarily ever done with development. You aren't done with it in legacy architecture, but because the tightly-coupled architecture binds all of the components, there tends to be long cycles of development and requirements gathering. This is where the business side is still wrapped in a waterfall approach.
Using a microservices approach, you can more easily embrace agile development methodologies as well.
Normalization at the Application Level
In database terms, normalization is described as follows:
"Database normalization (or normalisation) is the process of organizing the columns (attributes) and tables (relations) of a relational database to minimize data redundancy." (https://en.wikipedia.org/wiki/Database_normalization)
The reason that I bring this up is that it helps to relate the architecture of your application much like the way a normalized database creates these smaller tables, relates them to each other using keys, and breaking out the data to reduce the redundancy.
Databases that are in third normal form (3NF) are much like what we are striving for in a microservices architecture. Each table is as decoupled from the other content as possible, and the amount of redundant data is reduced as little as possible.
Microservices versus Monolithic in the simplest terms is illustrated here from Martin Fowler's blog:
So, what we have here is visualized shift in the approach. Decoupled components that act as services, bound only by an API. It's really a panacea when you think about it. This is where the fun begins.
In a new development project, you have the luxury of adopting an entirely different approach.
Refactor or Rewrite?
Typically, the choice will come to bring a legacy application forward to a newer architecture to begin to break out components as microservices. This means refactoring the existing code, or rewriting it entirely. The choice will be yours. This is not a choice to take lightly, but it is important to think of this as a long term reduction in technical debt.
Refactoring the application is also an option, but can often mean a much longer cycle to redevelop in the microservices approach. This is less disruptive on a day-to-day basis. The price for limited disruption is that much more effort is expended as well as much more elapsed time.
This bring us to the point where we will pick this up again, but with a true illustrative example. Having an anecdotal reference is very important as we discuss this because it will show us just how the initial challenges of rewriting for a microservices architecture pay dividends as we make the jump.