Using Side Cars to Get Rid of Distraction

Code is painfully slow to develop. It’s a gigantic problem because business rely on us to help them get powerful outcomes. By automating key aspects of business we can serve populations that weren’t financially viable to serve under more manual processes. Literally the world is depending on us to get better.

For the sake of this article I will refer to code that benefits the business as business logic. This includes activities such as more efficiently routing of vehicles (outcome is lower cost per trip), making financial calculations (outcome is less errors, faster cash cycle, and less manual finance work needed), Error checking inputs (cleaner data for better analytics and reduced manual rework), etc.

In contrast to business logic there are peripheral concerns. These concerns are things like logging, database manipulation and querying, architecture, caching layers, orchestration, configuration, etc. This is all the necessary work that needs to happen in an application, but we should always be cognizant that these activities are supporting and that ultimately we are paid to write business logic.

Side Cars

The microservice world has given birth to the concept of a side car. The name came from an attachment you can add to a motorcycle in order to provide a dedicated seat for an additional passenger. In coding it can be thought of a separate process that can be called within the main code which will provide peripheral concerns to a main process. In Kubernetes you would package your sidecars in containers and then deploy the main container and any sidecar containers in the same pod. We will specifically talk about the Kubernetes use case, but the principles should be applicable to other implementations of sidecars.

In the Kubernetes scenario you would communicate with side cars using HTTP. Pod networking will allow you to use localhost for all calls (so you will need to know the port, but there is no need to know an address). All HTTP calls will have their destination on the same host so you won’t have to deal with inter-host communication failure scenarios.

By using HTTP to communicate with all of your sidecars you unify how you deal with peripheral concerns. Since HTTP provides well defined error semantics in the form of return codes your error handling can be unified. If you are choosing a third party container and you don’t like the API or the error code philosophy you can wrap it in your own container and normalize the interface for your use case. If you want to turn a library into a side car you can use a similar strategy by writing a thin HTTP API layer that calls into the library and turn the return values, exceptions, and/or errors into HTTP responses.

Think about this. All of a sudden any library written in any language becomes available to you. You don’t have to do crazy inter language gymnastics, you simply use something you are already good at: HTTP. The price for this power is writing a thin layer of HTTP around new libraries that you want to consume as a side car. Note: You will still call most libraries the standard way, this is just for libraries that make sense as sidecars.

Purpose?

The purpose of sidecars is to move peripheral concerns away from your main code which should be focused on business logic. The goal is to spend as much time as possible on business logic and as little time on peripheral concerns as is responsible. Sidecars should provide an abstraction layer you can use to pack as many of the responsible actions you need to perform into an easy to deploy, easy to consume, and easy to reason about container.

What should you put into a sidecar? Think about your peripheral concerns: logging, data access, optimization, security, etc. Also think of all of the best of breed tools that other languages provide that you don’t use because they aren’t easy to work with in your language. An optimization example is that you can use Data Replication to fill up a local redis cache that you deploy as a sidecar which provides sub-ms access to critical data. User objects that you lookup on every HTTP request may benefit from such an optimization.

Conclusion

Side cars can help you move peripheral concerns out of your codebase allowing you to focus on business logic. They can also help you normalize the way you interact with libraries and even make calling libraries in other languages trivial. They can help with all kinds of concerns including logging, data access, optimization, security, etc.