In some cases, selecting the technology is just a matter of heritage or of what devs are used to. Some other times, our determination is based on a new trending technology that we might want to try out or get experience in. We may even need to create a PoC (proof of concept) to try a technology or more than one. But what should we really contemplate when it comes to choosing the right technology stack?
Selecting based on a couple of features we are a fan of, is like choosing a car based only on its color. It will keep us from assessing several aspects that will end up affecting the development process and the product’s outcome itself.
Is this a matter of life or death? Can’t we change the technology after? Are our choice and its impact going to last forever? Let’s see.
The implications of selecting the wrong technology stack
We should always consider how much time and effort future changes could require. How? These are some aspects that should be of our concern:
- Depending on how foundational your technology stack is, the decision can be more or less binding. If you choose Java for your backend, then it will be hard to change it after, as that will impact every line of code you write.
- Getting an API gateway or an Enterprise Service Bus up to speed and productive is not without a huge effort and may involve high licensing costs. Future changes will be expensive so it’s important to make this decision carefully.
- Selecting an authentication server/service that uses the OAuth protocol may not be as compromising, even when this is a cross-cutting concern and it will have a big impact on the solution. Changing the selected provider in the future should not be difficult. As far as we keep “talking OAuth + JWT” without modifications, nobody should notice the change.
Now that we know the possible consequences of selecting the wrong stack or just making our minds later, what is there to consider to make sure we make the best possible decision?
4 constraints to consider when selecting your tech stack and what projects could I apply machine learning?
Keep in mind that there are some other context-related aspects of your business and the product itself you’re trying to build and we are leaving that on your side. But there are a few things that are common to every company and development and that you should take into account when choosing your technology stack, and those are what we can name as constraints, the conditions that restrict our ability to choose from the complete universe of technologies. Let’s dig deeper:
- Partners: Sometimes the company has a partnership with a provider that forces you in that technology.
- Legal: There may be legal implications when you decide to use one technology or another. For example, if you want to provide a cloud solution to store medical records you can't choose any cloud provider. Usually, medical records are required to reside within the country so you need a provider that has data centers in each country that you will be working with, in case they have that legal regulation.
- Compatibility: No one will choose a technology that doesn’t work on the server OS or platform, neither we will select a technology that is not compatible with the device the product is expected to display on. For example, we are restricted to Java or Kotlin if we want to build for native Android. Yes, cross-platform technologies like Flutter also work, but you get the point.
- Feasibility: Even if this sounds ridiculous, the technology that we are considering should solve the problem we are working towards solving. It must have the features we are looking for and it should be possible to integrate with the rest of our tech stack. For example: is there a Kafka client (SDK) for the technology that I want to use? Does that support all the Kafka features that my solution uses?
Acknowledging the Software Quality attributes
If we search online, we can find an unlimited listing of software quality attributes, although the more commonly considered ones aren’t a lot. The more important traits will vary, depending on the solution you want to create. But here’s our selection:
- Performance: Will the technology meet the performance requirements for the solutions? AWS SNS may be good solution to handle a basic event sourcing architecture and integrating different modules, but it won't be fast enough if we expect to use those events to handle a microservices choreography.
- Scalability: Will the technology be able to accompany the growth of the solution as it gets more users and more data to manage? Cloud solutions' appearance had a huge impact on this consideration. Now it is much easier to get scalability out of the cloud.
- Maintainability: This aspect is critical, as it gets affected by the other attributes. For example, distributed solutions are usually more scalable but also more complex to maintain. Using low-level coding languages is usually more performant but this kind of coding has a higher level of complexity and therefore becomes also harder to maintain. If there are no specific or clear requirements that point to other quality attributes, this is the one that should be favored.
- Security: Security will be more critical for a banking, even if it means sacrificing maintainability up to some point. But every type of solution should have this aspect into consideration, as you will always need to look after your client's data and privacy. Questions that you should ask here:
- Is the platform, provider, service, or API that you are using secure enough?
- How can you guarantee security? Can the vendor provide proper certifications? - Availability: Even if %99.999 availability is not what everyone needs, this is also relevant to some level. Plains have all their systems duplicated because surely you don’t want to be in the air and find that something is not working. Systems that do offline processing probably don’t need to be up all the time as no one is standing there waiting for the outcome, anyway they should do their work at some point. Consider that every component in the stack will contribute to the general availability, keep this in mind: “A Chain is As Strong As The Weakest Link”.
These are some key points that contribute to the system stability:
- Robustness (what happens when we have an issue?)
- How fast can we restart?
- Ability to create redundant services and locate those services in separate
servers/locations/geographic regions.
A characteristic of the technology that will affect many of the aspects we’ve mentioned before, is how mature it is. Are we using something experimental or beta that just got released or is it something proved by the industry? Can it count on a supporting community?
Not just what, but who?
Alright, we are ready then! But have you thought about the people? The first thing to consider, besides the tech stack itself, is your team. The level of expertise, the diversity, the number of people, are all key factors that you shouldn’t forget. They are the wheels of your product car. But let’s leave that for our next chapter, in which we’ll also talk about market adoption and learning curves.
This blog post was developed in collaboration with Gaby Kotliar - Truelogic CTO
