top of page

Why Did We Migrate to AWS Cloud Platform?

I mentioned shortly reason for migration to AWS Cloud Platform in my previous post. Now I want to explain the reasons in detail.

The idea of migration to AWS started with a search better alternative than the current structure which we had a lot of problems and challenges.

In phase 1(rest of post I will define as ph1), our project’s backend was developed with spring boot and java as microservice architecture but to be honest, that was more like monolith architecture. The mobile app was developed on android in the first. When I started to work, the project’s ph1 was almost finished. And last bugs were fixing to move prod. For checking out I got the latest code to my local and installed the app on my phone. After getting the code and app, I have noticed that there are problems in both code and app -then I saw our team also realized of existing that problems-. Some problems which we saw are as follows;

Application performance: After installing the app on my phone, the first thing I realized was app performance which was very bad. Sometimes I waited for tens of seconds for just one process. To be honest, I was a little shocked. Why was our performance so slow even though it’s not a huge app. Something seemed wrong and we needed to find that to change it. I talked about performance with my friends and they were also aware of this situation and they said that will do some radical changes in the second phase of the project. To be honest I was very relaxed after hearing. Because the performance needed to be improved.

To improve application performance, we first had to reduce code complexity. Lambda functions that AWS offers for services would significantly reduce our code complexity.Both the runtime rendering on the application side and the structure used on the backend had a serious negative impact on application performance. We also realized that MySQL did not fully meet our needs. Instead, we had to find a better alternative. For this, using a NoSql database instead of a relational database would have helped us a lot to improve our performance. We used it because NoSQL’s key-value logic is more flexible and very good at exchanging real-time data. Besides, the fact that we don’t need transactionality was another reason why we switched to nosql. of AWS DynamoDB; We have seen that it is a good solution alternative for NoSQL database.

Monolithic Architecture: The last tests were doing in our project before making prod. During the test, we were finding some bugs. Because of the complexity of our code fixing those bugs were taking a serious time. The application actually looked like a microservice architecture, but since the structure wasn’t fully seated, it started to look more like a monolithic architecture. This was causing it to be hard to understand. Also fixing the bug always had the risk to collapse the whole application. That is why we needed to find a better alternative than the current. Our structure had to be modular and independent parts.

This complex structure was increasing our maintenance cost day by day. Also that was affecting on application performance very negatively. Instead of that we constructed more modular structure thanks to api’s. We developed our CRUD services with AWS lambda functions. And these were significant decreased our code complexity. Using AWS lambda provided us to less code, more modularity and more managment.

Redundancy of Features: There were lots of features in ph1. But really lots of them were not necessary for at the first. Because of that redundancy, both the project delayed to make prod and increased complexity. And this had a negative impact both on performance and effectiveness.

We decided to change our strategy and we divided it into MVPs. This provided us to simplicity and more efficiency. Surely, that was positive impact on our development speed. Also there was no need to make any effort for some features that will never be used.

Distribute Structure: The project was existing different sides which are mobile, backend and NLP&AI. So, the requirement of external libraries and extensions were very much. Both the requirement lots of libraries and extensions and integration with each other; these became a serious problem to manage and to monitor. We needed to monitor our application at a single point for 7/24.

AWS has made our job very easy with its compatibility with all third party applications we needed.

Log & Monitoring: We had not have constructed a holistic log and monitoring strategy yet. We were writing incoming logs only to DB. We have not done anything for monitoring or tracing. Especially when occurring problems it was hard to track and monitor. So, It was vital to log the whole application from start to end for tracking and create a real-time alert in error cases. It was also important to know application health checks for other situations.

At the first, we’ve created a centralized log strategy for this. We provided that both android, backend and nlp side to log with the same logic and structure. Thus, we could track whole application’s all process from start to end. We developed a AWS lambda function for logging. For tracing logs we’ve used CloudWatch service. Also, we’ve created queue structure with AWS SQS to prevent losing logs data. For realtime monitoring and analyze we’ve used AWS Opensearch service.

Auth: In ph1 for authentication and authorization we’ve used external microservices developed in Plato. These microservices were developed by a different team and we could access them via APIs only. While we’ve developed ph1 we needed to change something at those services. But, It was not very easy to change it. Because the service was managed by a different team and they did not seem willing to give us auth to change it. Also, this was increasing development costs. We had to find a better alternative to this.

AWS Cognito solution was very help us for this. We’ve integrated to our project quickly and we’ve provide to users signin with google account at the begining. For next logins Cognito gived us to check users had auth or not. This became easier to manage also.

The problems and challenges which we encountered and also our solutions for were these.

For the quick shot, I would like to express below the AWS solutions we have implemented for the challenges we face;

Application performance: AWS Lambda and AWS DynamoDB

Monolithic Structure: AWS Lambda Functions and AWS ApiGW

Auth: AWS Cognito

Log&Monitoring: CloudWatch, OpenSearch

Surely, We’ve had other reasons to choose AWS.

1- AWS has lots of services and solutions for all requirements that you need it. Of course for our requirement, we found all solutions on AWS. AWS seemed one step ahead in functionality.

2- Being the leader of cloud platforms in the world.

3- In our team, our friends had AWS know-how. This gave us the opportunity to learn much faster.

4- AWS Cloud Development Kit(CDK) solution to define your cloud application resources using familiar programming languages. For learning details, you can click the link.

5- AWS SDK solution to make it easy to call AWS services using JavaScript APIs to build Node.js, web, and mobile web applications. For details, you can click the link.

6- AWS AppSync solution to make it easy to develop GrahpQL APIs. For details, you can click the link.

7- AWS Amplify solution to develop mobile and web applications faster. For details, you can click the link.

Finally, AWS serverless structure made our job easier very much. We did not need to think about server’s management, maintenance and scalability etc. AWS is doing this for us. Reducing this cost is very important for Ventures like us and Startups.

Thank you for your reading patience. I hope this post would help.

See you at the next post…

İbrahim Halil Ateş

Senior Software Engineer

Group 7.png
bottom of page