3 Primary Considerations for Choosing an IT Architecture
The modern world offers a dizzying array of options for choosing IT architecture. You can select open-source vs. proprietary, cloud vs. on-premises, RDBMS vs. NoSQL, IaaS vs. PaaS, Ruby on Rails vs. Node.js, Apache vs. Nginx, iOS vs. Android, AWS vs. Azure, and so on. You can often mix and match such possibilities in any ways that help you achieve your goals.
Given so many choices, where should you begin when choosing an IT architecture? We will look at the three primary considerations that will get you started.
- Recognize the Benefits of the Cutting-Edge
One of the most engaging parts of software development is bringing things into fruition with bleeding-edge technologies. This is because of the inherent challenge and novelty of them – it is much like being an inventor in an age of discovery. Developers that are engaged while solving your problems are more likely to deliver quality than those who view them as drudgery.
Such technologies have another practical advantage; they represent progress. There is a good reason why so many new languages, frameworks, protocols, deployment platforms, and devices keep popping up at what seems to be an exponential rate – they address the common issues that have plagued the software world for years and the ones that we will have to control in order to move into the future. Cases in point are the ubiquity of memory-managed languages, which among many other things virtually eliminate the “buffer overflow” vulnerability nested in so many C/C++ programs, and the introduction of lambdas/functional features into languages like Java that sorely need them.
- However, Balance Novelty with Business Sense
Newer technologies bring clear advantages in terms of flexibility, long-term costs, and future-proofing. However, we need to balance our zeal for novelty with the reality of day-to-day business. There is no getting around the fact that even the most elegant software architectures can be expensive to design, deploy, and perhaps most of all test. It is also difficult to ensure that they will faithfully execute the business logic of legacy systems.
Companies such as Netflix build their solutions with microservices, Node.js, Kafka, Cassandra, and many other fairly recent innovations since they have to deal with unbelievable demand and competition. For such companies it is a requirement to stay on the cutting edge or die. Depending on the size of your business, your needs may be much more straightforward. A simpler architecture with dependable and proven technologies that plays nicely with your existing systems will often allow you to get the job done with minimal fuss and expenditure.
- Know When to Scale Vertically vs. Horizontally
Speaking of simplicity, minimalism, and time to market, you will often find that this goes hand in hand with vertical scaling. Vertical scaling is the practice of making improvements to the capacity of a primary solution (think adding RAM/CPU power to a server) in order to accommodate higher load and a wider reach. Horizontal scaling, on the other hand, involves parallelizing resources (e.g. expanding out to a cluster of servers) in order to achieve the same goal.
Vertical scaling encourages elegance by:
- Allowing you to develop and prove your architecture within a well-encapsulated deployment,
- Create a working baseline of code that serves as the foundation for all of your future solutions,
- Focus on scale through relatively simple factors; spreading out the resources of an architecture has always been among the hardest problems in computer engineering.
This of course does not mean that horizontal scaling cannot also encourage simplicity in many cases, nor that it is mutually exclusive with vertical scaling. There generally comes a point where you can no longer only scale upwards.
The main take-away here is that you should plan a model that can scale vertically in order to get a viable solution into the world while also making allowances for how you will scale out horizontally when the need arises. Starting out with the horizontal mindset will probably lead to some intriguing problems and research, but it will often work against the goal of delivering on time and budget.