Microservices does not mean small applications. It is an application architecture that helps businesses and developers break down their monolithic applications into separate services, according to Chris Richardson, founder of Eventuate, a startup with a focus on transactional microservices. Richardson explained that there is no such thing as a microservice in a keynote at the Oracle Code developer conference in New York today.
“One of the problems with microservices architecture as a term is the first thing you hear is ‘micro,’ which suggests a service should be tiny,” said Richardson. “In a nutshell, it is an architectural style and it structures an application as a set of loosely coupled applications.”
Richardson’s explains that developers should think of the ‘micro’ as silent, and think of it as a service architecture or distributed architecture.
In an application architecture, the key characteristics it needs to provide are the ability for developers to easily maintain, evolve, test and deploy a system. Size is secondary, according to Richardson. These four characteristics are important because businesses want to innovate faster due to commercial pressures and the fear of being disrupted. “What that means for software developers is we have to build better software faster. [We] have to do a much better job of keeping up with the business and develop software in a much more timely way, and that software is likely to be more complex,” said Richardson.
The point of a microservice is not to be small, but instead implement meaningful business functionality, be developed by a small team, and provide minimal lead time with high deployment frequency. Since microservices break down a monolithic application into a set of independent deployable services, it makes it easier for developers to maintain their code, easily evolve the technology stack, and test. As a result, microservices is a key enabler of continuous delivery because the architecture is much more easily testable and deployable, according to Richardson.
However, like with all technology, there are no silver bullets or perfect technology, and that is true of microservices, according to Richardson.
Microservices become a lot more complicated to handle because the data is distributed across different services, and there are a lot more moving parts that have to be deployed, managed and monitored than a monolithic architecture. In same cases, a monolithic architecture might actually be a better path to take, Richardson explained.
A monolithic architecture is simple, and structures an application as a single executable unit. “This is not necessarily a bad thing if we are building a small monolithic system,” said Richardson. Like microservices, a small monolithic system is easy to maintain, evolve, test and deploy. The problem is when you have a successful application, the development doesn’t just stop. You keep growing that application, and adding more code until eventually you end up in what Richardson calls “monolithic hell.”
“This situation [is] where basically all aspect of development is incredible painful,” he said. “This monolithic system is just too complex for anyone to understand, and [it is] extremely likely that the entire modularity is broken because…no one understands what the structure is.”
In monolithic hell it becomes too big to understand, too long to test and deploy, impossible to be agile, and too expensive or risky to change your technology choices. “There are a few executions of this rule, but the odds are eventually you will outgrow your monolithic architecture and you will end up in a world of pain,” said Richardson.
In order to figure out what the best application architecture is right for them, organizations need to ask themselves if microservices will be a good fit for the business, and if it is worth the additional complexity. If organizations do decide to go down the microservice path, Richardson suggest they take a look at the pattern language for microservices to help guide their decision-making and deal with complications.
“The goal of architecture is to satisfy non-functional requirements. Monolithic is great for small applications. Microservices is [great] for complex applications,” said Richardson.
