There’s undeniable enthusiasm for microservices. Every conference that focuses on applications has multiple sessions (if not an entire track) devoted to the topic. Developers, application groups, and business units are excited about the potential for faster functionality rollouts, more frequent updates, and the ability for different development groups to work and release independently.
However, one group is conspicuously missing from the microservices party: security.
Part of this comes from a common concern that many new technologies are adopted without thinking about security requirements. This inevitably results in problems when something built using the new technology goes into production and is attacked by external malefactors. Consequently, this has led some security professionals to react to microservices with views ranging from skepticism to outright resistance.
Which is unfortunate. While it is undoubtedly true that security practices need to change in the accelerated application lifecycles that many IT organizations are aiming toward, microservices can actually improve an organization’s security posture significantly. There are four key security benefits that microservices enable, and security professionals should start to recognize how this architecture addresses traditional security challenges very well.
1. Faster distribution of important security patches
You've read article after article about breaches at major corporations, citing unapplied security patches as the reason why a particular vulnerability was exploited by attackers. There’s no denying that lagging patch distribution is a widespread issue—so much so that there are products that allow security patches to be enabled with virtual patching until the patches can be applied to running systems. In effect, this approach gives up on putting patches where they should go and places them in a front-end system. While this approach addresses patch distribution, it naturally comes at a cost to system performance.
The cause of this lagging patch distribution is obvious: Many traditional IT organizations are only able to update their applications once or twice a year (although even six or seven times a year can be too slow). The monolithic code structures mean that everyone’s code has to be put in at once, and with late functional updates and extended integration processes—well, you get the picture.
Fortunately, microservices can make patch deployment easier and quicker. Because most organizations marry a DevOps frequent-release cycle with the move to microservices, instead of releases occurring once or twice a year, they can happen once or twice a week—or multiple times a day. That means important security updates can start protecting systems much, much faster than in the past. Which is a good thing, and a reason for security groups to embrace microservices.
2. Smaller attack surfaces
A key element of microservices is that each service provides a restricted set of functionality (a bounded context). Some people characterize it as a “do one thing and do it well,” UNIX-like approach. Consequently, each service exposes a well-restricted interface. After all, if the service does only one thing, the only interface required is what’s needed to support that one thing.
The net effect of this is that each service has a smaller attack surface: the sum of the points at which a piece of software may be attacked. The smaller attack surface also makes it simpler for security personnel to know where to distribute security patches. A monolithic application executable may end up with many different functions and software components inside of it, making it difficult for security professionals to know exactly where the software that needs to be patched is running.
3. Simpler code structures
Another challenge with monolithic applications that contain multiple groups’ code is that it’s difficult for anyone to know exactly what’s in the software executable. And that means that one group’s security error may have ramifications for another group’s code contribution—and the second group may not even know about it, since it isn’t aware of the other group’s code.
This is a much bigger problem than most people recognize. When security vulnerabilities aren’t merely the result of deferred patches, but of poorly partitioned code or unexpected interactions between code, it’s a nightmare. Trying to track down the root cause of a security problem when different groups have their fingers in the pie is challenging, to say the least.
Trying to figure out how to fix the vulnerability is also a problem. Identifying a fix that needs to cross code boundaries is difficult, since groups that are unfamiliar with the domain that another group addresses have to coordinate their efforts to close off a vulnerable code pathway. Of course, even when the fix is made, you’re back in the extended integration process, which further delays deployment of the fix.
Microservices help with this problem because code is partitioned into separate executables. In microservices-using organizations, it’s common for one development group to maintain full responsibility for all the code running in an individual service. As a result, it’s much easier to enable peer collaboration among a small group that works on a common codebase than it is to enable collaboration among multiple teams in a huge, monolithic codebase. Coding a fix that addresses a small set of functionality is simpler, too. And since microservice-based applications deploy frequently, getting the fix into production is faster as well.
4. Functionality shielding
One security benefit of microservices that is less appreciated is how it enables a defense-in-depth strategy. Instead of having all functionality deployed in a “front-line” service (i.e., a service that provides web access), microservices spread out the functionality. Other application functionality resides in other services that are only accessed by other application executables. This shields application functionality from the outside world and makes it more difficult for external parties to gain access to non-user-accessible functionality. It also means that security personnel can ensure that extra attention is paid to user-facing services, since they will bear the brunt of attacks.
Clearly, this microservices benefit does not mean that internal services do not need to pay attention to security concerns. It does mean that those services can focus on the security issues relevant to their specific functionality without worrying about issues outside their domain.
This defense-in-depth approach also means that critical resources such as databases are less likely to be subject to external attacks, since their access is restricted to peer services, making the overall system much more secure.
Functionality shielding also simplifies the task of security personnel. They can devote their review to the issues related to a given service’s functionality instead of being responsible for tracking a range of security topics applicable to different functionality elements. Security reviews can be executed more quickly, and the results can be held in more confidence, since review attention is focused on specific areas.
Security will be pushing for microservices
The initial misgivings security professionals have toward microservices is understandable. Nearly every new software platform comes with its own set of security issues, most of which are ignored in the headlong rush to adoption. Moreover, security personnel struggle to understand how to translate existing practices into ones appropriate for the new platform.
In the case of microservices, however, security professionals should recognize that this architecture holds the potential for simplifying their job and making the organization’s applications more secure, not less. The partitioned functionality and distributed executable architecture of microservices make assessing security easier and shield critical resources better than traditional application architectures.
I suspect that it won’t be long before security groups are lobbying development organizations to migrate to microservice application designs. My hope is that security professionals will join the industry discussion on microservices now and help lead the push for microservices applications in their own organizations.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
