What mobile can teach embedded about concurrency for the IoT
July 01, 2015
Concurrency means different things to different industries, and in this Q&A with Rick Chen, CTO of live video streaming app Hang w/, he discusses what...
Concurrency means different things to different industries, and in this Q&A with Rick Chen, CTO of live video streaming app Hang w/, he discusses what concurrency means to mobile, need-to-knows for database management, and how mobile apps will eventually touch every aspect of the Internet of Things (IoT).
For a long time there has been a dividing line between ‘mobile’ or ‘consumer’ and ‘embedded,’ but that’s changing with the Internet of Things (IoT). That said, give me your definition of concurrency, from a mobile perspective.
CHEN: Concurrency from my perspective as a mobile server architect is the number of concurrent users who are hitting the servers at the same time. Essentially, it boils down to the number of request per second. Then we use that information to figure out or predict the peak load on the servers. It’s usually bottle necking at the database layer, so database reads and writes per second is usually what comes to mind when I hear the word concurrency.
As a designer of mobile games/social apps, how do you approach concurrency challenges on a day-to-day basis, and how is that similar and/or different from the way “high concurrency” should be dealt with in an embedded/IoT environment?
CHEN: Knowing your audience’s behavior and anticipating traffic spikes are keys. The most successful mobile games and social apps are “freemium.” Since they’re free, the barrier to installing is usually very low, but so is uninstalling. Virality, big marketing pushes, getting featured, and massive events within your app are a few examples that can drive a high concurrency to our app.
The similarity with embedded environments is we’d like to squeeze out the maximum performance out of a server. The difference is we aren’t really constraint by the hardware thanks to cloud computing, which allows us to almost infinite amount of servers as long as we architect the app to scale horizontally.
So, given the fact that your major bottlenecks are in database performance, what do you prescribe for developers? Is there a certain type of database (SQL, for example) that you find is more effective, and/or what efforts do you make on the development side to help improve the performance of your app in the face of database constraints?
CHEN: Knowing what you’re building will determine how you would architect your database. After figuring out what’s important, then you choose the database(s). If you’re building an app that has millions of users, most likely you will need more than one database. There is not one database that fits all of your needs at this scale. With a slew of new databases on the market, it can be a daunting task to select which to choose. NoSQL has been around for a while to tackle what relational databases couldn’t do – horizontal scaling, availability, and partial tolerance. On the bonus side, they’re all very easy to scale up and down, so you can align your server cost with how successful your application is.
Understanding each of the database’s strengths and weaknesses is important to make the decision. Consistency, availability, and partition tolerance (CAP) theorem helps grouping these databases into three buckets: CA (consistency and ability), CP (consistency and partition tolerance), and AP (availability and partition tolerance). Once you know which bucket best suits your needs, it’s back to the regular due diligence of cost, maturity of the software, community support, and case studies.
Are there tools or methods you can prescribe for app developers operating in “high concurrency” environments? How do you tackle the scalability question, from low volume to mass market?
CHEN: Profiling (each operating system has their own profile), analytics, and error reporting for production is important, so Crittercism, BugSense (now Splunk), and Bugzilla are a few tools available for developers on the client side.
For server environments similar the challenges are similar – so load testing, profiling, analytics, and monitoring – and projects/platforms such as JMeter and Selenium can be used to simplify web automation and load monitoring and analysis.
Moving forward, in what ways do you see trends in mobile app development influencing the IoT space – which subsequently impacts embedded app development. What should developers be conscious of (including and/or discluding concurrency) in the days ahead?
CHEN: I believe the mobile app is the future. Anything IoT will eventually have a mobile app for it. Consumer-facing products are already moving in that direction, and in a couple of years the business products will follow. If I were in the embedded app space, I would definitely start learning mobile app development or at least have a good understanding of it. In terms of concurrency, from my point of view, I would recommend the same as for mobile app development – always assume the worse out of servers. Test your embedded app with bad connections, no connections, very long lag, etc.; have your app handle an “under maintenance” status in cases where servers may be out of commission or need to be upgraded; make as few server requests as possible.
Hang w/
