Virtualization of the compute layer was revolutionary for its time. Fast forward 5 years, and
containers took that to an entirely new level. The rate at which things changed after that is historical. It is
best read from a Wikipedia entry. The common thing of that time was to expand horizontally. Kubernetes
exploded the number of containers. When the number grew, orchestrating the communication between
them was important. The era before that was all about expanding vertically. More virtual servers per
physical server. Did you realize back then that it was the horizontal expansion that fuelled the cloud?
Vertical expansion is currently fuelling the golden era for the development and adoption of AI.
We are intentionally flipping between the vertical and horizontal expansion to build our narrative. One of the
scaling approaches is not Thor’s hammer. At this point of our narrative let us replace the word expansion
with its synonym of scaling. Like Thor’s hammer is a weapon that helps fight many villains and troubles in
the universe the scaling helps us fight many of the computing and business challenges. But it is not always
that either one of them ends up solving all the challenges. Horizontal scaling is good in some scenarios and
ends up solving the challenge typically experienced in retail customer-facing solutions. Whereas the same
type of scaling introduces unmanageable complexity and makes it difficult in fast computing scenarios.
Some solutions even benefit hugely due to horizontal scaling but the cost of maintenance (read taming
complexity) could put it out of favour particularly if you have fewer commercial constraints, vertical scaling
could fit the bill.
We found ourselves in one such situation in a recent engagement. We had been supporting the lifecycle of
a Line of Business application for a large enterprise. They recently revamped their business structure and
needed a change to the way access was defined within the application. Earlier, the granularity was at the
module level. Now such access checks are needed on blocks of information that are displayed on the
screen. Thus, tuning up the level of granularity of permission check. The labor of writing code that makes
such a check at the desired level of granularity could not be optimized any further as we would have to
introduce those if-else blocks at relevant places in the codebase. But we could think ahead and build a
framework to deal with the changes in permissions for such access definitions. The framework we had in
mind was mentioned earlier in one of our dispatches. It was about reimagining authorization using OPA i.e.,
Open Policy Agent.
If you recall OPA uses a domain language called Rego. In that dispatch, we demonstrated how it can be
used to describe the permissions in the form or rules using Rego. Let us take a quick look back at that here
default allow = false
allow = true {
input.method = "POST"
input.path = ["AssignUserToRole"]
input.subject.roles[_] = "Administrator"
}

Now this rule is to be assessed by the web app in runtime. It is achieved by invoking an HTTP endpoint and
passing the JSON payload that contains the necessary data. In this case the role of the user. We could let
OPA run in a daemon mode as a separate container and the web app as a separate container. If you are a
fan of applying Microservices everywhere, you would have gone down this approach already.
Stop for a moment and think. Microservices are good where it is necessary. For the context, is that right?
We thought it was not. Here are our reasons –
1. If we run OPA as a daemon in its container we will have to pay performance tax.
2. By making OPA as a service i.e., a separate container; we are inviting other services to consume it
as is.
Performance tax
Notice the increase in granularity. With increased granularity volume of HTTP requests flowing from the
web app to OPA would be higher. Network latency will pull down the overall throughput of the system. The
alternative you ask; why not put the OPA as a service within the container hosting the web app? We will
circle back to how on that in a while.
OPA as a service
OPA is a general-purpose policy agent. It can help us accomplish many scenarios where policy evaluation
is required. Thus, the conviction to make it a separate service is very high. However, there are policies
which can be functional and there are those policies that are critical to the security. The level of control one
will put on the policy servers dealing with security control of the system will be far greater than those which
are not dealing with the securities.
Sidecar without overheads
Sidecar is a popular design pattern used while deploying containers. There are two different ways to deploy
one is pawn as a process and another is as a container. By our reasoning above we ruled out the container
deployment. We wanted to avoid the performance tax for one and avoid accidental spider web dependency
on the OPA service just because it existed. How many times we would have encountered this in an
enterprise where such service is consumed “just because it existed”?
This is a cautious step and we are putting this on the table as an option. Remember this approach is no
Thor’s hammer that can be applied everywhere. Now the next big question is how do we do that in Docker?
Docker file
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
WORKDIR /App
COPY . ./
RUN dotnet restore
RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /App
COPY –from=build-env /App/out .
ENTRYPOINT ["dotnet", "webapp.dll"]
The above docker file is a simplified one. We have kept it simple to focus on the key point. To introduce the
sidecar, we will bring about a small change; where we leverage the PowerShell cmdlet Start-Job
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
WORKDIR /App
…
Start-Job -Name -ScriptBlock { opa run –server
https://yoursecuredomain.com/policybundle/policy.tar.gz}
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /App
COPY –from=build-env /App/out .
ENTRYPOINT ["dotnet", "webapp.dll"]
PowerShell allows you to run a job that can spawn the process and access ports. Note this process will not
be accessible from outside of the container. It will be only the web app that can port mapped when the
container is run using the docker run command. The web app can communicate with the OPA server using

a local host address. Within the container, OPA service will be accessible. Thus, reducing the network trips
and making policy evaluation very fast. The HTTPS endpoint from where it is downloading must be a public
endpoint. You could secure it further with signature validation. From an infrastructure point of view, you can
do all that within the script block in the above docker file.
Using the above docker file we have effectively triggered two processes with lesser overhead and more
versatility for the change request that customers demanded.