What is a Microservices Architecture?

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a base minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
- James Lewis and Martin Fowler

From this definition, we understand that microservices are small, independently deployable services that work together. These services are focused on doing one thing well (Single Responsibility Principle). In this style, you break down your larger system into multiple microservices that will interact with each other to accomplish the larger goal. There is no standard model for a microservices architecture but most share some notable properties.

microservices architecture

First, they are autonomous. Microservices are typically created by componentizing the software, a component being a unit of software that is independently replaceable and upgradeable. This is especially important as more applications are being deployed to the cloud where load demands can increase dramatically. All communication happens via lightweight networking calls (APIs). The aim is to be as decoupled and as cohesive as possible.

Microservices do not need a standard technology stack. While traditionally large software applications standardize on a single technology stack, when you split your software into independent services you can choose your technology stack for each service. For example, you can use C/C++ for real-time services, Java for the GUI, and Node.js for reporting. You should remember that there will be overhead for having different technology stacks for each service.

You need to design your services to handle the failure of other services; they need to be resilient. This is a side-effect of making the software individual components. You need to consider how a failure of a single service will affect the overall user experience. As a consequence of this, each service should fail as quickly as possible and restore itself automatically, if possible.

Scaling is one of the big advantages of microservices and one of the reasons it is so popular. Since each service (feature) does not depend on the other services, they can be deployed separately. You can now distribute the services across servers and replicate them as load demands increase. Compare this to traditional development that must scale the entire application as demands increase.

Different microservices can be owned by different teams. Teams are cross-functional, which means that they contain the full range of skills for the development of the service. The development team builds the software and owns the product for its lifetime. An example of this is Amazon’s philosophy "You build it, you run it." The advantage is that the development team now has special insight into how users are using their service and can tailor future development to their needs. Teams can also be organized around business capabilities but you will need to watch out for Conway’s Law where the design tends to mimic the organizational structure (see our blog post Overcoming Conway’s Law: Protecting Design from Organization).

Finally, because of the componentization of the software there is a lot of opportunity for reuse of functionality. In the microservices architecture, as you are making the software individual components you should also be designing them so that many different programs can reuse the functionality. This does take significant effort and awareness to be done correctly but can also lead to increases in quality and productivity (for more information see “Effects of Reuse on Quality, Productivity and Economics" by Wayne C. Lim).

To summarize, microservices: are autonomous, using services to componentize the software; use decentralized governance; are designed to handle service interruptions; are easily scalable; focus on products not projects; are typically organized around business capabilities; and promote software reuse. To learn more see our whitepaper "Developing a Microservices Architecture."

A Software Architect's Perspective on APIs and Copyrights


The topsy-turvy legal struggle between Oracle and Google over Java got me interested in the issues that have produced such divergent judgements and such passionate responses. Initially, it seemed that it was about patents, then it turned into a battle over copyrights, and then narrowed to fair use. And this battle isn’t over yet. As a programmer and an architect, I first tried to understand how the legal system thinks about copyright. So, I started thinking about books.

A book is protected by copyright. A typical book consists of chapters that consist of paragraphs that consist of sentences, and eventually we reach words. The same book may also contain illustrations, a table of contents, and a cover. A book may have a particular type of binding and the pages may have a certain thickness and feel. So, when a part of a work is used by another author, how does the legal system decide whether it is an infringement? Simply using the same words in different sentences isn’t enough; after all, we all use the same language. Simply repeating the sentence doesn’t do it either. You are allowed to quote parts of another book in your own work. This is called fair use. Are the titles protected?

Are the events described in a fictional work protected? There is no one answer. Like all things in law, there is a large case history about what is an infringement and what isn’t. The underlying conclusion I came to is that the legal 2 system treats the work as a whole, and then sees how much or what parts of the whole constitute sufficient grounds for infringement. Of course this approach does not provide a clear answer because it is impossible to enumerate all the possible ways that could constitute infringement.

And, yet, I like this approach. This is systems thinking. As an architect, I am used to thinking of systems as a whole. When we think of systems, we think of the parts of the system and how they interrelate with each other, within different perspectives. The perspective is important because we may think of the same system in completely different ways depending on who we are. For instance, as the driver of a car I have different concerns from the passenger in my car; while the designer of the car thinks of it in an entirely different way.

So, let’s examine Java. This particular dispute is from the perspective of the developer. Java software consists of many parts. There is a Java language specification, there are many libraries, there are programs to compile the language, there are programs to package the compiled output, there are fonts, there is a virtual machine to run the compiled output, and there is a fair amount of documentation. There is even the steaming coffee cup logo to go with it. These are just a few components that come to mind.

To complete the notion of a system, we must also look at the interrelationships. The documentation of the libraries obviously depends on the API because that’s a key part of what the documentation is about. Of course, the API depends on the implementation. You cannot provide services that you don’t implement, much like a car with an automatic transmission doesn’t have a lever to shift gears. At an even more subtle level, the API for one part may refer to the API for another part, and even the implementation of one part may use the API or implementation for another part. So, these parts are all intertwined. As an architect, I want to tease them apart in a way that makes things understandable and manageable. Nevertheless, take it from me, not everything can be or should be separated. Indeed, once you accept that one part of a system is a creative expression subject to copyright, then it is not hard to accept that other parts also share that creative expression since they are all interrelated.

So this is what the legal system contends with, when asked to adjudicate about copyright. What is the entire work? How much was copied and does that constitute infringement? This is a daunting task with considerable subjectivity and, perhaps, that is why it gets handed over to a jury to decide on a case by case basis. The higher echelons of our legal system have not been amenable to absolute tests. For instance, you cannot look at the percentage of text that you may have copied to say whether that’s an infringement. And, in this case the higher courts rejected the notion that copying an API is unconditionally permissible.

So how far does this analogy of examining software as a creative work like a book go? Java libraries are organized into packages. Can we think of the Java packages as chapters of a book or the API as the title of the chapters? Here the analogy appears to be fairly weak. The chapters are normally sequenced while there is no particular ordering constraint for Java packages. The title is merely informative or suggestive of what is to follow while the API describes in precise detail exactly how to make use of the underlying implementation.

The analogy between books and software begins to fray to much greater extent when we consider how we interact with them. Typically, we read books. All other uses are marginal – including burning them to express disapproval or holding them up to hide our face. Software is different. We interact with software; we do things with software. When you stream a movie from Netflix, a complex series of interactions ensue. Netflix downloads software into your display device (e.g. browser on your PC); that software then uses APIs to communicate with other software on Netflix servers to show you the list of movies that you might be interested in. Once you make your selection, the software then streams the movie into your device, which also contains software to display it on your monitor or TV. Indeed, the TV may contain software as well. So, software interacting with humans and software interacting with other software is pervasive.

So, here we come to the other aspect of software. Software is used for “doing things” and APIs are central to doing things with it. Indeed, the developer, much like the designer of a car, is intimately concerned about the how the software will be used. The API design reflects it. So, when the district judge ruled that APIs couldn’t be copyrighted, he viewed them as essential for “doing things” and when the Federal Court overruled him, they viewed APIs as an essential part of a creative work.

For me, as a software architect, all of these aspects are parts of the same system. The legal system tries to tease the system apart and apply different parts of the law to different parts of the system. It is a hard task. Some might consider it nearly impossible. And, yet, billions of dollars are at stake and the decision will have an impact on the entire industry. One way for us to think about it is to go back to the underlying constitutional rationale: Copyrights exist for the public good. Let that be the cornerstone for this decision.