My first program was a PRG file with BASIC code, stored in a magnetic cassette. Using a datasette, the program was load into RAM and executed by the C64’s CPU.
Fast forward to today, once you have a working code, just hook your repository with any continuous integration tool, push it, and you are up and running.
The components remain the same: you have a code, you need storage to save it, and you need hardware to run it.
Not understanding this process is why many engineers confuse architecture with infrastructure. They overlook the integration design between the two of them.
Microservices are not the same as containers. Serverless is not the same as lambda functions. Take a minute to read AWS recommendations on how to deploy microservices; they propose two paths: lambda or containers. Lambda is serverless by design, containers can be serverless.
Infrastructure is all hardware-related (even if it is virtualized). It is where you store and run your code. Architecture is how you structure your code. Back in the 80s (and even late 90s), it was around how you organized the code into files.
Why would you care about how you structure your code? Because the codebase will be so big at some point that you wouldn’t remember where things were. And if you need to add new engineers to the project, they wouldn’t know where to start.
Architecture is a communication tool for humans, for organizing the code. Infrastructure is for machines.
The most productive engineer I’ve met used to write large PHP files. Not a bad thing, especially if it generates $2k per day. Horrible thing if you want help (or respect) from other engineers.
- Challenges in Implementing Federated Learning in Ad Tech - 10/09/24
- Graph Neural Networks for RTB Systems - 10/02/24
- Measuring Emotional Impact in Local Campaigns - 09/25/24