Microservices: Simple servers, complex security

Keep these details in mind before you dive into the app-containers revolution

The benefits of microservices architecture -- smaller development teams, faster release cycles, fewer dependencies, less risk -- are becoming widely known, thanks to companies like Amazon, Google, and Netflix sharing their experiences. Less widely understood are the security challenges introduced by this new paradigm, but the engineers in the vanguard have wisdom to offer on this front as well.  

You need to keep in mind more than a few details before you rip the wrapping off the shiny new app containers. Instead of securing one monolithic app or a couple, you're now responsible for perhaps dozens of smaller services, all capable of interacting with each other in a number of ways. What's more, you're trying to secure those services from outside attack and internal misuse, deliberate or not.

Not like the old days

Yesterday's monolithic apps were big and inflexible, and the service-oriented architectures created to replace them had their own complexities. Replacing these stacks with loosely coupled applications deployed via immutable containers seems like a step in the right direction, and it is. But it also means several key breakaways from tradition, many of which affect security.

As Eric Knorr put it in his discussion of winning with microservices, these sea changes mean developers end up shouldering responsibilities once held by operations. Security inside of and between microservices falls into that category. A good argument could be had about who has the better understanding of security -- dev or ops -- but remember that developers own the APIs that govern how services interact with other services and with the outside world. That is, much of the security burden falls to them.

Copyright © 2015 IDG Communications, Inc.

How to choose a low-code development platform