From code to infrastructure
It’s easier to change code than infrastructure, so we should prioritize code over infrastructure. I have the feeling that people nowadays…
It’s easier to change code than infrastructure, so we should prioritize code over infrastructure.
I have the feeling that people nowadays think it is better to favor infrastructure.
Infrastructure is the foundation or framework that supports a system or organization. In computing, IT infrastructure is composed of physical and virtual resources that support the flow, storage, processing and analysis of data. Infrastructure might be centralized within a data center, or it might be decentralized and spread across several data centers that are either controlled by the organization or by a third party, such as a colocation facility or cloud provider.
https://www.techtarget.com/searchdatacenter/definition/infrastructure
Infrastructure in the last one or two decades have felt an explosion.
We have now great platforms, tools that help us a lot with infrastructure, that they have had a huge impact in how we now solve problems in software simplifying things, sometimes.
AWS, Azure, Kubernetes, Docker, Terraform have made infrastructure easier and easier to change, as software is. Infrastructure as code is a great example of a paradigm that tries to move infrastructure to the field of software, something easier to change.
But even so, infrastructure is not as easy to change as code. There are many certifications related to cloud computing services, and many of them feed off the concept of “solutions architect.”
I’m writing this because I have the feeling that people are too much focus on how to solve a problem with the Legos that for example AWS is providing, without even thinking on how can be their problem easier to solve just writing some lines of code and evolving it based on feedback of production.
I think this is part of some main problems in architecture we have right now:
Too much upfront design
Being afraid of evolving a solution
Design solutions per problem without taking into account the current domain/context
Evolving architecture is just easier if the things you have to change are in code, more difficult if you have to change a database, or if you need to change decisions about the networks you created because of a possible problem you never know if it is going to happen.
If we move too many things to infrastructure, we are making those decisions harder to change. Why don’t we use with infrastructure the idea of use “The Simplest Thing That Could Possibly Work”?
Why not taking decisions based on that, on the easier thing to change instead of the perfect solution to solve all the problems at once?.
Some upfront design could be fine, but just the minimum one, just when we really realize we need that infrastructure.
To execute some actions when an event happens in the system from time to time, we don’t need a SQS, SNS, Kinesis and an event bridge, we can just create an interface a new module apart from the rest of application and execute the thing that we need to execute, even if that’s against any paradigm you have probably invented.
Try with that, and if the problem makes more complicated and really needs to move the code to another part and make everything distributed, think on the minimum infrastructure required to solve it.
Do you know why you always go for infrastructure?
Because you think is your job as an architect, don’t accept to be classified as a box painter.
Because you think the organization is not ready to iterate solutions.
Because your team doesn’t have metrics about how effectively has been the solution in place and what problems are coming.
All of this is related to decisions, why, when and what decisions to take.
If you can solve a problem through some lines of code inside your current application, do it as first (make it work). Then design your code as if you need to move it outside that place and put in place some fitness functions to understand when the solution will not be enough.
Make your team to understand what is technical debt and how to manage it effectively.
Don’t try to solve everything with the Lego that your cloud provider gives you, at some point you will need to change, and it will be harder, just because you spread all the logic around because of your infrastructure.