Source – veracode.com
I am not a fan of tapas. I’ll take the 22-oz. bone-in ribeye over small plates any day. My wife is the opposite; she loves them. With more tapas bars opening and existing restaurants adopting a “small plate” menu, I find myself losing the battle of steakhouse vs. tapas quite often. After several meals (if that’s what you call them), I will admit I’ve started to see some of the appeal: pick what you’re in the mood for each bite, collaborate with friends on menu selections, and prevent one bad dish from ruining the meal. At the steakhouse, I make my own selection, I commit to a large meal, and my entire dining experience depends on one item that I hope the chef cooks perfectly.
If I switch focus from steaks to software development, I do a complete 180 – I’m all about the small plates. This is not a ground-breaking opinion. The shift to developing several small pieces of software versus a single large application has been popular for a while. The advantage of developing microservices over monolithic applications are numerous:
- Reuse of services across multiple apps. The concept of what defines an application starts to change as the boundaries between applications dissolve. As an example, instead of having four apps that have a payments processing component, there’s one payments microservice that several applications utilize.
- Use diverse technologies. Pick the technology that meets the need of the service. You are not committed to one technology stack for an entire project.
- Easier maintenance. Is something broken or out of date? Update or replace a small service, not a piece of a large monolith that will have rippling effects and create a testing nightmare.
- Development speed. The planning and testing time of incorporating a small change into a large platform can bring innovation to a screeching halt. The microservice architecture allows organizations to bring new features to market much quicker.
Those are just a few of the many benefits of the microservice architecture, which is why most of our conversations with existing clients or prospective customers eventually involve microservices and how they impact an application security program, especially with the rapid development that goes hand-in-hand with microservices. After many of these conversations with various organizations on this topic, here are the three most common discussions points:
- The need for speed. The shift to microservices is often a key component in the adoption of DevOps. If we try the AppSec 1.0 approach of sending code to a security team for analysis and waiting for a report, either speed or security will be sacrificed. Neither should be acceptable in a DevSecOps culture that promotes rapidly delivering quality (including secure) software to market. To avoid being a cog in the DevSecOps wheel, security must automate and integrate testing with rapid feedback loops.
- Centralized view. Shifting to microservices will mean more applications for an AppSec team to manage (albeit much smaller applications). What was once one application will now be dozens of microservices. This means even small-to-medium businesses are seeing a problem large enterprises have for years: running an effective AppSec program at scale. This emphasizes the importance of an easy-to-scale solution with a centralized view for enforcing compliance, maintaining an inventory and tracking metrics.
- Keeping up with the technology. One of the joys of microservices is picking the technology that meets a particular need. As I learn about customers’ development organizations, I hear statements like “we are a Java shop” far less. Now it’s more like “we have Java, Scala, Node.js, and some teams are starting to adopt GO.” If the development team is going to be agile, you need your security program to be agile and continually enhance support for additional frameworks, languages and integration points.
As this shift to microservices takes hold, we’ve been working with our customers every day to help them embrace microservices without sacrificing security. Veracode scans of microservices usually happen in minutes (or seconds with our latest Greenlight product offering); we’ve been solving the problem of scale with our cloud-based solution for years; and, our roadmap is constantly being updated to include support for the newest development technologies.
Shifting to microservices and the greater movement to DevSecOps should allow your organization to create higher quality software faster. Without aligning the application security program to embrace this transition, there will be conflict between speed of delivery and security. At our core, we are a software company. We practice what we preach by using Veracode to ensure our software is secure as we deliver new functionality (via microservices) to our clients.