A Short Analogy
Imagine that you own a small business and are handling all of the inventory, keeping track of all purchases, paying a few employees, managing expenses, and all the other sorts of things a small business owner handles. This is certainly doable when the company is small, but what if your business starts growing and you want to enlarge your store, or potentially open more stores? How much can you handle on your own before bringing in help?
Maybe you bring in some folks and ask them to help out in various areas. It probably doesn’t make sense to get too complicated when you are first growing—you and your new employees can likely back each other up and share supplies and work spaces.
If you are fortunate enough that your business keeps growing, you will eventually experience an increasing need to hire more specialized professionals (managers, accountants, salespeople, stock people, etc.) and ensure that these people have the tools and focus to get their specific jobs done. Each group should do their own tasks as efficiently as possible, working together when necessary, but doing so in a limited fashion. As you reach scale, you are less likely to have your salespeople pitch in to help the accountants balance the books, for instance. But you may very well come up with a system that allows all sales information to be readily accessed by the accountants.
Of course, there is no such thing as a free lunch. As you grow, you add overhead and complexity. And as you add more people, you must manage, pay, and coordinate them.
Like all analogies, this one is imperfect. Real companies grow in as many different ways as there are companies. But it does illustrate a general growth progression, which I argue is similar to that of successful software products.
Grow Software Like You Would Grow a Business
Like a successful small business, software products tend to grow to meet changing and increasing demands. Well-designed software can scale impressively—it is not quite as restricted as a business in the physical world would be.
A successful business manages its growth, figures out the right people to bring in, and sets them up to succeed. A software product should be fostered with the same level of care. Too often, software just accumulates, with new features added as needed but little consideration for the design. By the time the need to reorganize and improve the software is recognized, it is critical.
One of the best practices for software development is to favor decoupling code into cohesive modules so that the different parts of the code perform their specialized roles. This is much like the growth of a well-functioning business, where specialists focus and different groups coordinate in well-defined ways.
A “service” is a focused and independent program that runs on a server. Services are, in this analogy, the cloud software equivalent of business specialists. A well-designed service encapsulates cohesive functionality and provides a reasonable interface to access it. Most cloud software does not necessarily need to start with separate services, but they are a useful, powerful, and natural way to organize growth of a system, much as you would naturally grow a business.
Microservices in the Cloud
Most of my experience in the past decade has been at Cloud Computing companies. During this time, I have witnessed the general acceptance of Cloud Computing and the birth of a new architectural style of software development ideally suited for the cloud: microservices.
There are many good technical reasons for favoring a Microservice Architecture (MSA). These can be found all over the web and in various books on the topic. My favorite of these is Sam Newman’s excellent reference, Building Microservices. I will touch on some key technical reasons for preferring MSAs here, but this is not a deep dive into the subject—I suggest you read the book if that is what you are seeking. What makes me a strong advocate of MSAs is the combination of the technical benefits and the strong support for high-performing teams.
Microservices are the most recent and refined flavor of service architecture. They include good ideas from previous designs, avoid some of the problems, and add new and useful concepts and technologies. A number of key companies have enthusiastically adopted them, and they have inspired a powerful set of open source tools. In short, microservices are the right idea at the right time.
Note that the “micro” prefix is a bit of a misnomer. A more appropriate name might be “focused, right-sized services,” but microservices flows better.
Perhaps the key concept in an MSA is the strict separation of the functionality into small, cohesive services with well-defined and decoupled interfaces. MSAs carry this idea further than previous service architectures by stressing sharp focus, encouraging independent data stores, and even curtailing code reuse. Many of the higher-level benefits accrued from MSAs comes from successful implementations of this concept.
Benefits of Microservice Architectures
Simplicity
As software grows, it can become quite complicated. Programmers who work on large chunks of code attempt to keep in mind all of the various types of functionality and quirks. They struggle with the cognitive load, and too often, the result is suboptimal and buggy code. A well-implemented service bounds each domain to a single, cohesive area. This facilitates the development of deep, relevant product and code expertise by the team and leads to high-quality outputs.
Testability
High-level end-to-end testing of software is critical in order to ensure that the software functions as it should. But high-level tests are slow, complicated, and hard to get exactly right. Well-defined services simplify much of the testing and reduce the overall burden. Short, pointed tests can be created to ensure that each service properly fulfills its contract. A smaller number of high-level tests will still be required, but they will build from a solid base.
Scalability
The “growing business” analogy asserts that a successful business must be able to scale to support more customers. This is also true of successful software. Microservices support scalability by providing a fine level of granularity. Only the services that are needed are scaled, rather than the entire program (in the analogy, you wouldn’t duplicate every role in a company each time it experienced growth). In particular, services are an excellent fit for the cloud concept of elastic computing, which can automatically scale services to match customer needs—in real time.
Industry Adoption
If MSAs were a great new idea that only a few had tried, they would be interesting but quite risky. Fortunately, many companies have already proceeded down this path and have shared their experiences and successes (or failures). A wealth of good information is available on what it means to build an MSA. In addition, there is a thriving and competitive open-source ecosystem surrounding MSAs, where top companies submit functionality that supports various aspects of microservices. The best projects have massive adoption. As with any architecture approach, there are risks, but MSAs are rapidly becoming a well-known and highly adopted paradigm.
Team Alignment
Best practices for MSAs suggest that the services should align with product boundaries. This is ideal for engineering teams, as they can develop expertise on the code and specific product areas. It is useful for Product Management, as they will know exactly which teams own which features. It makes it easier to appropriately staff teams as changes in the work level occur.
Independent Development
The DevOps approach to coding emphasizes the independence of teams—a good match for the clear separation a microservices architecture promotes. Teams make many of their own decisions, choosing tools and techniques they prefer in order to make great products. This independence and ownership allows teams to move forward as fast as they are able, with each team acting like a mini-startup.
No Free Lunch
Microservice architectures provide great utility, but they are neither free nor magical, nor are they foolproof. They are an advanced technique and should not necessarily be the first approach. They should only be applied after a software organization has reached a sufficient level of maturity to truly understand what they are getting into and what they can expect. When properly leveraged, MSAs can provide great benefits, but they do come with their own overhead and costs. When inappropriately applied, they can multiply existing problems.
I recently pointed to the Thoughtworks’ Technology Radar as a great source of information on new technologies and techniques. In a recent article, they urged caution, despite their enthusiasm for many of the principles of MSA. The caveats and warnings are nothing new. Martin Fowler has urged caution for years.
The cautions are all legitimately offered. There is no panacea—no one technique is appropriate for all situations. But if you need to grow the scale of your cloud software to support the success of your business, you should definitely consider a microservice architecture, for both the technical benefits and their support for high-performing teams.