Posts

A while back, we introduced you to Amazon Web Services (AWS) for non-technical folks and today we’re continuing the discussion with the AWS cloud based Relational Database Service (RDS). Understanding the basic components of AWS like EC2 and RDS are some of the foundation blocks for most software, including mobile applications. Gaining high level knowledge in these areas can help, whether you’re a new engineer, manager or startup founder. And today’s topic is super important. Why? Because a database typically houses the most important information about your product, customers and business.

A database is at its most basic, a repository for information. With a large software product, you might have multiple databases, but for today we’re going to focus on a single database since most companies start with one. A database could be compared to a fancy spreadsheet.  Instead of tabs like in Microsoft Excel you might have tables and each table contains different bits of information. The way the information in the tables is laid out is called the data model. This is incredibly important as a software product scales because poorly structured data can be a pain in the you know what later on. So it’s not quite as simple as Excel.

The database for your application needs somewhere to live (like AWS or other cloud providers) and an engine that runs it (like Microsoft SQL Server, PostgreSQL, MySQL, Oracle, etc).  For most of our clients, we use AWS and PostgreSQL. In AWS we have a few hosting options, one is that we could spin up an EC2 instance and install PostgreSQL on that instance and then go from there. However, when we do that, we need to worry about making sure it’s highly available (always up), backed up (disaster recovery) and updated (latest version). If that single EC2 instance were to stop working, then we lose access to our data…and with most applications, that’s not a good thing.

That’s why Amazon introduced the Relational Database Service (RDS). RDS is not a specific type of database or database engine. It’s a managed service running in the AWS cloud for databases that is easy to set up, deploy, scale and update a database with the click of the button. No need to worry about high availability or keeping the database versions up to date. RDS will take care of it for you. Need to have everything backed up? No problem, it’s built in to RDS. Instead of building out everything necessary to have a highly available, durable and updated database, it’s already built into RDS.

On the cost front, RDS can look expensive but consider most companies would need to employ a dedicated person to setup and manage the infrastructure. And instead of days to setup a database, it took a few minutes. That’s time to be used elsewhere. RDS has simplified an incredibly complex process and should be considered as part of any scalable software infrastructure.

We’ve covered what a database is, why it’s important and why you should consider RDS as an easy way to setup a highly reliable database running in the AWS cloud. If you have any questions about how this might fit into your project, send us a note.

Amazon recently announced over 100 new cloud services and products at the latest re:Invent conference. While there are tons to be excited about, there are four cloud services that we look forward to using in future projects. Most we’ve had to build from scratch at some point or have had clients ask for them only to be disappointed in the high cost of development. All four services introduce easier ways to integrate machine learning into your cloud based software or mobile application, without significant added cost.

Amazon Personalize

When shopping on Amazon.com, have you noticed the recommendations based on your latest purchases? That’s all created by a recommendation engine that is based on things you like, and things other people like you have purchased too. Amazon is now making similar recommendation models available to developers. Imagine you have an app, like CurEat, that curates local restaurants and lists.  You can now make more personalized recommendations using Amazon Personalize instead of developing something from the ground up.

Amazon Forecast

Remember using spreadsheets to forecast sales for your company, or maybe for a school project? Ok, so maybe not everyone had to do that, but at some point in your career you’ve likely been asked to forecast sales, inventory, or some sort of business or application metric. With Amazon Forecast, you can now feed your data into deep learning algorithms based on the same algorithms Amazon uses for their own business. Amazon says their forecasts are 50% more accurate and are completely automated. Say goodbye to continuous feeding and care of spreadsheets for forecasts. As developers, we can use Amazon Forecast in all sorts of features and components, from predicting product usage to in app features like forecasting production material needs or equipment breakdown in IoT devices.

Amazon Textract

Amazon Textract is like an OCR service except it goes a few steps further and can extract data from fields and tables, and do so very affordably. This is great news for startups or really any company needing to integrate some level of OCR into their product. Imagine quickly building a mobile app that scans old school paper copies of insurance claims, medical records or any paper form. Then taking that data and uploading to a CRM or EHR system, quickly and easily. That’s just the beginning of what’s possible with Textract and there are sure to be more complex, more exciting uses for something that is now incredibly inexpensive and accessible. How inexpensive? Try $1.50 per 1,000 pages for the Document Text API. Read more here.

