Phases of Teknasyon’s architecture evolution process
Teknasyon is a fast-growing tech company. As of the beginning of this year, our employee number has been increased by one hundred. Our current population reached to more than three hundreds. Although mainly Turkish people work in the company, recently many people from different nationalities joined us. Today, people from Iran to Russia working with us.
It might be a guide for people who would like to know more about the IT team of Teknasyon, “ What technical methods we use, what kind of projects we work on etc.” on the other hand, I will be following our progress in the next coming years and will have a snapshot of our current development.
This article is going to consist of a series of articles. Today, I am going to mention the first topic then walk through the following steps in the future.
- Phases of our architecture evolution process
- What kind of project are we working on?
- Organization
- Project management
- Software development life cycle
Before going any further, it is good to mention Teknasyon IT that consists of different groups. One of them is Samcro(Teknasyon Software) that is in charge of developing and maintaining B2C, B2B, and also internal projects. Except for Samcro, there are two other groups called GTC and Rockads. I am going to only mention about Samcro that I am part of.
Phases of our A.E process
As Teknasyon, our focus was generally B2C projects a few years ago. Our main challenge was developing and maintaining many apps at the same time.
Phase 1 — Boilerplate
Developing many custom apps at the same time isn’t reasonable, it brings many issues. One of challenges is developing the same functions over and over again for different projects. Since there is no common code-base, all functions have to be written repeatedly on different projects. To solve this problem, we decided to prepare a boilerplate that includes iOS, Android, and Backend versions. The idea was that when starting a project on top of it, it would have brought many required functions without spending time to develop.
Phase 2 — Framework
Having some functions provided by the boilerplate at the beginning of a project was nice but it wasn’t enough. The main problem was maintenance effort. With each project, the maintenance effort had increased. Even if we developed any new feature on the boilerplate, it couldn’t be implemented easily into projects. Only at the beginning of the project code can be implemented without extra effort otherwise special effort needs to be given to merge. Thus we decided to develop a framework called “Ares”. The idea was to develop a framework is solving common problems on it and put it on the projects as a base layer. If we solved any problem on the framework, only an Ares SDK version update would be enough to get the related update.
All responsibilities were divided into separated layers like the framework layer or app layer. Plus, the internal structure of the framework was designed to include different layers. We didn’t need to spend any project-specific effort to merge codes anymore. Just we needed to update Ares SDK with a new version.
Although this had decreased our maintenance effort seriously, updating all apps had been still a matter. When we determined and solved any issue on the framework, we had to update all projects separately. It was still a big problem.
Phase 3— Microservices
Microservices create different types of complexity than monolithic applications for development teams and up-front costs may be higher with microservices. Therefore projects of Startups often come to the world as monolithic. Many responsibilities are given to the same code-base. We did the same thing as expected. All features were put into Ares framework such as subscription management, campaign management, customer engagement system, etc. Managing these all solutions on top of one framework obviously required many framework updates.
If the project tries to handle many requirements on only one code-base, the project naturally gets divided into services with different responsibilities. Over time, we had created many micro-services and assigned different responsibilities to them.
Phase 4 — Event-driven Architecture
Microservices oriented architecture had decreased our maintenance effort. No longer we had to update or develop mobile backends. Apps that used the services could directly have an access to updates.
Microservices work well with agile development processes and satisfy the increasing need for a more fluid flow of information.They are independently deployable and allow for more team autonomy. Therefore we had created teams that were responsible of developing microservices. Apart from these, using microservices brought us many benefits.
As the number of microservices increased, so did the integration needs between services. Not only our services but also 3.party services we used that brought us complexity for maintenance of integrations between them.
We had decided to move our architecture to event-driven model so that we could solve the complexity problem. All services would have a connection to a hub service and if they wanted to send a message to one other, they could send a message through the hub service. The services needed only one connection to send message to each other thanks to the hub service, no more had needed connections between each other.
Phase 5 — Big Data
Requests, responses, logs, events, all were converted countable numbers thanks to event-based structure. That brought us many benefits.
At first, we had needed a platform to store millions of events. We started to look for a platform to store all data and considered different big data solutions of many providers in terms of performance, pricing, query ability etc. Some of them were tested. Eventually, we decided to develop our own platform and gave it “Athena” name.
We achieved to develop a comprehensive platform that was able to handle millions of event traffic in a day. After this, we could watch events between services from a bird’s eye view. Bottlenecks, inadequacies, anomalies could be seen by that way.
Although we had thousands of alarm metrics that are set on our cloud providers, anomalies that were on the application layer couldn’t be found out. Detecting anomalies on the app level requires app level control not server level. So our first application running on our Big Data system became the anomaly detection system.
As a result of an intense effort, we took place our anomaly detection service. Today we are able to follow more than 2000 metrics thanks to our anomaly detection system that name called “PAN”.
Time will show us what the next phase will be. After these steps, we have reached our current structure. All phases took time to occur and are derived from our needs. At this point, we have productised our services and opened them to external users as B2B solutions. Our current challenge is productisation. We are learning more and more every day and trying to have different perspectives on product development…
Is there a phase we missed or what do you think our next step will be?
Feel free to leave a comment, dm me on Twitter or LinkedIn. I writes about tech at twitter.
