Microservices are an innovative way to accelerate and improve software development. The term refers to application subcomponents (think ingredients) which can be developed separately and which often focus on one specific function. For example, an ecommerce application for online shopping may have several microservices involving order collection, account access, inventory management and shipping. Many well-known ecommerce or social media organizations such as Twitter, PayPal, Amazon, eBay and Netflix rely upon microservices.
Microservices are similar to containers, but not identical. Think of microservices as molecules and containers as atoms; microservices can run in containers but not vice versa. Microservices communicate with one another via an Application Programming Interface (API) as part of the overall ecosystem, or architecture, of the application.
There are several advantages to microservices: They are quick to spin up, they can be reusable, they promote scalability and they can even consist of different coding languages. It's easy to update applications if only one or two microservices needed to be adjusted, rather than the entire program. They can help facilitate and track change, troubleshoot issues, promote fault tolerance (such as by using redundant microservices) and improve performance.
As with every element of technology, there are security risks with microservices as well as best practices for appropriate usage. At face value, it would seem the microservices "molecules within an atom" concept bodes well for security since you might expect application vulnerabilities to be sandboxed off behind virtual walls, so to speak.
However, vulnerabilities still can and do exist and even if only one microservice can be compromised - the account access microservice in the ecommerce application example - that still represents a risk. After all, if burglars can only break into one room of your house and manage to infiltrate the living room, your flat screen television still ends up on eBay. In addition, the plethora of diverse microservices can also increase complexity and make security harder to achieve, especially if different developers and methods are in use across the application.
Owen Garrett, Head of Products of NGINX had this to say about microservice security:
"Microservices have different security risks than a monolithic architecture. Differences include:
Communication Changes: Monolithic apps use in‑memory communication between processes while microservices communicate over the network. The move to network communications raises issues of speed and security.
Data Stores: Microservices use many data stores rather than a few. This creates the opportunity for implicit service contracts between microservices and services that are tightly coupled.
Technical Expertise: Microservices can create additional complexity, and in turn security gaps, if the team in place doesn't have the right experience or know how to properly manage them."
Here are ten tips for securing the microservice architecture:
1. When developing microservices, establish common repeatable coding standards which can be reused elsewhere and reduce disparities that can lead to exploitable vulnerabilities or escalated privileges.
2. Develop an understanding of what access is needed from a minimalist perspective; less is better. Consider what damage can be done to (or by) each particular microservice if it should be compromised, and see what can be adjusted or safeguarded against.
3. Use access controls to provide data only to processes or individuals which should have it. Apply segmentation to separate functions and environments where possible. For instance, a microservice which merely checks inventory availability should be granted read permissions to a database rather than read/write if there is no necessity for it to create or change existing information.
4. Utilize security principles within the code of the microservice, not applied after the fact through external methods or processes.
5. Where possible, use centralized security or configuration policies which can be applied across the board to build consistency and reduce the necessity for human analysis or interaction.
6. Peer review microservices code so multiple sets of eyes examine and approve it. This can reduce human error as well as provide additional insights into code feasibility.
7. Fully document each microservice to illustrate what function it serves, so potential weaknesses can be exposed (for instance, a messaging microservice which communicates with an Exchange server that permits open relaying which might conceivably be hijacked and utilized to send spam).
8. Fully map out the communication methodologies between microservices so as to identify potential problem areas as well as irregular behavior that might signify a vulnerability exploit or hijack.
9. When using external access (such as to another server or storage device) utilize encryption for data in transit (such as through HTTPS via certificates) and at rest.
10. Conduct periodic code and usage reviews of microservices and remove any which are obsolete or unused.
Experts explain why microservices are overhyped
Why microservices are about to have their "cloud" moment
How one e-commerce giant uses microservices and open source to scale like crazy
Microservices 101: The good, the bad and the ugly
Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.