Can’t believe it, but it’s the last set of talks: Part 2 of CascadiaJS Server Day afternoon.
Michael Lanzetta: Containing the Chaos: Building and Scaling IoT Node Services on Azure Using PaaS and Containerization
IoT = Internet of Things; Two problems = Internet (TCP, but devices are flaky in connection, can lose packets; scaling to handle traffic; servers can go down), Things = devices, low powered, own vector for attack
A lot of these problems are difficult to solve.
Nitrogen.js = our (other) IoT solution (see slides for all features)
Architecture (from the before times) – Devices -> Ingestion Service and Device Registry; Applications can send query to Device registry.
Oxide = IoT Portal for the user, built using Ember-cli
Use Case: Car Telemetry
basic deployment monitored ~30,000 cars, designed to be capable of 60% usage
Each ingestion instance could handle roughly 1000 msgs/sec; ~100 servers total
Needed another layer of indirection.
Deploying using Docker (runs in container), CoreOS (stripped down Linux distro), Deis (Git push to push to entire suite of apps)
Scaling by using AMQP (binary messaging system), wrote AMQP 1.0 package for npm
Still more work to do, love user feedback
Wanted something agnostic, which Azure IoT wasn’t, and didn’t exist at the time.
John Feminella: A Matter of Time
Assumptions ground us but sometimes will get us into trouble, especially with software.
Example: Leap Year: Evenly divisible = leap year, but not if (divisible by 100, or not divisible by 400)
Time is hard. Why is it hard? Because humans.
Two schools of thought is that time exists independently of humans, but others argue that it is a human construct.
Will assume that time is what stops everything from happening at once.
How to represent time?
- Day =
- Year = one revolution around the sun
- Lunation = moon going around the Earth once
All of these are periods.
- Time = measurement within a period, but arbitrarily done
One minute represents a range of time. Even if we’re more specific, it just represents a smaller interval of time.
Problem: Moments are ambiguous
As a human being, we understand it based on context. Need specificity, not just granularity.
What time is it?
While we can specify a time on a particular day in a particular system, we didn’t take into account timezones.
Problem: Want morning times during day, evening times during dark.
Resolution: Charles Dowd proposed timezones. Moved things based on offset.
Problem: We’re not using the same calendar.
Resolution: Use same calendar, but then need to remember switchovers when referred to the past.
Problem: Offset changes, change at different times of the year, and in the past, we changed our mind about when that would happen. Also means sometimes no times occur when move forward, and have two times when moving back.
Something missing when mapping calendar and time.
Resolution: one time zone for every distinct list of historical offsets to remember. Libraries help with applying TZ Database.
Working with Times
Intention matters: e.g. 3 times a week, 6am (regardless of timezone?)
Problem: simple math doesn’t give us the solution
Duration: concrete representation of time
Period: based on calendar.
Need to match time to intentions.
Be careful of library assumptions. e.g. If not whole day, then doesn’t count the day.
Conclusion
- Times are hard, and it’s our fault.
- Be aware of library limitations and differences
- Be precise about your intentions.
That’s the End
Goodnight. Hope you join next year.
