Skip to main content

Isolocity Architecture Overview

Isolocity is a web based application that securely stores all manufacturing data, for auditing and reporting purposes. The system uses a completely distributed architecture through Amazon Web Services.

API and REST Based Design

The API is build with a fully REST based design principals, using nested objects and controllers, for a truly RESTful nature. Our front-end clients that connect to this system require a true REST based system, and maintaining this standard helps keep development streamlined and consistent.

Integrations are made easy with ISOlocity because of it’s reliance on convention over configuration. Our API makes data easily to import data into our system, or send data to outside systems that consume JSON feeds.

Front End and Desktop Apps

The front end of the application is built using a JavaScript framework called Ember. This is a widely adopted framework, and is used by large applications such as Apple Music, and LinkedIn. Ember uses a data fetching method which it calls Ember Data. Ember Data strictly consumes RESTful APIs, which of course works flawlessly with our systems.

Ember relies on strong conventions that it uses. Controllers, Models, Views, Components, and Templates, are all kept in a specific place. This helps our development team maintain consistency, and allows new people to be brought onboard much quicker.

The app is then compiled and built into several different versions. The primary deployment is to a single HTML file, with embedded JavaScript, that we deploy to an S3 bucket. We then add CloudFront distribution to the file, so the app is loaded from the users closest location. The Ember app can also be built into a standalone desktop application. We currently do this for macOS, and will be releasing a Windows version soon.

Data and Files

Keeping our clients data safe, is a top priority at ISOlocity. We take advantage of Amazon’s RDS service, so we can get by the second read-write duplication, across multiple Availability zones. These availability zones are maintained across several data centres in your country, so your data is never exposed to another foreign body. Along with replication, we take daily snapshots of each database, and store them for a determined period of time. Hourly (or more frequent time periods) are available as an upgrade feature.

Each organization on ISOlocity is given their own database. Your data does not share the same database as another organization, so there is never any potential for data leaks or seeing other organization’s information. We do maintain a master database with the list of all organizations, and users. We do this so everyone can benefit from a simple user signon, rather then having to visit different URLs for each organization or team.

When a user uploads a file, the file is immediately stored in a AWS S3 bucket. AWS S3 buckets have a 99.999999999% retention rate. That is 11 nines, and is lower then the failure rate of 3 hard drives failing consecutively. The S3 bucket is kept completely private. For a user to see a file, a request is send to the API, with the user’s auth credentials. The API then makes a hash, and sends the hash to the S3 bucket to request the file. The URL can not be stored for later viewing, as the hash expires after 20 minutes.

Authentication and other AWS Services

Due to the fact that ISOlocity uses a fully distributed system, there is a need to manage state across the platform. We don’t use traditional sessions for authentication. Instead we rely on token based authentication. The major benefit of using tokens, is they can be revoked in an instant.

Emails are sent through AWS Simple Email Service. No sensitive information is every contained in the emails that are sent. Only links to take action are provided to the users. In the case of suppliers, where they need to upload documents, a one-time hashed URL is sent to them to provide the information. Once they provide the required information, the URL is destroyed, and another must be made if they want to append their information.

Other AWS services that we use are Simple Queue Service, CloudWatch, Route53, and Lambda. The uses for these services is fairly simple, and we use them as intended (ie CloudWatch to monitor logs, and Route 53 to manage DNS). Everything is contained within a private subnet, within a VPC (Virtual Private Cloud), and only an Internet Gateway is allowed to the API. The API sends data to the RDS instances which are maintained in a private subnet. You must be within the API subnet to access the RDS private subnet.