Modeling DevOps and application delivery with electric circuits
part 2
Part 2 of 3| go to Part 1|go to Part 3
Modeling systems using electric circuits can help you study their behavior. After going over the concept and reviewing Picasso’s take on it (if you missed it — read part 1), it’s time to go back to DevOps and application delivery.
Modeling application delivery with electric circuits?!
Why not? Application delivery is a system, so it should be possible to model it as an electric circuit. The system’s output is the value that you are serving to your customers, or in other words — what they get from your application. If you operate in a competitive market, you are probably trying to find ways to make this system perform better, and give customers more value, faster.
Besides, doing multi-disciplinary stuff is as much fun as it is useful.
Let’s get to work. What electric circuit does this look like to you?
This is your application delivery system. At least this is how it is often viewed today. This depiction of application delivery, also known as The DevOps Toolchain, sort of gives the electric circuit model away, doesn’t it?
It mostly resembles a series circuit. The different stages of application delivery are equivalent to resistors in series:
The DevOps toolchain concept is rooted in the notion that application delivery is broken down into a sequence of stages, or tasks (planning, development, testing, deployment to production), that need to happen in a certain order so the customer can get a product.
And this is indeed how it traditionally goes — you think about the product, design a minimum viable product, code, test and ship to your customers. And while the customers start giving you feedback about your great new product, you go back to thinking of more capabilities and so on.
A side note — some people also call this a Value Stream
I like this term because it makes you think of the value created and delivered through your application as a fluid that flows in the system. Fluids and electrical current have a lot in common. Not surprisingly, using electric circuits to model systems in fluid dynamics is also very common.
Increasing the speed of a DevOps Toolchain
If the application delivery is a series circuit, loading more tasks and tools to the DevOps toolchain is like adding light bulbs to a series circuit: the more you add, the current goes down and the bulbs become dimmer.
Looking at your application delivery as a series circuit makes it quite clear what you need to do in order to get the flow to value (i.e. current) faster: you need to reduce the resistance.
It also makes it clear how you should measure the resistance of your system. You measure factors like ‘the time it takes to complete each stage’, ‘how much time it takes to move from stage to stage’, ‘how much time it takes to complete an entire cycle’ etc.
How do you reduce resistance? Automation is surely one answer. If you automate the stages and the hand-offs between the stages, the flow to value would be faster.
A tempting way to improve the performance is to eliminate any resistance that may be removed without immediate consequences. Especially if the mere thought of automating it makes you a bit dizzy. Did anyone say testing was dead? What about security?
Scaling application delivery
This may be why the Devops toolchain concept seems very applicable for simple stuff, but when you try to adopt it in real life applications, the ones that handle your money and your health and your airplane’s auto-pilot.. well, let’s just say it’s not that obvious.
The series approach works — but it’s hard to scale it. No matter how fast you get each stage to be, each stage must wait for the previous stage to finish in order to start.
There may be a better way to model this system.
Read more in part 3.
Part 2 of 3| go to Part 1|go to Part 3