Amazon Comprehend Medical

Finally, for our medical device and healthcare clients, we’re super excited to see Amazon Comprehend Medical, an expansion of Amazon Comprehend. Amazon Comprehend Medical uses Natural Language Processing to process text in documents and files. Say you have years of medical records that weren’t exactly filed away correctly. Now you can use Amazon Comprehend Medical to process those files and look for patterns. For example, maybe you have an archive of unstructured documents, like physician notes, and you want to extract documents pertaining to a particular medical condition. You can use Amazon Comprehend Medical to look for the medical terminology that coincides with that condition, making it possible to comb through archives in a matter of minutes without manual intervention. It also has the ability to detect Protected Health Information (PHI) which could be used for organizing data or in some cases, avoiding parts of data that may not be necessary for a specific use case.

These are just four of the new services that will be available via AWS in the next few months, and we’re excited to help our clients introduce new features that are now more affordable than ever. If you’d like to hear more about what AWS can offer, contact us or read all the latest announcements from re:Invent here.

If you’re anything like me, you’ve spent an unhealthy amount of time perusing adorable cat GIFs on your phone, tablet, computer, tv and anything else that will let you get your fix of cuteness.

via GIPHY

In addition to browsing cat GIFs on every device I own, I can also check my email, listen to my collection of music, chat with my friends and even write blog posts! On every device I own I can access the same emails, the same music, the same chats, and the same text documents.

In a world where seemingly everything is connected, it is almost unheard of for a web app to exist without an associated mobile app, and vice versa.

Build Once, Use Anywhere

To reach so many diverse platforms, it is crucial to initially develop with the “Build Once, Use Anywhere” mentality. What do I mean?

Let’s say you want to create a program that lets you browse adorable cat GIFs (if you do end up doing this, definitely let me know!). You decide you want to build a website and an iPhone app, but also want to be able to add iPad and Android apps in the future. To “build once, use anywhere” in this case means building one API that knows how to talk to all of the apps, current and future, that you create, rather than creating an API for each app.

API

An API allows one program to interact with another. In this case, you would create an API that communicates between your cat GIF storage and the mobile and web apps people are using to view and upload cat GIFs. So, let’s come up with a few API commands you’ll want:

  • Create – Allows user to upload a GIF (Technical term: POST)
  • Delete – Allows user to delete a GIF (Technical term: DELETE)
  • Update – Allows user to change the name of a GIF (Technical term: PATCH)

For reference on the technical terms listed above, check out this article.

Now that we’ve defined our API commands, we need to create a way for apps to interact with the API. Both the device running the apps and the device running the API must be connected to the Internet. In this case, the API is part of a program that runs on a computer called a “server” which is connected to the internet.

Server

In computer science jargon, this project structure can be referred to as a “client-server model”, where one server (a program that runs your API) knows how to communicate with many clients (iPhone, Android, desktop, laptop, etc). If you want to learn more about the details of how a client-server model works, check out this article.

In reality, the server is just a computer in “the cloud,” which means it is just a computer connected to the open internet!

https://cdn.techterms.com/img/lg/client-server_model_1253.png

Storage

Now that your API connects your server with your apps, you need a database to store the cat GIFs that are uploaded. A database can either be hosted on a server of its own or the same server as the API. To keep it simple for this example, we’ll just say the database is hosted on the same server as the API.

The goal of the database is to keep it isolated so that only the web server framework running the API knows how to access the data. This keeps the data secure and abstracted in a way that only one device (the server) has to know how to access it instead of all the devices users have.

Takeaways

  1. If you’re looking to have a mobile app built, make sure the API is being developed with the “build once, use anywhere” mindset. This is one of the easiest money and time-saving decisions in modern programming.
  2. Whether you’re on a phone, tablet, computer or other device, if you’re using the same service (e.g. Google, Spotify, etc.) then you’re likely interacting with the same API to access that service on all devices!
  3. “Build Once, Use Anywhere” allows you to build the logic behind a service once and allow use of that logic from as many devices as you want (or can afford).
  4. If you build an awesome cat GIF app, make sure to let us know!