The Case for Components
Easier for humans and computers
If you are a seasoned developer and are quite familiar with components, then you are probably better served spending your time elsewhere. You are already aware of how prevalent they are in just about all technologies and programming languages, and the plethora of reasons why using them just makes sense.
However, if you are newer to programming let me introduce you to the greatest thing since sliced bread, components.
Components can be thought of in a similar way to functions, in that they are reusable (ideally) pieces of code that serve a specific purpose. Some common components that are used when designing applications can include views, models, controllers, or even different cloud services that serve a specific purpose, that are part of a larger architecture.
To help you better visualize what a component is, you can think of them as chapters in a book. Imagine you had a large book on how to build a computer from scratch. I want you to visualize how impossible and ridiculous it would be to comb through that book if it had no chapters, but instead was just a continuous series of thousands of words and paragraphs. How would you go back and review previous steps, or even preview what is to come so you can adequately prepare yourself?
Now imagine this same book was instead split into chapters, and each chapter contained a clearly defined step in the process to build your computer? For example you could have a chapter on pros and cons of each operating system and hardware types, where to get your hardware, how to assemble each piece, how to run tests at each stage, maybe even a chapter on troubleshooting common problems. Do you see how much easier that would be, and how it would allow you to build a computer exponentially faster?
This is the same concept as an application split into different components, as opposed to a huge monolithic application that is just one giant piece. Analogies aside, here are some reasons why you need to consider using components:
Your applications will be easier to troubleshoot
If you have your applications broken down into components that each perform a specific job, when (not if, when) problems arise it is much easier to know where to look to remediate the issue quickly. For example if part of your application sends out emails for successful user registrations, password reset requests, etc. and all of a sudden users report not receiving emails, then you would know to first start looking at the component/service of your application that acts as a mail server.
Or maybe you have a data analytics platform that allows users to run queries over a database you have provisioned. One day users start complaining that their results are being returned much slower than normal. You decide to look at the log files for the queries they are running (logging likely being its own component/service) and see that the select statements are taking an unusual amount of time. Knowing that the select portion of a SQL query takes place on the server, you could go out to your database service and perhaps see if it is experiencing some latency issues, or if it is malforming queries, etc. However if you just had one huge codebase with all of your services running on top of each other, it could be that your databases are underperforming due to another service that it directly relies on. This leads me to my next reason why components are so beneficial:
Your applications will have less dependencies
To refer back to our book analogy earlier, imagine if you had that same book on how to build a computer and it was a thousand pages with no chapters, just continuous words and paragraphs.
If somehow pages 400–500 go missing, there is a high likely hood you are not going to be able to properly build the computer you want! This is because your book is dependent on all pages always being where they should be.
The same concept can be applied to your applications. If you have separate services for databases, networking, security, computing, and storage, then in the event of failures or attacks it will be substantially easier to see what specifically was affected and concentrate your time and resources on repairing that area. However if you have one massive compute instance that runs all of those areas, if something were to happen to that instance your entire application would be toast. Finito. So it is important to understand that by separating your application into components, where each component has a specific job, you can more easily deal with outages, upgrades, service interruptions etc. Finally, lets talk about the last and potentially most important reason why you need to utilize components:
Your applications are easier for humans to understand
It is a part of life that employees and team members will come and go. A valuable, sustainable business overtime will either lose or add people, and you need your current team members to have the best chance at understanding your code base or architecture so that they can quickly adapt to your tech stack and begin either innovating or problem solving.
Again, if you have only a couple files each with thousands of lines of code, good luck trying to troubleshoot that or add/remove things without breaking something else. That’s likely to be impossible.
On the other hand if you have separate services for networking, computing, storage, etc. like I mentioned above, not only is it easier to make changes to each area without breaking everything else, but you can have employees who specialize in one area work only on that, and not have to spend a bunch of time learning new concepts or technologies they are familiar with. The less time your team spends trying to figure things out, means they have more time to innovate and push your business to new heights and increase value.
I hope this was helpful to you in helping you understand how to better structure your applications and architecture. Of course, large applications could potentially have a plethora of services or components it utilizes so conceptually understanding it is only the beginning. I would encourage you to check out something like the AWS series “That’s my architecture”, where you can see videos that are no longer than 5 minutes or so from companies of various sizes and niches break down the different components and services they use to optimize what they are doing and deliver the most value.
As always, best of luck on your journey of cloud computing.
