We are coding, Crop is growing. Engineering@Fasal

[Cross Post from Authors Medium Post]

 

I am an engineer at heart. I think and I code and more importantly, I make a lot of trade-off decisions. Fasal is a 6 member team today, and though we are doing multiple jobs, 6 out of 6 are engineers first and we are proud of that.

Our team and even our investors can see the sparkle on my face when I talk about engineering. Our co-founder Shailendra would definitely agree with this. Because I see him sparkle when he talks about building a product. Both of us now talk more about investment, strategy and core components but deep down we both love to engineer and build the product.

Fasal in all sense has a very strong foundation, be it a product foundation or technological foundation. I am here to talk more about technical stuff.

When we started Fasal, we had few things in our minds which we wanted to achieve —

  1. Small and high performance team
  2. Self driven and motivated team
  3. De-coupled and Cohesive system design
  4. Single codebase for all platforms
  5. We can be DevOps
  6. We can be QA
  7. Zero downtime, rolling upgrade, and auto-scale
  8. No one wants to wait for next app release, so hot code push for apps but no crashes, please!
  9. Self-log, self-monitor, self-heal
  10. Piece of mind

Before going deep into each point mentioned above, let me discuss a few various systems at Fasal. Core to its Fasal is an and . We have -

  • A node which connects with an array of sensors records data every configured interval, creates a data frame and pushes it to Fasal backend server on a 4G/3G/GPRS network. The node is solar powered, supports deep sleep mode and can be programmed over the air (OTA).
  • A linearly scalable container based IoT backend server, always available. Processes the data frame and stores it to Fasal highly available and replicated storage servers.
  • An app backend and frontend. Single codebase for web app and all mobile apps. App backend talks to Fasal storage server to pull data and runs algorithms. App frontend presents data to users on Web, iOS and Android.
  • AI engine which periodically loads data from n different sources, trains the ML algorithms, deploys the model and gives an endpoint for prediction.

The interesting bit is — all the above is developed and managed by 2 and a half engineers at Fasal and you will hardly see us working on weekends. I am the half engineer here :).

We always want to remain a small and high-performance team. And saying that doesn’t mean that we want to work late in the night or call engineers in the midnight to troubleshoot customer issues. We strictly want to balance work-life. We have actually achieved that and we will keep following that practice always. Fasal is built in a way that it never goes down or till date, it has not went down. I will share some stats for this claim.

Our IoT backend server is written in Java using SpringBoot and deployed on AWS Fargate using Containers. Under high load, it auto-scales and balances the incoming traffic in a rolling fashion without losing a single request. If a running instance is about to crash it launches another instance in no time and re-directs all the traffic to the new node. When we deploy a new version, it performs a rolling upgrade by first moving all the traffic to the new version, doing all the checks and bringing down the old nodes.

Last time we had deployed our IoT backend was sometime in Feb 2018. Never looked back or got any midnight alerts. It auto-heals itself whenever needed without bothering us.

Last deployed on 22nd Feb 2018

At times load is really high

Look Ma! it auto-heals itself

We always want our team members to be self-driven and self-motivated. Our brilliant engineers Dhaval and Shivang work on their own. I and my co-founder are mostly busy talking to investors and partners these days, and hardly get time to sit in office but that doesn’t stop our engineering pace. Dhaval and Shivang have taken that responsibility they do planning and execution by themselves and we push code daily and make least 3–4 releases every week.

When you design a system which is de-coupled, you have a greater flexibility to make a change in small parts without affecting others but it also opens more chances of bugs, more connection points and also the management overhead. We at Fasal have taken a strategic step in building all our systems to be de-coupled and highly cohesive but leave less open points for issues and management. Our app server is written completely in Node.js and Meteorframework. We have extensively used Meteor DDP for pushing real-time updates to our apps which also make our app more responsive in nature.

Node.js and Meteor have provided us with a great language and framework combination where a single code base has allowed us to build our web app, iOS, and Android app on a single day without any hassle. We are the fan of containers and our app server is also deployed in containers in the same fashion as our IoT backend server which just takes care of itself without bothering us at all. Again never went down from the time it is live.

As I told you earlier, we do 3–4 releases a week which goes to production instantly and also to all our customers without them updating their app. We don’t even publish a new app. We publish app once in a month or even longer. Seems real magic and the best part in our deployment process. It’s called hot code push. Another brilliant feature by Meteor which allows you to push new code to all the apps in a blink without end-user noticing it. And you may ask why we do that and why it is extremely important for us? Because we deal with the customer (farmers) located at remote places with slow internet connectivity. We want to deliver new features but updating the app every-time is not gonna work. So we decided to do hot code push. Happy customers!

193 releases in last 6 months

Managing web app, Android and iOS looks very challenging. You have to take care of versioning, , crashes. Fortunately, Fasal has not crashed yet, not on a single device in the last 6 months. I am very of proud of that. And we don’t want to crash ever. That’s a big commitment but we are all in to make sure it doesn’t happen.

Jan 1st 2018 to July 27th 2018. No Crashes!

No ANRs or Crashes in last 60 days

Crop is growing, We are coding

That is all we have done in the last 6 months. Two and a half engineers and an awesome team. We are also committed to giving back to Open Source and you can see some of our current work under our Git Repo. This is just a start. There are many more things we want to open source and we will do it as we move forward and with the commitment to manage it always.

Our recent contribution includes a Mongo backed API rate limiter which Dhaval has been working for some time now. It was a demanding feature request from many in the community. He has finally filed a PR yesterday and it is live now. We have used it in Fasal and it works really good.

Another upcoming PR is from Shivang. He has modified Cordova to supports actions in the mobile notification. We will be pushing it very soon. He is still documenting it.

We are also opening our APIs. Right now for internal partners who are building excellent service for farmers. We have already opened few and that is where Dhaval has created a Mongo backed API rate limiter on express.

From the first day, we had decided to be a software company, focused on AI and predictions. But is an integral part of our solution and most of our competitors are building really cool IoT devices for agriculture. We see them as our collaborators in the future. But to adhere to the market demand we have also started assembling and building our own hardware. Our sole aim is to make hardware a commodity so a larger farming community can be benefitted with Fasal solution.

We are very soon publishing out our first research paper on Micro-Climate prediction. I am trying to buy some time from my regular work to focus on writing it. We are also hiring actively for AI engineers and Plant Pathologist. Do send your CV to connect@wolkus.com.

Leave a Reply