Securing microservice environments in a hostile world

If you build bridges you have to go where the water is.

miniature figurines on a circuit board amid binary code / hardware / development / microservices
Alfexe / Toni Vaver / Getty Images

At the present time, there is a remarkable trend for application modularization that splits the large hard-to-change monolith into a focused microservices cloud-native architecture. The monolith keeps much of the state in memory and replicates between the instances, which makes them hard to split and scale. Scaling up can be expensive and scaling out requires replicating the state and the entire application, rather than the parts that need to be replicated.

In comparison to microservices, which provide separation of the logic from the state, the separation enables the application to be broken apart into a number of smaller more manageable units, making them easier to scale. Therefore, a microservices environment consists of multiple services communicating with each other. All the communication between services is initiated and carried out with network calls, and services exposed via application programming interfaces (APIs). Each service comes with its own purpose that serves a unique business value.

Within a microservices deployment, one must assume that the perimeter is breachable.  Traditional security mechanisms only provide a layer of security for a limited number of threats. Such old-fashioned mechanisms are unable to capture the internal bad actors where most compromises occur. Therefore, it is recommended to deploy multiple security layers and employ zero trust as the framework. This way, the new perimeter and decision point will be at the microservice.

In this day and age, we must somehow enforce separation along with consistent policy between the services, while avoiding the perils of traditional tight coupling, and not jeopardize security. We need to find a solution so that the policy is managed centrally. However, at the same time, the policy should be enforced in a distributed fashion to ensure the workloads perform as designed and do not get compromised.

The cost of agility

The two main drivers for change are agility and scale. Within a microservices environment, each unit can scale independently, driving massively scalable application architectures. Yet, this type of scale was impossible when it was necessary to couple heavy data services along with the application.

The ability to scale and react rapidly increases business velocity, which allows organizations to reap the benefit in terms of cost and resilience and also improved ways of managing and building the application. However, the decentralized nature of agile deployments introduces challenges in terms of governance.

We should keep in mind that we now have a distributed organization with sub-teams responsible for individual microservices, In addition, the patching and updates are carried out in real time. Eventually, this creates a gap that needs to be filled. The gap consists of visibility and the ability to scale policy in a distributed fashion.

1 2 Page 1
Page 1 of 2
IT Salary Survey: The results are in